Subject: Re: Soliciting additional GSS/Kerberos interoperability results

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 21:50:25 +0200 (METDST)

John Brezak wrote:
> 
> So in the case where a "client" is known by multiple names, one and only
> one name can be used for authentication to the server for the purposes
> of gss_canonicalize_name?
> 
> What if the admin of the database were handed all of the known names for
> the front-end server in my example? How does the admin of the database
> get the correct name to put on the ACL?
> 
> Ideally each of the inputs to gss_canonicalize_name of [email-masked],
> [email-masked] and [email-masked] all end up with the same canonical
> name of "[email-masked]".
> 
> Also multi-homed hosts do not need to have the same names - then can
> exist in different DNS zones and frequently do.

That's what I've been telling you all the time.

Traditional Kerberos hostbased service names are not really
compatible with GSS-API, and the approach that Microsoft has taken
to implement is clearly incompatible with GSS-API.

The flaw is not with GSS-API here.  GSS-API is really and truely generic.
However GSS-API doesn't promise that it can cover every conceivable
gssapi mechanisms' characteristics.  Some of the vendors of security
and authentication toolkits that approached finally added GSS-API
to their mechanism because it was required for interoperability
with our application.  However some had "features" that they weren't
able to carry through.

One example was a provider who offered user-specific configuration 
of what "data protection" level was required when the user communicated.
Well, such a policy can not be enforced by a gssapi mechanism onto
a gssapi-based application.  In the initial test protocols I noticed
the same performance during gss_wrap for message protection
with and without confidentiality and I asked them for the cause.
They told me about their policy settings in their user management
and I laughed.

When our application is configured to use "integrity protection",
it uses gss_getmic() instead of gss_wrap(), so their attempt
to force confidentiality upon our application failed.  You can
configure our application to use authentication only, then
it will not do any message protection call at all ...

No, really: the approach how Microsoft implemented hostbased service
name is wrong because it is not possible to create a GSS-API level
abstraction for it.  Premature optimization.

-Martin

---

From: "John Brezak" <[email-masked]>
Date: Fri, 11 May 2001 12:29:38 -0700

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, May 11, 2001 12:04 PM
To: John Brezak
Cc: [email-masked]
Subject: Re: Soliciting additional GSS/Kerberos interoperability results

John Brezak wrote:
> 
> Consider this scenario. Clients connect to a computer that is known by

> multiple DNS name - foo.dns.com, bar.dns.com and baz.xyz.com. As a 
> result it has these Kerberos principals - host/foo.dns.com, 
> host/bar.dns.com, host/baz.xyz.com.
> 
> This host is the middle tier of an application and needs to access a 
> database on another server. That server authenticates the middle tier 
> server and needs to have it's identity on the database access control 
> lists. In order for this to work, all 3 principal names would have to 
> be on the ACLs, but there is no canonical name for the host. The 
> database server only knows that host as "baz.xyz.com".
> 
> What is the expected behavior of gss_canonicalize_name when presented 
> with these principals for the same application?

Traditional kerberized applications may have a problem. Portable GSS-API
based application don't have this problem. We have such a distributed
application and it works just fine. Since its a "portable" GSS-API based
application, none of the components makes the flawed assumption that
there is any relation between the hostname assigned to the address of
the transport endpoint and the identity of the service that it wants to
talk to.

As we talk about this.  When we recently added the cabability to use
HTTPS alternatively to legacy GSS-API protected communication I realized
once again how stupid it is that Web-Browsers expect hostnames in the
certificate of the Web-Browser.  Trying to use the SSL server certs for
SSL client connections inside the distributed environment will make your
ACLs explode.  We use the same SSL client credential for all instances
of the same service.  Unfortunately, because we want to allow regular
Web-Browser access, some toying around with the SSL server identity is
required for secure mutual authentication.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 22:19:36 +0200 (METDST)

> of gss_canonicalize_name?

In gssapi, there is no real link between client and identity.
The link is between credential and identity.  Each credential
has exactly one canonical name.  This name pops out of
gss_accept_sec_context() when this credential is used by
an initiator to establish a security context.

Both, initiator and acceptor can acquire either a "default" credential
or they can acquire a credential by name.  It's mechanism specific
whether there are any aliases or abbreviations available for names.

It is a serious usability issue and an administrative nightmare
when the allowable names have a very local meaning and frequent
collisions with other local names.

> name of "[email-masked]".

Ideally one wouldn't use any hostbased service name with GSS-API.
Although I could have, I don't prevent the use of hostbased service
name in our application (with mechanisms that recognize it).
However I recommend against using them, primarily because of
the DNS-based hostname canonicalization in MIT Kerberos 5 v1.x.

> exist in different DNS zones and frequently do.

Basically all our customers use multihomed hosts.  Some have initial
problems of getting the different types of communication channeled over the
correct network.  We never had a single "identity crises".  The PKI-lovers
usually share a single credential among all distributed instances of the
same service.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2001 16:51:23 -0400

- MS chose to have one key per-host -- why are you concerned here?

 - gss_canon_name() is not what you think. gss_import_name() creates a
   gss name which may contain multiple names, one per-mechanism, but
   since GSS supports only one mechanism per-context there needs to be a
   way to remove unused mechanisms' names from the gss name, and *that*
   is what gss_canon_name() does. It should have been named
   gss_reduce_name() in the beginning.

   Theodore Ts'o pointed this out last time we went around this whole
   name canonicalization thing.

 - so then, what's this about a server having multiple names and
   determining which is the "canonical" or preferred name?

Nico

--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2001 17:13:33 -0400

> an initiator to establish a security context.

Right. It's the responsibility of the initiator to ask for the default
credentials (in MIT krb5 that would be whatever creds are in the ccache
referenced in the KRB5CCNAME environment variable) or some other creds.

> whether there are any aliases or abbreviations available for names.

I don't think John Brezak is concerned with aliases here but with hosts
(applications) with multiple identities. See below.

> collisions with other local names.

[...]

> Ideally one wouldn't use any hostbased service name with GSS-API.

I still think this hostbased service principal name stuff is just a way
to partition the principal name space and is artificial -- at most, when
you reference a hostbased name in GSS-API you're giving the GSS-API a
hint that the name in question is a hostname that could be looked up
and canonicalized by GSS-API (this is what gss_import_name() does, at
least in MIT krb5).

> usually share a single credential among all distributed instances of the

With multi-homed hosts the *key* is to have each IP address have a PTR
resource record in DNS such that all those PTR RRs reference the *same*
canonical name, and that name, in turn, should have multiple A RRs, one
for each IP address of the host.

E.g.,

foo.bar.com.	IN	A 10.20.30.40
foo.bar.com.	IN	A 10.20.31.40
foo.bar.com.	IN	A 10.20.32.40
foo-e1.bar.com.	IN	A 10.20.30.40
foo-e2.bar.com.	IN	A 10.20.31.40
foo-e3.bar.com.	IN	A 10.20.32.40
...
40.30.20.10.in-addr.arpa.	IN	PTR	foo.bar.com.
40.31.20.10.in-addr.arpa.	IN	PTR	foo.bar.com.
40.32.20.10.in-addr.arpa.	IN	PTR	foo.bar.com.
...

Nico
--