Subject: constructing service principals

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 19 Feb 2002 11:55:06 -0500

Clients trying to construct service principals is a huge problem that
leads to current interoperability problems with Kerberos.

* The "standard" situation as it is today:

RFC 2743 (GSS) gives an "example" of canonicalizing which is followed
by some Kerberos implementations.  Sadly, even this example is
incomplete:

   When a reference to a name of this type is resolved, the "hostname"
   may (as an example implementation strategy) be canonicalized by
   attempting a DNS lookup and using the fully-qualified domain name
   which is returned, or by using the "hostname" as provided if the DNS
   lookup fails.  The canonicalization operation also maps the host's
   name into lower-case characters.

Does "attempting a DNS lookup" mean doing a forward lookup (chasing
any CNAMEs) or doing a forward lookup followed by a reverse lookup?
In our Kerberos 4 implementation (KTH) only a forward is done.  In our
Kerberos 5 implementation (Heimdal) both a forward and a reverse are
done.

* Proposed changes?

The latest Kerberos revisions draft
(draft-ietf-cat-kerberos-revisions-10) has a footnote with the
following:

   2.2
     It is important that the KDC be sent the name as typed by the user, and
     not only the canonical form of the name. If the domain name system was
     used to find the canonical name on the client side, the mapping is
     vulnerable.

It's unclear to me where this footnote is referenced.  This directly
contradicts the "example" in RFC 2743.  It is also not clear if it is
normative.

* Current implementations

We have three Kerberos 5 implementations in production here at
Computing Services at CMU.  All three construct service principals
differently:

. Heimdal does a forward DNS lookup, a reverse DNS lookup, and then
  downcases the resulting string.

. Microsoft performs no canonicalization on the client.

. Sun Java JDK 1.4 does a forward DNS lookup, a reverse DNS lookup,
  and then uses the resulting string with no further modifications.

Needless to say, this causes interoperability headaches today.

* What should be done?

Hopefully, this is something that clarifications can help with.

I believe that footnote 2.2 should be moved into the body of the text.
It should be made explicitly normative (as at least a SHOULD and
possibly a MUST) and should explicitly say that "when Kerberos is used
under a GSS mechanism with host-based service naming, no
canonicalization is done".

Larry