Subject: RE: pkinit comments: confirming kdc certificates

From: "Eric Rosenfeld" <[email-masked]>
Date: Sun, 13 Feb 2005 15:17:48 -0700

Trying to catch up on all the threads for PKINIT. Can someone explain
why the EKU extension with the value pkkdcekuoid is required for KDC
certificates? What purpose does it serve? I am not familiar with the
arguments for it, so at this point I am opposed to requiring it. It
should be up to client policy.

Also, if the draft does require it (which I currently oppose), then
should the EKU extension be marked critical?

Perhaps this has been discussed in the past, or I missed it in -24. If
so, please point me in the correct direction.

-Eric

Eric S. Rosenfeld
Director, PacketCable Architecture
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750
Phone: 303-661-9100
Fax: 303-661-9199
Web: www.cablelabs.com
Email: [email-masked]
Direct Phone: 303-661-3841
Direct Fax: 303-664-8195

-----Original Message-----
From: Liqiang(Larry) Zhu [mailto:[email-masked]] 
Sent: Wednesday, February 09, 2005 2:16 PM
To: Chaskiel M Grundman; [email-masked]
Subject: RE: pkinit comments: confirming kdc certificates

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: Sam Hartman <[email-masked]>
Date: Sun, 20 Feb 2005 17:43:16 -0500

>>>>> "Eric" == Eric Rosenfeld <[email-masked]> writes:

    Eric> Trying to catch up on all the threads for PKINIT. Can
    Eric> someone explain why the EKU extension with the value
    Eric> pkkdcekuoid is required for KDC certificates? What purpose
    Eric> does it serve? I am not familiar with the arguments for it,
    Eric> so at this point I am opposed to requiring it. It should be
    Eric> up to client policy.

It seems clear to me that we need an EKU for KDCs.  This will allow a
CA to say that a particular certificate is for a KDC or not.

we can adopt one of two strategies, both permitted by RFC 3280.

First, we can require an EKU.  That's more secure.  It means that an
arbitrary cert can never be mistaken as a KDC cert.  The problem with
doing so is that it may be difficult for some CAs to issue this EKU.

Alternatively we can say that clients MUST understand the EKU
extension and if the EKU extension is present the client MUST reject
the certificate if it does not contain a KDC EKU.  The advantage of
this is that it makes things easier for off-the-shelf CAs.  The
disadvantage is that if a CA includes no EKU extension at all, its
certificates are valid KDC certificates.  To restrict a certificate
and say the certificate is not a valid KDC cert, the CA must enumerate
all acceptable usages of the cert.

I guess one thing we could potentially do and that you might even
encourage us to do is to allow support for EKU checking to be an
optional client feature.  I am personally opposed to that approach as
it seems like it would lead to potential security problems because for
such clients there is no way to say that a cert is clearly not a KDC
cert.

I disagree with you that this should be a matter for client policy; I
believe that is dangerous both from a security and interoperability
standpoint.

--Sam