Nicolas Williams wrote:
>
> On Tue, Jun 12, 2007 at 11:03:11PM +0200, Martin Rex
wrote:
> > I never liked hostbased service names
>
> Well, we undoubtably need principal names for hosts.
The service part
> seems... less necessary.
Depends on what you do.
In many situations hostbased service names are not only
unnecessary,
they acutually create significant pain and problem.
On which particular "host" a service runs today,
and on which
it runs tomorrow should be left up to the sysadmin, in many
situations a causal user need not and ought not to care
about this.
None of the X.509-based gssapi mechanims I've seen so far
did
support hostbased service names. Probably all of our
customers
that use an X.509-based gssapi mechanism for single sign-on
do *NOT* put hostnames into their server's certificates,
but
instead the name of the distributed system, because
it is so much easier if you can share the credentials for
all servers in your backend server farm. You also don't
have
to mess with the ACLs used by backend servers to
authenticate
each other when you add or change/replace servers.
When using domain-based service names, the "service
name" should
probably not name a protocol, but rather a particular
incarnation
of a service. Otherwise, one would need a seperate
"domain"
(DNS-domain, Kerberos Realm) for each independently-managed
incarnation of a service talking a particular protocol.
A single (independently managed) Web-Server per domain looks
like
a pretty strong limitation to me, and requiring a seperate
domain
(or worse, a seperate kerberos realm) per Web-Server is a
fairly
expensive solution (e.g. when each kerberos realm is equal
to a seperate Windows PDC).
But if _not_ using the protocol for the service part of the
name,
the client software has little chance to guess it (or to
supply
it automatically), it needs to get that information from the
user.
-Martin
_______________________________________________
Kitten mailing list
Kitten lists.ietf.org
https:/
/www1.ietf.org/mailman/listinfo/kitten
|