Subject: GSSAPI and domain-based names

From: [email-masked] (Sam Hartman)
Date: Thu, 21 Aug 2003 15:35:58 -0400 (EDT)

A few months ago, there was a discussion on the [email-masked] mailing
list about names for GSSAPI principals. 

One conclusion from that list is that we may have an incomplete
handling of the issue in SASL.  I'm going to present the issue and
step back and let Nico actually argue about solutions.

The problem is what GSSAPI name do you use for replicated GSSAPI
services?  For some services, particularly those running on a cluster
of tightly connected machines, especially with aload balancer
involved, you want to use the same GSSAPI name.

But for other services, especially when an SRV record is used to find
the specific machine, it seems like you want to avoid requiring the
instances of the service to use the same GSSAPI name.  This is
particularly true for some GSSAPI mechanisms such as Kerberos that
need to share a replay cache.

Note that this issue is not unique to GSSAPI.  Other mechanisms such
as the digest-md5 mechanism specify mildly complicated naming rules,
where the name the user typed in is combined with the the name from
the DNS or other location service.

Two questions:

1) Do we want to provide some better handling for this situation in
   the GSSAPI case?  IT's clear we cannot get away with just using
   service@name_from_dns.  We can either use
   service@name_typed_by_user, requiring any replicated service to
   just deal internally or we could use some new name type.

2) Do we want to say anything about this in the base spec?  We aren't
   designing an API, but we may want to give general guidelines about
   what bits of information SASL mechanisms can assume they can get
   from an application, to prevent people designing mechanisms in the
   future that make unreasonable requirements of multi-mechanisms
   implementations.

--Sam

---

From: "Paul Leach" <[email-masked]>
Date: Thu, 21 Aug 2003 16:15:17 -0700

There is lots of implemented art here at MSFT on principal names for
replicated services. I'll attempt a brief intro.

We use "service-type/service-instance/service-name" as the principal name.

The service type might (and is, for Active Directory) "ldap". The service
instance is the host an instance is running on -- "ad1.microsoft.com" might
the the host for one instance of AD. The service-name might be
"microsoft.com" for the LDAP service for Microsoft. (Microsoft's is actually
a hierarchy of LDAP naming contexts, but this might be a real enough example
for a smaller company.)

The overall service principal name (SPN) for this example would thus be:
"ldap/ad1.microsoft.com/microsoft.com" -- this is what is in the "sname"
field of the service ticket.

In the case that a single host runs multiple instances of a service, the
above is elaborated a little bit. The service-instance is
"service-host:instance-within-host". The instance with a host could be the
port number of the separate instance, or it could be anything the
application protocol chooses. (In fact, the whole "service-instance" is just
a convention of the application protocol -- a UUID would work just fine.)

The way our clients of replicated services work is that they look up SRV
records for "service-name" -- in the above example, they might have looked
up _ldap._tcp.microsoft.com and gotten back "ad1.microsoft.com" and
"ad2.microsoft.com" and picked the first one.

Note that the lookup does not have to be secure -- a DNS spoofing attack
that returned "ad3.microsoft.com" as a SRV record would not be backed up by
an entry in the KDC account database with a key that the attacker knew
unless the KDC administrator had entered it there, thus attesting to the
fact that it was a legitimate LDAP server for the "microsoft.com" domain.

(If no SRV records are found, then A records are looked up, and if found,
the form "service-type/service-host" is used. Again, if multiple instances
on a host are allowed, then "service-type/service-host:instance-within-host"
will enable that.)

We use this convention polymorphically across all our GSSAPI (aka SSPI)
providers that do mutual authentication. Not all of them are full function,
however.  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nicolas Williams
> Sent: Thursday, August 21, 2003 3:25 PM
> To: Steve Hole
> Cc: Sam Hartman; [email-masked]
> Subject: Re: GSSAPI and domain-based names
> 
> 
> On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote:
> > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams 
> > <[email-masked]> wrote:
> > 
> > > If we go the route of defining a new GSS-API name type we can 
> > > actually do a very neat trick: we can have the name encode the 
> > > service name, the domain name and, optionally, a hostname 
> name (an 
> > > instance of the domain- based service).  This would avoid 
> the replay caching issue.
> > > 
> > > What's the difference between domain-based service names and 
> > > host-based service names?  With host-based service names, if a 
> > > client has to lookup what servers are associated with a 
> domain-wide 
> > > infrastructure/cluster, the resulting principal names 
> won't reflect 
> > > the domain/cluster association, and if the lookup is not 
> secure, well that's a problem.
> > > With domain-based names the client makes sure that the 
> name of the 
> > > domain/cluster it's interested in is part of the 
> principal name and 
> > > so binds the service principal name, no matter how the 
> servers may 
> > > be found, to that domain name.
> > 
> > 
> > Could you please work up an example of this Nico -- say a 
> three system 
> > load balanced HTTP cluster?   I'm having a hard time 
> understanding exactly
> > when the name resolution is going to occur and what kerberos 
> > principals will be bound.
> > 
> > Sorry for being thick )-:
> 
> NP :)
> 
> For a load balanced system one would have to use a principal 
> that is shared throughout the cluster (that means sharing the 
> rcache too, for Kerberos).  So the principal name would be 
> just service@domain or service@clustername.
> 
> For non-cluster domain-wide services the names might be of 
> the form service@domain@host_instance.
> 
> I.e., the syntax for domain-based names might be
> 
> <service> "@" <domainname> [ "@" <hostname> ]
> 
> Where you can share a principal across multiple hosts you'd 
> not use the optional hostname instance part.
> 
> Cheers,
> 
> Nico
> -- 
> 
>