Subject: RE: GSSAPI and domain-based names

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
> -- 
> 
>