Subject: RE: pkinit comments: confirming kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 3 Feb 2005 12:24:04 -0800

Pointing out a difference:

The current text verifies the responder's identity.
Your proposed change ensures that what the client got back from the DNS
SRV query is authentic (the dNSName is the name of the KDC). 

Perhaps you do not really care if you wanted to talk with KDC1, but KDC2
(another KDC instance) of the same realm responded.

I think this is interesting, it should be used as an altercative for
checking dNSName, but not in conjunction, and perhaps it should also be
preferred over the dNSName approach.

The question is then whether this workgroup would accept this proposal?
Jeff?

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Thursday, February 03, 2005 11:30 AM
To: [email-masked]
Subject: RE: pkinit comments: confirming kdc certificates

--On Thursday, February 03, 2005 10:30:12 -0800 "Liqiang(Larry) Zhu"
<[email-masked]> wrote:

> Did you argue that these deployments would preconfigure Id-pksan?
Do I have to make this argument? id-pksan is the "default" mechanism for
confirming pkinit client certificates. Why shouldn't it be used as the
default mechanism to confirm kdc certificates? Note that I was not
specifically picking on windows. Recent heimdal and MIT krb5 are also
able to use SRV records to find kdc's,(...but presumably only where
krb5.conf does not define the kdcs for a given realm) I think that using
SRV records to find kdc's is a fine thing, as long as it does not reduce
security.

> Id-pksan alone does not give enough security assurance (what presents 
> any server in the realm from responding as the KDC),
'Any server in the realm' that isn't a kdc won't have a valid
certificate that claims to belong to krbtgt/REALM@REALM.

> rather, you can use
> it in conjunction with id-pkkdcekuoid (to get better assurance).
I was not suggesting that the EKU check be removed.

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 4 Feb 2005 11:43:27 -0800

> From: Chaskiel M Grundman
> Sent: Friday, February 04, 2005 10:48 AM
> 
> --On Friday, February 04, 2005 10:33:58 -0800 Paul Leach 
> <[email-masked]> wrote:
> 
> > If the realm isn't an FQDN, then it currently needs to be (and is) 
> > mapped to a KDC's host name by some local mechanism, which must be 
> > secure.
> 
> Where is the requirement that the mapping be secure? As I 
> said before, in traditional kerberos, the kdc is 
> authenticated by the client as part of the AS exchange, so 
> there's no need for a secure mapping.

The requirement is in existing implementation of PKINIT, which is the
context in which I was thinking at the time (but didn't make clear).
You're right that with password based Kerberos the mapping need not be
secure (although reuse of username/password in more than one realm would
lead to the inability to distinguish between KDCs of those realms, and
make the security of the mapping more important).

---

From: "Paul Leach" <[email-masked]>
Date: Mon, 7 Feb 2005 19:58:41 -0800

> 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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 18 Feb 2005 08:57:28 -0800

Eric Rosenfeld wrote:
> Can someone explain why the EKU extension with the value 
> pkkdcekuoid is required for KDC certificates? What purpose does 
> it serve?

The KDC EKU indicates to us that the certificate is for the KDC. This is
because the domain controller (the domain controller is the Microsoft
term for KDC) can have other services running on the same machine, we
need to distinguish if the certificate issued to the domain controller
is for the KDC or for other services. Does this make sense?

> Also, if the draft does require it (which I currently oppose), 
> then should the EKU extension be marked critical?

We currently do not have additional constrains for this EKU beyond what
is in RFC 3280. 

As specified by RFC 2480, EKU MAY, at the option of the certificate
issuer, be either critical or non-critical.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Rosenfeld
Sent: Sunday, February 13, 2005 2:18 PM
To: [email-masked]
Subject: RE: pkinit comments: confirming kdc certificates

Trying to catch up on all the threads for PKINIT. Can someone explain
why the EKU extension with the value pkkdcekuoid is required for KDC
certificates? What purpose does it serve? I am not familiar with the
arguments for it, so at this point I am opposed to requiring it. It
should be up to client policy.

Also, if the draft does require it (which I currently oppose), then
should the EKU extension be marked critical?

Perhaps this has been discussed in the past, or I missed it in -24. If
so, please point me in the correct direction.

-Eric

Eric S. Rosenfeld
Director, PacketCable Architecture
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750
Phone: 303-661-9100
Fax: 303-661-9199
Web: www.cablelabs.com
Email: [email-masked]
Direct Phone: 303-661-3841
Direct Fax: 303-664-8195

-----Original Message-----
From: Liqiang(Larry) Zhu [mailto:[email-masked]]
Sent: Wednesday, February 09, 2005 2:16 PM
To: Chaskiel M Grundman; [email-masked]
Subject: RE: pkinit comments: confirming kdc certificates

Chaskiel, the comments in the list were getting out of context, -24 was
aimed to make the discussion interesting therefore moving the draft
forward.

For this part, here is the text went into -24. we now shoot for last
call on -25, please take some time to comment and we will incorporate
changes as needed. Thanks. -- Larry

   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 satisfy at least
   one of the follow two requirements:

   1.  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" would contain a dNSName value of
       "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".

   2.  The 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.
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Wednesday, February 09, 2005 1:05 PM
To: [email-masked]
Subject: RE: pkinit comments: confirming kdc certificates

--On Wednesday, February 09, 2005 12:50:01 -0800 "Liqiang(Larry) Zhu"
<[email-masked]> wrote:

> I agree. -24 will reflect the sugguested adjustments.

Based on what consensus?