Subject: EKU considerations for KDC certificates

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 Aug 2005 17:48:18 -0400

On Monday, August 01, 2005 03:53:36 PM +0200 Jeffrey Hutzelman 
<[email-masked]> wrote:

> It seems to me that in any given situation, we can do one of the
> following:
>
> (å) Require the Kerberos KDC EKU to be present
> (ä) Require the Kerberos KDC EKU, or the "any" EKU, or no EKU extension.
> (ö) Make no requirements on the EKU extension or presence thereof.
>
> I believe we have consensus that if rule 1a is satisfied, then we need
> not have any EKU requirements.  The disagreement is as to what happens in
> cases where rule 1a is _not_ satisfied.  For this situation, all three of
> the above choices have been proposed.  We need to decide which is
> appropriate, in order to resolve this ticket.
>
> I'm not going to attempt to summarize the arguments for each of choices
> Å, Ä, and Ö (alternately, AA, AE, OE).  Instead, I will ask the
> proponents of each choice to make their arguments.

On further reflection, it seems to me that RFC3280 places option ö out of 
consideration; it says "If the extension is present, then the certificate 
MUST only be used for one of the purposes indicated."

So now we really have two orthogonal questions:

I.  Do we define an EKU at all?  If not, then the presence of an EKU
    extension will prevent a certificate from being used for a PKINIT
    KDC unless the anyExtendedKeyUsage keyPurposeID is present, per
    the rules in RFC3280.

II. Under what circumstances do we _require_ our EKU to be present?
    It seems to me that some possible choices are:
    (A) always
    (B) always, unless test 1a is met (or some other non-EKU test we add)
    (C) always, unless the implementation knows by some other means
        that this certificate is intended for a Kerberos KDC
    (D) only if the implementation feels like it
    (E) never

Note that if the answer to (II) is anything other than 'E', that pretty 
much forces the answer to (I) to be 'yes' -- we can't require a particular 
keyPurposeID if we don't define one.

Now I'm going to take off my chair hat for a few minutes...

==========

First of all, I think it's pretty straightforward that the answer to 
question (I) should be 'yes'.  Even if we choose never to require its 
presence and not to allow implementations to require its presence, defining 
such an ID makes it possible to produce a certificate which can be used 
_only_ for a KDC, and as a general rule I believe it's desirable to be able 
to restrict certificates to particular applications.  Further, we've 
_already_ allocated an OID for this and defined it in the document, so it's 
not like there's actually any work to be done here.

The real meat of the issue is in question (II).

Personally, I believe that a certificate should be accepted as belonging to 
a Kerberos KDC only if it is clear that it is intended for that use.  That 
pretty much eliminates options 'D' and 'E', which either allow or require 
the implementation to accept certificates which do not meet this test. 
Further, I think we already have agreement that satisfying rule 1a is 
sufficient to prove the certificate is intended for a KDC, and so no EKU 
should be required in that case.

That leaves us with choices 'B' and 'C'.  The real, fundamental difference 
between these choices is whether we specify up front all the possible means 
by which a cert can be determined to be "good enough" (choice 'B'), or 
whether we leave it up to the implementor to determine that, based on 
considerations like policy or reading other specifications (choice 'C').

I find either of these choices acceptable, but I'm going to argue for 
choice 'C', which amounts to trusting implementors to look at the whole 
picture, which we cannot hope to see within the scope of this one document.

I can certainly think of other non-EKU tests.  One is by adding support for 
Stefan's "SRV RR" SAN, which is currently a work item of the PKIX working 
group, but will not be done in time for PKINIT to reference it.  Another, 
which I expect to be fairly widely deployed, is for the client to already 
have a trusted copy of the KDC's certificate.  Still another is the use of 
a dedicated CA for signing KDC certificates.  Who's to say that there won't 
be other methods down the line that we haven't thought of.

I'm much happier with a requirement like "the EKU MUST be present unless 
some other means is used to verify that the certificate is intended for use 
by a KDC" than with one like "the EKU MUST be present unless one of these 
two conditions we happened to think of is met".

==========

OK, chair hat back on.  We need resolution on this issue.  Until we reach a 
consensus, PKINIT cannot move forward.  We cannot reach a consensus if no 
one says anything.  So let's have some discussion, please...

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Aug 2005 13:10:37 -0400

Hi.  I got a chance to talk to Russ yesterday about this issue.

The main question is whether Russ was OK with option (c).  I believe
I've convinced him that is acceptable.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 19 Aug 2005 14:25:15 -0400

> I've convinced him that is acceptable.

Excellent.  Now, if only we had something resembling a consensus, we could 
move forward.  Unfortunately, I can't really characterize a deafening 
silence as "consensus".   Comments, please?

The current text in PKINIT looks like this:

>    Based on local policy, the client MAY require that the KDC
>    certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
>
>        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.

This describes option (d), in which the implementation can require the EKU 
if it feels like it.  If we decide to go with another option, we will need 
replacement text to describe it.  While we're waiting for people to speak 
up and say which option(s) they support, I'd like a volunteer to write up 
new text for options (b) and/or (c).

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 19 Aug 2005 16:17:52 -0400

Jeffrey Hutzelman wrote:

> I can certainly think of other non-EKU tests.  One is by adding support
> for Stefan's "SRV RR" SAN, which is currently a work item of the PKIX
> working group, but will not be done in time for PKINIT to reference it. 
> Another, which I expect to be fairly widely deployed, is for the client
> to already have a trusted copy of the KDC's certificate.  Still another
> is the use of a dedicated CA for signing KDC certificates.  Who's to say
> that there won't be other methods down the line that we haven't thought of.
> 
> some other means is used to verify that the certificate is intended for
> use by a KDC" than with one like "the EKU MUST be present unless one of
> these two conditions we happened to think of is met".

I will support this decision.

Jeffrey Altman

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 26 Aug 2005 18:34:23 +0200

>         that this certificate is intended for a Kerberos KDC
...
>
> OK, chair hat back on.  We need resolution on this issue.  Until we
> reach a consensus, PKINIT cannot move forward.  We cannot reach a
> consensus if no one says anything.  So let's have some discussion,
> please...

I thought the problem was solved by using requiring the SAN id-pksan in the
KDC certificate with the TGS of the target realm. Am I missing something ?

c is fine with me.

Love

---

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

I support approach C.

________________________________

From: [email-masked] on behalf of Love Hörnquist Åstrand
Sent: Fri 8/26/2005 9:34 AM
To: Jeffrey Hutzelman
Cc: [email-masked]
Subject: Re: EKU considerations for KDC certificates

...

c is fine with me.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 19:49:17 -0400

On Wednesday, August 17, 2005 05:48:18 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> much forces the answer to (I) to be 'yes' -- we can't require a
> particular keyPurposeID if we don't define one.

OK.  Based on comments received in reply to this, and on discussion at the 
WG meeting, I'm declaring consensus on option "C".  To implement this, 
Larry has proposed making the following change in section 3.2.4:

-   Based on local policy, the client MAY require that the KDC
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
    certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:

Do we think this is sufficient?  Do we need to call out explicitly that 
presence of the KRB5PrincipalName SAN satisfies this requirement, and that 
an EKU is not required in that case?

-- Jeff