Subject: RE: pkinit comments: confirming kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 6 Feb 2005 18:41:11 -0800

Chaskiel's proposal looks basically good. But I would suggest the
following text. The improvements are outlined below the new text.

   In either case, the client MUST verify the signature in the
   SignedData according to [RFC3852].  Unless the client can otherwise
   prove that the public key used to verify the KDC's signature is bound
   to the target KDC, it MUST verify the responder's identity as
   follows:

   1.  The KDC's X.509 certificate MUST contain the EKU KeyPurposeId
      [RFC3280] id-pkkdcekuoid:

       id-pkkdcekuoid OBJECT IDENTIFIER ::=
         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
           pkinit(3) pkkdcekuoid(5) }
              -- Signing KDC responses.
              -- Key usage bits that MUST be consistent:
              -- digitalSignature.

   2.  The KDC's X.509 certificate MUST contain a Subject Alternative
      Name (SAN) extension [RFC3280] carrying an AnotherName whose
      type-id is id-pksan (as defined in Section 3.2.2) and whose value
      contains a KRB5PrincipalName name, and the realm name of that
      KRB5PrincipalName matches the realm name of the target KDC.  If no
      such SAN extension is present in the KDC's certificate, the client
      SHOULD accept the KDC's certificate as meeting this requirement if
      the KDC's X.509 certificate contains an SAN extension carrying a
      dNSName and that name value matches the domain style realm name
      [CLAR] of the target KDC.  The KDC's certificate SHOULD also be
      accepted if it contains an SAN extension carrying a dNSName or an
      iPAddress (if the KDC is specified by an IP address instead of a
      name) and that name value matches the hostname or the IP address
      of the KDC that the client is communicating with.  If the KDC's
      hostname or IP address is used for matching, it MUST have been
      obtained securely.  Matching rules using the dNSName value are
      specified in [RFC3280].

      Implementation note: CAs issuing KDC certificates SHOULD place all
      "short" and "fully-qualified" realm names of the KDC (one per SAN
      id-pksan extension) into the KDC certificate to allow maximum
      flexibility.

   If all applicable checks are satisfied, the client then decrypts the
   enc-part of the KDC-REP in the AS-REP with the reply key, and then
   proceeds as described in [CLAR].

Why this is more preferable:
1) The KDC's certificate is issued to a specific KDC instance, not for a
shared principal name, such as the target
TGS name suggested by Chaskiel.
2) Enterprise admins have experiences and tools dealing with dNSName,
they can place the domain name in a dNSName extension with minimal
effort.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Sunday, February 06, 2005 4:35 PM
To: [email-masked]
Subject: Re: pkinit comments: confirming kdc certificates

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 07 Feb 2005 20:07:22 -0500

> following text. The improvements are outlined below the new text.

This is ticket #837.

I consider this a critical security flaw in PKINIT which _MUST_ be 
corrected before I will ask Sam to take the document to the IESG.

Both Chaskiel and Larry have now proposed text to address this issue.
I would like to see comments and discussion from the rest of the WG
on these proposals.

-- Jeff