Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 26 Aug 2005 19:58:10 -0700

Paul suggested the following text after consolidating approach 1 and approach 2.

------------------
   If the KDC's certificate is certified by a CA as a KDC certificate
   for a target ream (for example, by asserting the TGS name of that
   Kerberos realm as an id-pksan SAN and/or restricting the certificate
   usage by using the id-pkkdcekuoid EKU, as described in
   Section 3.2.4), the KDC certificate's CA MUST be authorized to issue
   KDC certificates for that target realm.  Otherwise, the binding
   between the KDC certificate and the KDC of the target realm is not
   established.  

   To achieve this, local policy should specify a set of
   trust anchors for KDC certificates, and the client must verify that
   the KDC's leaf certificate is path validated [RFC3280] to an anchor
   in this set.  Each CA in the certification path between the KDC
   certificate and the trust anchor should have name constraints applied
   to it that specify for which realms it is allowed to issue KDC
   certificates.

------------------

Please comment.

Thanks,

-- Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Liqiang(Larry) Zhu
Sent: Friday, August 26, 2005 6:16 PM
To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Updated with Paul and Stefan's suggestion:

===================================
If the KDC certificate is certified by a CA as a KDC certificate for the target ream (for example, the CA can indicate the certificate is a KDC certificate of a Kerberos realm by asserting the TGS name of that Kerberos realm as id-pksan SAN and/or restricting the certificate usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC certificate's CA MUST be authorized to issue KDC certificates for that target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established. The means by which the client authorizes a CA for such purpose can be one of the following:

1. Local policy can specify which CAs are allowed to issue KDC certificates, and for each one name constraints should define for which realms it is allowed to issue them.

2. The client can keep a list of trust anchors for each Kerberos realm it can contact (this list may be specific to KDC certificate issuance) and validate that the KDC's leaf certificate is path validated [RFC3280] to a trust anchor in the trust anchor list for the target realm.

===================================
Comments?

-- Larry

________________________________________
From: Paul Leach 
Sent: Friday, August 26, 2005 5:26 PM
To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

If the following text is to go into the security considerations section, then I don't buy the last line:

"If a client accepts a certificate as a KDC certificate of the target realm without a priori knowledge, for example by using id-pksan SAN and/or the presence of the id-pkkdcekuoid EKU as described in Section 3.2.4, it MUST verify  that the KDC certificate's CA is authorized to issue KDC certificates for the target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established. The means how to authenticate and authorize a CA for such purpose is outside the scope of this specification."

The security considerations section needs to point out ways in which it is possible to insecurely use a protocol.

Some things that people SHOULD do to make sure that KDC are authentic include:
1. Local policy should specify which CAs are allowed to issue KDC certs, and for each one name constraints should define for which realms it is allowed to issue them
2. Keep a list of trust anchors (which may be specific to KDC cert issuance) and validate that the KDC's leaf cert chains up to a trust anchor.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sat, 27 Aug 2005 06:50:11 +0200

"Liqiang(Larry) Zhu" <[email-masked]> writes:

>    Section 3.2.4), the KDC certificate's CA MUST be authorized

by local policy

>    to issue

Other then that, the text seem fine to me.

Love