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: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 13:05:21 -0700

> step back and let Nico actually argue about solutions.

:)

> involved, you want to use the same GSSAPI name.

So, the Kerberos TGS names are what I'd call domain-based service names
- like host-based service names, but with a domain (realm) name instead
of a hostname.

I think the concept of domain/cluster-based service names needs to be
generalized beyond the particular case of the Kerberos TGS.

One way to do this would be to define a new GSS-API name type.  Another
would be to establish the convention of using domain names with the
existing GSS-API host-based service name where domain-based services are
needed.

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.

> need to share a replay cache.

Replay cache sharing is a related issue, but it's an implementation
detail, a security consideration.  Of course, shared replay caching is
reasonably feasible for some cases, but it may not always be feasible
though.

I think that, for example, LDAP services ought to use domain-based
service names, no matter how the servers are located.  This means that
the LDAP servers for any given domain have to share a replay cache OR
that we really need a domain-based name type with host instances.

>    just deal internally or we could use some new name type.

In the case of LDAP the service name may often not be derived from any
information typed in by the user (e.g., where LDAP is used by a name
service switch).  The domain name could come from local configuration or
from user context (e.g., from a domain-qualified username).  If we're
using a domain-based name type with host instances the hostname can
safely come from an SRV record.

See above.

>    future that make unreasonable requirements of multi-mechanisms

IMO it would be nice to specify a domain based name type for the GSS-API
and the various existing GSS-API mechanisms.  Then amend SASL to require
support for domain-based naming where applications request it and where
the SASL mechanisms support it.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Aug 2003 16:50:34 -0400

One thing I think I can do with my chair hat on is suggest what you'd
need to do if you want to make a change to the SASL GSSAPI spec.
Obviously you'd need to get consensus.

But it seems that you would need to specify how the SASL GSSAPI spec
should choose the GSSAPI name it uses, and how it works with GSSAPI
mechanisms that do not support any new name types you introduce.  Then
you would need to fully describe interoperability considerations,
looking at applications written to the old SASL GSSAPI mechanisms as
well as old implementations of the SASL GSSAPI mechanisms.  Then you
need to convince people that your proposed changes are acceptable.

---

From: Steve Hole <[email-masked]>
Date: Thu, 21 Aug 2003 16:22:42 -0700

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

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 15:25:24 -0700

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Aug 2003 21:38:43 -0400

On Thursday, August 21, 2003 15:25:24 -0700 Nicolas Williams 
<[email-masked]> wrote:

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

Of course, this only describes the name syntax at the GSSAPI layer.  In the 
case of the Kerberos mechansm, this would presumably map to principal names 
with more than one component, like 
http/fully.qualified.host.name/[email-masked], as Paul Leach 
described.

I'd be interested in hearing what sort of GSSAPI name types Microsoft is 
using that map to these principal names, if any.  And I'd also like to hear 
whether these are truly three-component principal names, or 
single-component names with '/' embedded in the instance.

In any case, I'm somewhat concerned as to whether defining a new GSSAPI 
name type is in scope for this working group.  Actually, I'm more concerned 
that if this work happens here, we might inadvertently exclude folks who 
care about this issue but otherwise have no interest in SASL.  As long as 
we make sure these folks have a chance to participate, I'm all in favor of 
doing this work here -- it's a real problem and I'd definitely like to see 
a solution.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 21:39:06 -0700

> http/fully.qualified.host.name/[email-masked], as Paul Leach 

Of course, I was only describing the proposed GSS-API name syntax.

> single-component names with '/' embedded in the instance.

Me too.

> doing this work here -- it's a real problem and I'd definitely like to see 

No kidding.  I think that given the lack of a CAT WG (or KITTEN, as
you've suggested - no I haven't come up with something that it could be
the acronym for) we can do GSS-API work elsewhere, but we ought to give
other WGs heads ups, and even Last-Call in multiple WGs.  E.g., the
NFSv4 WG I-D on CCM - the Channel Conjunction Mechanism.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 23:49:10 -0500

The SRP GSS-API mechanism that's been discussed here is one that could
use domain-based names.

As we've seen, though SRP itself provides for mutual authentication, the
proposed mechanism does not deal with acceptor principal naming,
therefore it can't be said to provide mutual authentication with any
acceptor name other than the anonymous name.

This can be addressed by salting the password/verifier with the name of
the acceptor principal, but this would mean generating a verifier
per-{user host} tuple, which does not scale well.

So an SRP mechanism could benefit from domain-based names in
environments where verifiers are generated per-{user service} or {user
domain} tuples, or any such tuple that is less numerous than {user host}
tuples are.  That is, one could get away with fewer verifiers per-user
by using domain-based names.

This possibility complicates the way in which an application decides
which name type to use for an acceptor, but not much.  As I've said, I
think LDAP ought to use domain-based names, but existing implementations
may not, so for interop any implementation that supports domain-based
names will also have to be configurable to use host-based names.  Such a
configuration parameter might be a per-mechanism parameter (and one
might even have a per-domain configuration too).

I hope this and my previous post answers Sam's question about when to
use which name type.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 13:05:21 -0700

:)

See above.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Aug 2003 16:50:34 -0400

---

From: Steve Hole <[email-masked]>
Date: Thu, 21 Aug 2003 16:22:42 -0700

Cheers.

---
Steve Hole

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 15:25:24 -0700

NP :)

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Aug 2003 21:38:43 -0400

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 21:39:06 -0700

Me too.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 23:49:10 -0500

Cheers,

Nico
--