Subject: RE: PKINIT-26 changes: identifying the kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 May 2005 15:53:35 -0700

The use of EKU is orthogonal to the names and at Minneapolis people were
telling me that it is not sufficient to require an EKU in order for
PKINIT to be secure, because a lot of CAs out there just do not know how
to deal with EKUs.  

I do not think there is consensus on using the DNS domain style realm
name with the KDC EKU.

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, May 23, 2005 2:32 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Stefan Santesson
Subject: Re: PKINIT-26 changes: identifying the kdc certificates

On Fri, May 20, 2005 at 04:43:12AM -0700, Liqiang(Larry) Zhu wrote:
> Based on this development, we would like to withdraw our proposal of
> using _Kerberos._tcp dNS name to identify KDC certificates.

Yes, please.  Also, I'd like to revive a proposal of Sam's: KDC certs
with a dNSName that correspond to the requested realm and which have
the id-pkkdcekuoid EKU.

> Here is the updated section 3.2.4.
> 
> 
> 3.2.4  Receipt of KDC Reply
> 
> << cut >>
> 
>    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 be validated
>    according to [RFC3280] and it MUST satisfy at least one of the
>    following requirements:
> 
>    1.  The client checks to see if the KDC's X.509 certificate
contains
>        a Subject Alternative Name extension [RFC3280] carrying an
>        AnotherName whose type-id is id-pksan (as defined in
>        Section 3.2.2) and whose value is a KRB5PrincipalName that
>        matches the name of the TGS of the target realm.

Yes.  Note that you yourself referred to the "name of the TGS of the
target realm."  :)

>    2.  If the client has a priori knowledge of the KDC's name or IP
>        address, it checks to see if the KDC's X.509 certificate
contains
>        a Subject Alternative Name extension [RFC3280] carrying a
dNSName
>        or an iPAddress.  If so, it checks to see if that name value
>        matches that of the KDC it believes it is communicating with,
>        with matching rules specified in [RFC3280].

I prefer the approach I mentioned above.

Also, note that this amounts to requiring support for all of these
alternatives, (1) and (2).  I'm not sure that this is clear in the text,
though it is clear to me (how could it not, after this grueling e-mail
marathon over this topic).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 May 2005 17:59:25 -0500

> PKINIT to be secure, because a lot of CAs out there just do not know how

Oh right.  Did we ever confirm that?

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 May 2005 23:52:51 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, May 23, 2005 at 03:53:35PM -0700, Liqiang(Larry)
    Nicolas> Zhu wrote:
    >> The use of EKU is orthogonal to the names and at Minneapolis
    >> people were telling me that it is not sufficient to require an
    >> EKU in order for PKINIT to be secure, because a lot of CAs out
    >> there just do not know how to deal with EKUs.

    Nicolas> Oh right.  Did we ever confirm that?

EKU is clearly efficient to be secure.  It just may not be sufficient
to actually produce a working product if the CAs do not support it.

Who was telling you that EKU was not implemented?  I thought you were
telling us that; let's make sure we did not get wires crossed
somewhere and that there is actually someone who believes EKU is not
sufficient.