Subject: RE: pkinit comments: confirming kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 9 Feb 2005 16:45:41 -0800

For approach #1:

I chatted with Sam off-list and he asked me to post the rationales for
the dNSName proposal.

It is a requirement that we find some solution that allows existing CAs
to deploy pkinit.

by using the dNSName SAN extension with the "_kerberos._tcp" prefix, we
accomplish two goals: 1) we avoid the KDC EKU so that we do not require
all CAs to be upgraded, 2) we use the _kerberos._tcp prefix (an encoding
violation) to reduce the chance for administrators to issue a KDC
certificate by mistake. 

For approach #2: I will continue to discuss with Sam to understand why
the KDC EKU check plus the realm name matching are not sufficient.

Thanks,

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, February 09, 2005 1:23 PM
To: Liqiang(Larry) Zhu
Cc: Paul Leach; Jeffrey Hutzelman; Nicolas Williams; Chaskiel M
Grundman; [email-masked]
Subject: Re: pkinit comments: confirming kdc certificates

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

    Liqiang(Larry)>    1.  The client MUST accept the KDC's X.509
    Liqiang(Larry)> certificate if the certificate contains a Subject
    Liqiang(Larry)> Alternative Name (SAN) extension carrying a
    Liqiang(Larry)> dNSName and that name value matches the following
    Liqiang(Larry)> name format:

    Liqiang(Larry)> _Service._Proto.Realm I am not comfortable taking a
document which overloads service lookup labels as part of a
certificate's name.  I strongly object to this approach.

    Liqiang(Larry)> "_kerberos._udp.EXAMPLE.COM".

    Liqiang(Larry)>    2.  The client MUST accept the KDC's X.509
    Liqiang(Larry)> certificate if that certificate contains the EKU
    Liqiang(Larry)> KeyPurposeId [RFC3280] id-pkkdcekuoid (defined
    Liqiang(Larry)> below) and an SAN extension [RFC3280] carrying an
    Liqiang(Larry)> AnotherName whose type-id is id-pksan (as defined
    Liqiang(Larry)> in Section 3.2.2) and whose value contains a
    Liqiang(Larry)> KRB5PrincipalName name, and the realm name of that
    Liqiang(Larry)> KRB5PrincipalName matches the realm name of the
    Liqiang(Larry)> target KDC.

I think this check is too weak.  I think you should specify the full
principal name (TGS) or invent a new othername type.

    Liqiang(Larry)>         If no SAN id-pksan extension is present
    Liqiang(Larry)> (but the id-pkkdcekuoid EKU is) in the KDC's X.509
    Liqiang(Larry)> certificate, and the client has a priori knowledge
    Liqiang(Larry)> of the KDC's hostname (or IP address), the client
    Liqiang(Larry)> SHOULD accept the KDC's X.509 certificate if that
    Liqiang(Larry)> certificate contains an SAN extension carrying a
    Liqiang(Larry)> dNSName and the dNSName value matches the hostname
    Liqiang(Larry)> (or the IP address) of the KDC with which the
    Liqiang(Larry)> client believes it is communicating.

I'm not really very happy about this.  It seems like it will create too
many configuration problems to have things sometimes work depending on
how clients learn about a KDC.

--Sam

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 09 Feb 2005 20:49:20 -0500

> It is a requirement that we find some solution that allows existing CAs

absolutely

> violation) to reduce the chance for administrators to issue a KDC

using the DNS SRV format here is simply not good idea.  dNSName is a 
field controlled by a group other then ourselves.  The purpose of that
field is for use with legal DNS A-record names.  I would not feel at all
comfortable with breaking that usage.

I would be much happier with something like

	ATHENA.MIT.EDU.KERBEROS5

which is legal notation but is never going to match a TLD.  However,
even with this approach I would not feel comfortable going ahead with 
it, without first raising it with the IAB and the representative to ICANN.

Jeffrey Altman