Subject: RE: pkinit comments: confirming kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 9 Feb 2005 13:16:08 -0800

Chaskiel, the comments in the list were getting out of context, -24 was
aimed to make the discussion interesting therefore moving the draft
forward.

For this part, here is the text went into -24. we now shoot for last
call on -25, please take some time to comment and we will incorporate
changes as needed. Thanks. -- Larry

   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,  the KDC's X.509 certificate MUST satisfy at least
   one of the follow two requirements:

   1.  The certificate contains a Subject Alternative Name (SAN)
       extension carrying a dNSName and that name value matches the
       following name format:

           _Service._Proto.Realm

        Where the Service name is the string literal "kerberos", the
       Proto can be "udp" or "tcp", and the Realm is the domain style
       Kerberos realm name [CLAR] of the target KDC.  This name format
       is identical to the owner label format used in the DNS SRV
       records for specifying the KDC location as described in [CLAR].
       For example, the X.509 certificate for the KDC of the Kerberos
       realm "EXAMPLE.COM" would contain a dNSName value of
       "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".

   2.  The certificate contains the EKU KeyPurposeId [RFC3280]
       id-pkkdcekuoid (defined below) and an 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.

       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.

        If no SAN id-pksan extension is present (but the id-pkkdcekuoid
       EKU is) in the KDC's X.509 certificate, and the client has a
       priori knowledge of the KDC's hostname (or IP address), the
       client SHOULD accept the KDC's X.509 certificate if that
       certificate contains an SAN extension carrying a dNSName and the
       dNSName value matches the hostname (or the IP address) of the KDC
       with which the client believes it is communicating.

   Matching rules used for the dNSName value are specified in [RFC3280].

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

   Implementation note: CAs issuing KDC certificates SHOULD place all
   "short" and "fully-qualified" Kerberos realm names of the KDC (one
   per SAN extension) into the KDC certificate to allow maximum
   flexibility.
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Wednesday, February 09, 2005 1:05 PM
To: [email-masked]
Subject: RE: pkinit comments: confirming kdc certificates

--On Wednesday, February 09, 2005 12:50:01 -0800 "Liqiang(Larry) Zhu"
<[email-masked]> wrote:

> I agree. -24 will reflect the sugguested adjustments.

Based on what consensus?

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 09 Feb 2005 16:41:10 -0500

>        "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".

Boy is that complex.  Why don't we just use a new SubjAltName type 
called "Kerberos5Realm" and place the REALM name in it.

>               -- Key usage bits that MUST be consistent:

Shouldn't the principal name be a fixed name such as

	kdc/fqdn@REALM

in order to ensure that the certificate matches the service and hostname?

>        with which the client believes it is communicating.

ok.

>    per SAN extension) into the KDC certificate to allow maximum

Are short names a good idea?

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Feb 2005 15:43:40 -0600

> called "Kerberos5Realm" and place the REALM name in it.

And why should transport protocol names be part of the cert
name/altname??

> >       with which the client believes it is communicating.

And the client should be able to have the KDC certs pre-shared to it.

> Are short names a good idea?

No.