Subject: PKINIT-26 changes: identifying the kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 20 May 2005 04:43:12 -0700

Recently Stefan has proposed to define a Subject Alternative Name
extension contains the DNS SRV records. Using this extension the client
can bind the KDC certificate to the KDC of the target realm.

Stefan is expected to publish his proposal shortly and request the PKIX
working group to accept his ID as a working group document.

Based on this development, we would like to withdraw our proposal of
using _Kerberos._tcp dNS name to identify KDC certificates.

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.
   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].

   Future work within the PKIX working group is expected to define an
   X.509 certificate extension that allows a certificate subject to be
   associated with a DNS Service Resource Record.  This extension can be
   used to identify the KDC certificate when the KDC is discovered via
DNS
   based on the domain style realm name, as specified in Section 7.2.3.2
   of [CLAR].

   Based on local policy, the client MAY require that the KDC
   certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:

<< cut >>

And in the security consideration section, I would propose to add the
following text:

   If the KDC certificate is identified using a dNS name or iPAddress,
   and the same KDC host could provide services more than the KDC of the
   target realm, the client MUST ensure the KDC certificate is intended
   for the KDC of the target realm, for example by requiring the
   presence of id-pkkdcekuoid KDC EKU.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 May 2005 15:20:39 -0400

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

    Liqiang(Larry)>    In either case, the client MUST verify the
    Liqiang(Larry)> signature in the SignedData according to
    Liqiang(Larry)> [RFC3852].  Unless the client can otherwise prove
    Liqiang(Larry)> that the public key used to verify the KDC's
    Liqiang(Larry)> signature is bound to the target KDC, the KDC's
    Liqiang(Larry)> X.509 certificate MUST be validated according to
    Liqiang(Larry)> [RFC3280] and it MUST satisfy at least one of the
    Liqiang(Larry)> following requirements:

    Liqiang(Larry)>    1.  The client checks to see if the KDC's X.509
    Liqiang(Larry)> certificate contains a Subject Alternative Name
    Liqiang(Larry)> extension [RFC3280] carrying an AnotherName whose
    Liqiang(Larry)> type-id is id-pksan (as defined in Section 3.2.2)
    Liqiang(Larry)> and whose value is a KRB5PrincipalName that
    Liqiang(Larry)> matches the name of the TGS of the target realm.

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

My preference is that this option be dropped.  If it is retained I think   we need explicit text mentioning that it should not be used if the KDC is located via DNS SRV records.

    Liqiang(Larry)>    Future work within the PKIX working group is
    Liqiang(Larry)> expected to define an X.509 certificate extension
    Liqiang(Larry)> that allows a certificate subject to be associated
    Liqiang(Larry)> with a DNS Service Resource Record.  This
    Liqiang(Larry)> extension can be used to identify the KDC
    Liqiang(Larry)> certificate when the KDC is discovered via DNS
    Liqiang(Larry)> based on the domain style realm name, as specified
    Liqiang(Larry)> in Section 7.2.3.2 of [CLAR].

This text requires a normative reference to that extension.
Personally I think that it is premature to mention the PKIX work at
all.  If you plan to mention the pkix work and have it be useful for
pkinit you must either:

1) normatively reference it in the pkinit spec

2) Define the pkinit use in another document--possibly the document that defines the name form in pkix.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 May 2005 16:31:42 -0500

> 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.

>        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."  :)

>        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
--