Subject: RE: pkinit comments: confirming kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 8 Feb 2005 13:20:28 -0800

New proposal:

  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, it MUST verify the responder's identity as
   follows:

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

           _Service._Proto.Realm

        Where the Service name is the string literal "kerberos", the
       Proto can be "udp" or "tcp", and the Realm is the domain style
       Kerberos realm name [CLAR] of the target KDC.  This name format
       is identical to the owner label format used in the DNS SRV
       records for specifying the KDC location as described in [CLAR].
       For example, the X.509 certificate for the KDC of the Kerberos
       realm "EXAMPLE.COM" contains a dNSName value of
       "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".

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

       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.

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

   Matching rules used for the dNSName value are specified in [RFC3280].

   If all applicable checks are satisfied, the client then decrypts the
   enc-part field of the KDC-REP in the AS-REP using the KDC AS reply
   key, and then proceeds as described in [CLAR].

   Implementation note: CAs issuing KDC certificates SHOULD place all
   "short" and "fully-qualified" Kerberos realm names of the KDC (one
   per SAN extension) into the KDC certificate to allow maximum
   flexibility. 

Is there anybody who want to use the dNSName hostname or Ipaddress? We
would be happy to keep it around if anyone wants to use it but we do not
need it.

The reason for the "SHOULD" (instead of "MUST") (matching hostname or
Ipadress) is that the same KDC can host multiple realms.

Thanks,

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Leach
Sent: Monday, February 07, 2005 7:59 PM
To: Jeffrey Hutzelman; Nicolas Williams
Cc: Chaskiel M Grundman; [email-masked]
Subject: RE: pkinit comments: confirming kdc certificates

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: Monday, February 07, 2005 5:04 PM
> >>
> >> Note that realms do not have FQDN's; they have realm names.
> >> I would expect a suitable solution to this issue to support realms
with
> >> non-DNS-style realm names.
> >
> > Why?  Such realms would not be using DNS SRV RRs to find KDCs...
> 
> Because the issue is not "using DNS is bad".
> The issue is that Kerberos provides a way for a client to know if it
is
> talking to the legitimate AS for its realm, and as it stands, PKINIT 
> breaks that.  Unbreaking it only for DNS-style realms is insufficient.
[Paul Leach] I can' tell if I said that or Nicolas did. If I did, what I
meant to say was that the "_kerberos._tcp.Realm" approach didn't have to
work for non-domain realm names -- I did not mean to imply that a
solution for other realm name types wasn't needed. Larry will have a
proposal that addresses both domain and non-domain realm names shortly.

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Feb 2005 23:56:26 +0100 (MET)

>    2.  The client MUST accept the KDC's X.509 certificate if that

Ouch--this sounds awful.  We are engineers, not attourneys.

I would prefer something along the lines of :

      Clients should perform such-and-such checks

      if these checks succeed, the certificate is considered a
      valid KDC cert according to this specification.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Feb 2005 21:46:02 +0100 (MET)

Trying to clarify myself:

The wording "The client MUST accept" leaves no, zero, nil room for the client
to apply its own policy.

"The client MUST perform such-and-such checks"  is still ok,
but "The client MUST accept" would prohibit a communication peers to
reject the certificate (chain) based on some local policy (not necessarily
covered by this spec, e.g. a local "blacklist" of certificates that a peer
has chosen *NOT* to trust, even though everything looks good from the
PKI perspective.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Feb 2005 16:23:17 -0500

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