Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 27 Aug 2005 21:16:17 +0100

This looks OK to me.

However, to be picky I would change the last sentence to:

"In addition, name constraints [RFC 3280] may be applied to constrain for which realms a CA is allowed to issue KDC certificates."

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 27 augusti 2005 20:23
> To: Stefan Santesson; Paul Leach; Jeffrey Hutzelman; Sam Hartman
> Cc: [email-masked]; [email-masked]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
> 
> 
> s/determine/verify/
> 
> I also would like to make this understandable by Kerberos developers, not
> just target at PKI experts.
> 
> ----------------------
> 
> "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. Typical
> ways to achieve this is includes configuration of specific sets of
> intermediary CAs and trust anchors, one of which must be on KDC
> certificate's certification path [RFC 3280]. In addition, name constraints
> [RFC 3280] may be applied that specify for which realms a CA is allowed to
> issue KDC certificates."
> 
> --------------------
> 
> This text is very explicit and plain about what is the requirements; can
> you help to verify if I have fixed all inaccuracies you pointed out below?
> 
> Thanks,
> 
> -- larry
> 
> -----Original Message-----
> From: Stefan Santesson
> Sent: Saturday, August 27, 2005 2:51 AM
> To: Liqiang(Larry) Zhu; Paul Leach; Jeffrey Hutzelman; Sam Hartman
> Cc: [email-masked]; [email-masked]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
> 
> This is definitely an improvement, but I'm still not satisfied :)
> 
> We should not be specific about any requirements on how to configure trust
> in a particular CA since it can be done in many valid ways.
> 
> You definitely do NOT have to have specific trust anchors for KDC
> certificates and you not have to apply name constraints. And if you apply
> name constraints it is never applied by all CAs in the path.
> 
> A perfectly valid example is if you have the KDC certificate chaining to a
> more generic root/TA while clients are configured to require a certain KDC
> specific intermediary CA (under that root/TA) to be present in the path.
> 
> I suggest some hopefully minor changes to the text:
> 
> "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 determine 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. Typical
> ways to achieve this is includes configuration of specific sets of trust
> anchors and intermediary CAs, possibly supported by name constraints,
> which have to be utilized in the certificate validation process according
> to RFC 3280."
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: Liqiang(Larry) Zhu
> > Sent: den 27 augusti 2005 04:58
> > To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> >
> > 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:owner-ietf-krb-
> > [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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 27 Aug 2005 16:52:26 -0700

I agree. thanks Stefan.
 
Put everything together, here is what we have now:
------------------------------------

How to validate this authorization is a matter of local policy. Typical 
ways to achieve this is includes configuration of specific sets of 
intermediary CAs and trust anchors, one of which must be on the KDC 
certificate's certification path [RFC 3280]. In addition, name constraints 
[RFC 3280] may be applied to constrain for which realms a CA is 
allowed to issue KDC certificates" 
----------------------------
 
comments please?
 
-- Larry

________________________________

From: Stefan Santesson
Sent: Sat 8/27/2005 1:16 PM
To: Liqiang(Larry) Zhu; Paul Leach; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

This looks OK to me. 

Stefan Santesson

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 20:09:16 -0400

On Saturday, August 27, 2005 04:52:26 PM -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> 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.
>
> certificate's certification path [RFC 3280]. In addition, name
> constraints  [RFC 3280] may be applied to constrain for which realms a CA
> is

<wg chair hat off>

I've been following this discussion somewhat, and the above looks fine to 
me (except s/ream/realm/, which I already mentioned to Larry off-list).  I 
agree the issue is an important one, and this seems to resolve it.

<wg chair hat on>

Now, I've seen lots of discussion from Larry and Stefan, with an occasional 
comment by Love and Paul Leach.  I'd like to see comments from other WG 
members either indicating support for this text, or calling out any 
remaining problems.

-- Jeff