loadbalancing of keberized services

Donn Cave donn at u.washington.edu
Tue Apr 13 16:19:30 EDT 2004


In article <1858400000.1081881728 at minbar.fac.cs.cmu.edu>,
 jhutz at cmu.edu (Jeffrey Hutzelman) wrote:

> On Monday, April 12, 2004 16:52:23 -0700 Donn Cave <donn at u.washington.edu> 
> wrote:
> 
> > I believe we're more or less always asking for this trouble.
> > If you don't get a canonical, reverse looked-up name back
> > out of MIT Kerberos krb5_sname_to_principal(), then you're
> > doing something different than me.
> 
> Well, for starters, I don't call MIT kerberos krb5_sname_to_principal() 
> very often, since I don't currently use that implementation.

So, do you currently use an implementation where that function
or its equivalent doesn't return a canonical name?  My experiment
with Heimdal 0.6 tells me it works just like MIT, but I am not as
familiar with that implementation and could be missing something.

> Performing DNS alias resolution in krb5_sname_to_principal() is insecure 
> unless you have a well-managed DNSSEC infrastructure, which virtually no 
> one does.  I have always considered this behaviour to be an implementation 
> bug.  While this is not addressed well enough in RFC1510, the next version 
> of the Kerberos V spec (due out later this year) will include the following 
> text:
> 
>       Implementations of Kerberos and protocols based on Kerberos MUST
>       NOT use insecure DNS queries to canonicalize the hostname
>       components of the service principal names (i.e. MUST NOT use
>       insecure DNS queries to map one name to another to determine the
>       host part of the principal name with which one is to communicate).

The language I read (I think it was at least 6 months ago) didn't
even leave room for CNAME alias translation, let alone reverse
lookup canonicalization. 

I don't think it's really fair to call current behavior a bug,
because it has too large of a constituency.  Whatever MIT chooses
to do about it after this spec comes out, I wouldn't care to be
in their shoes.

It would be especially ironic if adequately secure DNS were to
become widespread in a year or two from now.  So after a decade
of supporting a naming model with this security problem, Kerberos
switches to a different model just about the time the old one
becomes safe for anyone who cares.

   Donn Cave, donn at u.washington.edu


More information about the Kerberos mailing list