Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Paul Leach" <[email-masked]>
Date: Thu, 1 Sep 2005 12:30:57 -0700

I propose the following text, which I think meets everyone's fundamental
objections (but which of course might have errors):
=====================================================
There are two sets of security considerations relevant to PKINIT: one
for the client and one for the administrators of the PKI for an
organization.

In order to trust a KDC certificate that 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 client MUST verify that the KDC certificate's
issuing CA is 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.

How to validate this authorization is a matter of local policy. A way to
achieve this is the configuration of specific sets of intermediary CAs
and trust anchors, one of which must be on the KDC certificate's
certification path [RFC 3280]; and for each CA or trust anchor the
realms for which it is allowed to issue certificates.

In addition, if any CA is trusted to issue KDC certificates can also
issue other kinds of certificates, then local policy must be able to
distinguish between them: for example, it could require that KDC
certificates contain the id-pkkdcekuoid EKU or that the realm be
specified with the id-pksan SAN.

It is the responsibility of the PKI administrators for an organization
to ensure that KDC certificates are only issued to KDCs, and that
clients can ascertain this using their local policy. This leads to the
following considerations.

If there is more than one CA that can issue KDC certificates, and the
organizations running those CAs do not fully trust one another, then
name constraints [RFC 3280] should be used to limit the realms for which
each CA can issue KDC certificates. This will reduce the reliance on
local policy being correct in this regard. (Note: currently, name
constraints can only be used with the dNSName SAN, because only for it
are name constraint matching rules defined at the time of writing.)

If any CA can issue certificates for both KDCs and other purposes, then
it must guarantee that the two kinds can be differentiated. To do this,
it could either issue certificates containing the id-pkkdcekuoid EKU, or
specify the realm using the id-pksan SAN. (Other means of doing this may
exist in the future and would also be acceptable.)

In addition, CAs that the PKI administration does not trust to issue KDC
certificates should be constrained from issuing certificates containing
the id-pkkdcekuoid EKU or the id-pksan SAN.

Finally, local policy should only configure a trust anchor for KDC
certificate issuance if the administrators of that anchor observe the
above considerations.
====================================================
The above text would be improved by giving an example of how to
constrain CAs not trusted by the PLI admins to issue KDC certs from
doing so.

Comments?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Sep 2005 16:23:08 -0400

Speaking mostly without the chair hat...

On Thursday, September 01, 2005 12:30:57 -0700 Paul Leach 
<[email-masked]> wrote:

These two paragraphs appear to say almost the same thing in slightly 

> exist in the future and would also be acceptable.)

I think only one of these is needed, and I prefer the latter.

> are name constraint matching rules defined at the time of writing.)

<chair hat on>
To date, the only name type called out explicitly by PKINIT for KDC certs 
is the KRB5PrincipalName SAN, for which name constraint semantics are not 
defined.  There is an open consensus call on the question of whether other 
name forms should be specified, and dNSName was one of those postulated. 
My presumption in issuing that call was that the consensus would be that no 
other name forms needed to be specified; if you disagree with that 
presumption you need to make that clear so we can talk about it.
</chair hat on>

If we do decide to specify use of dNSName, your Note should be amended to 
indicate that it is the only form _of those specified for use with PKINIT_ 
for which name constraints are defined.

If we do not decide to specify use of dNSName, then even that statement 
would not be true.  I would suggest that in this case, the Note should not 
mention the use of dNSName, since that would not be specified.  Instead, it 
would have to make some note about name constraints not currently being 
defined for KRB5DNSName, and that constraints would thus only be suitable 
for name forms for which a local policy was in place.

Or, we could instead specify that there must be _some_ means of 
distinguishing which CA's are authorized for which realms, and perhaps 
mention name constraints as one way of doing this.

> the id-pkkdcekuoid EKU or the id-pksan SAN.

Can you constrain a CA from issuing a particular SAN type?  How?

Also, I don't believe this is good advice.  CA's which are trusted to issue 
client certs but not KDC certs should still be permitted to issue the 
id-pksan SAN.  They simply should not be configured to be treated by 
clients as trust anchors for KDC certs.  If you believe this is 
insufficient, then perhaps we do need to define the name constraint 
semantics, so it is possible to allow a CA to issue client certs while 
constraining it from issuing KDC certs.