[24331] in Kerberos

home help back first fref pref prev next nref lref last post

SPN Canonicalization (was: Re: [neon] Re: neon, SSPI,

daemon@ATHENA.MIT.EDU (Christopher Mason)
Fri Jul 22 15:00:41 2005

Date: Fri, 22 Jul 2005 08:25:50 -0500
From: Christopher Mason <Mason.Christopher@mayo.edu>
To: Joe Orton <joe@manyfish.co.uk>
Message-Id: <94546BA9693E0AA93651C8C4@71-10-94-9.dhcp.roch.mn.charter.com>
In-Reply-To: <20050722103006.GB613@manyfish.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
cc: Rudi Chiarito <chiarito.rudi@mayo.edu>
cc: neon@webdav.org
cc: vmpn@hitechman.com
cc: modauthkerb-help@lists.sourceforge.net
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu

[Removing subversion and adding comp.protocols.kerberos.]

--On Friday, July 22, 2005 11:30 AM +0100 Joe Orton 
<joe@manyfish.co.uk> wrote:

> There is some discussion of this issue in the neon list archive;
> the  issue is AIUI that mod_auth_kerb *does* canonicalize the
> hostname but  neon does not.  neon doesn't canonicalize the server
> hostname in general  because doing so would break name-based
> vhosting; I guess it could do so  solely for use in the Kerberos
> principal, but that seems a bit dubious.

Yeah, this is a messy, long-standing, and unresolved issue in 
kerberos.  In theory canonicalization introduces a potential MITM 
attack which essentially undermines mutual authentication; in 
practice, everyone does it.  This is apparently to be addressed in 
future protocol mods, but it's unclear what to do in software that 
actually needs to work today.  Read on for details.  Maybe this could 
update the kerberos FAQ?

The question is: should an application canonicalize a hostname 
entered by a user when forming the SPN?

Defining terms:

SPN = serviceName/HOST@REALM
   eg HTTP/proteomics.mayo.edu@MFAD.MFROOT.ORG

where SPN is the Service Principle Name, the name of the
           kerberos principle that the service uses to
           authenticate itself to the client (so called
           "mutual auth").
      serviceName (eg HTTP) is the (case sensitive[1]) protocol
           specific service name established by convention.
      HOST (eg proteomics.mayo.edu) is the host name of the
           machine the service is running on.  This is the
           part we're wondering about.
      REALM (eg MFAD.MFROOT.ORG) is the name of the kerberos
           realm and is often implicit.

Canonicalization is essentially gethostbyaddr(gethostbyname(host)) 
where host is the name provided by the user.

I've done some googling on this issue and the clearest statement I 
can yet find comes at the end of section 1.3 in RFC4120, which states:

> 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., they 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).
[...]
> Implementation note: Many current implementations do some degree
> of canonicalization of the provided service name, often using DNS
> even though it creates security problems.  However, there is no
> consistency among implementations as to whether the service name
> is case folded to lowercase or whether reverse resolution is
> used.  To maximize interoperability and security, applications
> SHOULD provide security mechanisms with names that result from
> folding the user- entered name to lowercase without performing
> any other modifications or canonicalization.

Clear as mud?  So it seems like we're left with a choice between 
interoperability and correctness.  Almost all other discussion I find 
of this issue seem to indicate that canonicalization is performed in 
practice.  Firefox and IE definitely do it.  See also question 2.14 
in the Kerberos FAQ: 
<http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbdns>, 
and numerous previous discussions on comp.protocols.kerberos such as 
this thread on load balancing and kerberos: 
<http://mailman.mit.edu/pipermail/kerberos/2004-April/005102.html>.

Samba seems to work around this problem by creating a skillion 
different keytab entries like:

   3 HTTP/proteomics.mayo.edu@MFAD.MFROOT.ORG
   3 HTTP/proteomics@MFAD.MFROOT.ORG
   3 HTTP/PROTEOMICS@MFAD.MFROOT.ORG
   3 HTTP/PROTEOMICS.mayo.edu@MFAD.MFROOT.ORG
   3 HTTP/proteomics.MFAD.MFROOT.ORG@MFAD.MFROOT.ORG
   3 HTTP/proteomics.mfad.mfroot.org@MFAD.MFROOT.ORG

and many more besides these (with different salts?).  See 
<http://lists.samba.org/archive/samba-technical/2004-November/038234.html>. 
There's an additional problem with samba, active directory validated 
writes, and disjoint namespaces that I'll save for another time.

It seems to my uneducated eye that really GSSAPI should be such that 
we simply hand it "HTTP" along with the host name entered by the user 
and it figures out the rest.  Alas, it is not so.  What to do is 
anyone's guess.

Anyone care to jump in here?

-c

[1] Services names are supposed to be lower case; other examples 
include "host" and "imap".  "HTTP" is apparently a happy gift from 
microsoft.

-- 
[ Christopher Mason  MPRC Bioinformatics  http://proteomics ]
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post