Subject: Re: Soliciting additional GSS/Kerberos interoperability results

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

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: "John Brezak" <[email-masked]>
Date: Fri, 11 May 2001 11:39:51 -0700

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, May 11, 2001 2:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Soliciting additional GSS/Kerberos interoperability results

John Brezak wrote:
> 
> There appears to be an issue with gss_canonicalize_name when used with

> Kerberos. If a middle tier server has multiple principals (as is 
> currently the case with Kerberos), how can gss_canonicalize name be 
> used in its described way for building a canonical name for that 
> middle-tier server that can be stored on ACLs?

Which particular problem are you referring to?
(MIT) Kerberos 5 doesn't have a problem here, it should be implementable
with DCE.  I know that Microsoft Kerberos has a problem, but that's a
design flaw.

We have certified more about a dozen different gssapi mechanisms for
interoperability with our application and none of them had a problem
with gss_canonicalize_name() ...

-Martin

---

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

That host should have one canonical name for all its addresses, meaning
there should be one DNS PTR RR for each of its IP addresses, all of
which reference the same canonical name. But that host could have
multiple aliases, and those aliases may be in the form of CNAME RRs
(preferred) or A RRs (ok).

See my preceding mail for an example

Also, gss_canonicalize_name() accepts a GSS-API name structure and
returns another one with all but one mechanism-specific names removed;
GSS-API names are allowed to contain just one name for each mechanism
supported by that GSS-API implementation.

Nico

--