Subject: pkinit comments: confirming kdc certificates

From: Chaskiel M Grundman <[email-masked]>
Date: Wed, 02 Feb 2005 20:48:44 -0500

The existing text's description of how to confirm a kdc certificate in the
PA-PK-AS-REP focuses on making sure that the certificate is bound to the
hostname or IP address of the target KDC. 
However, an increasing number of kerberos deployments do not preconfigure
kdc hostnames. They instead rely on (insecure) DNS to find the identity of
the kdc's for a given realm. When traditional AS/TGS exchanges are used,
this is safe, because the AS (and cross-realm TGS) exchange authenticates
the kdc to the client (because only the client and the kdc know the correct
key). When pkinit (or pkcross) become involved, this is no longer true.

I think it would be appropriate to bind the certificate to the kerberos
realm (perhaps by using a SubjectAltName of type id-pksan containing the
TGS name of the target realm) instead of or in addition to the target kdc.

---

From: Chaskiel M Grundman <[email-masked]>
Date: Sun, 06 Feb 2005 19:35:14 -0500

Here's some text I'll propose for dealing with this issue using id-pksan. I
think that focusing on realm FQDN's is the wrong approach when the document
already defines a mechanism for putting a principal name in a
subjectaltname.

Old text:

   Unless the client can otherwise prove that the KDC's certificate is
   for the target KDC (i.e., the subject distinguished name in the KDC
   certificate is bound to the hostname or IP address of the KDC
   authenticating the client), it MUST do the following to verify the
   responder's identity:

   1.  The client checks to see if the included certificate contains a
      Subject Alternative Name extension [RFC3280] carrying a dNSName or
      an iPAddress (if the KDC is specified by an IP address instead of
      a name).  If it does, it MUST check to see if that name value
      matches that of the KDC it believes it is communicating with, with
      matching rules specified in [RFC3280].

New text:

   Unless the client can otherwise prove that the KDC's certificate is
   for a KDC in the target realm, it MUST do the following to verify the
   responder's identity:

   1.  The client verifies that the included certificate MUST contain a
      Subject Alternative Name extension [RFC3280] carrying an AnotherName 
      of type id-pksan [3.2.2]. It further verifies that the 
      KRB5PrincipalName value MUST match the name of the TGS of the target
      realm.