Subject: RE: pkinit comments: confirming kdc certificates

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

Chaskiel M Grundman wrote:
> an increasing number of kerberos deployments do not preconfigure kdc
hostnames.

Did you argue that these deployments would preconfigure Id-pksan?

Id-pksan alone does not give enough security assurance (what presents
any server in the realm from responding as the KDC), rather, you can use
it in conjunction with id-pkkdcekuoid (to get better assurance).

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Wednesday, February 02, 2005 5:49 PM
To: [email-masked]
Subject: pkinit comments: confirming kdc certificates

The existing text's description of how to confirm a kdc certificate in
the PA-PK-AS-REP focuses on making sure that the certificate is bound to
the hostname or IP address of the target KDC. 
However, an increasing number of kerberos deployments do not
preconfigure kdc hostnames. They instead rely on (insecure) DNS to find
the identity of the kdc's for a given realm. When traditional AS/TGS
exchanges are used, this is safe, because the AS (and cross-realm TGS)
exchange authenticates the kdc to the client (because only the client
and the kdc know the correct key). When pkinit (or pkcross) become
involved, this is no longer true.

I think it would be appropriate to bind the certificate to the kerberos
realm (perhaps by using a SubjectAltName of type id-pksan containing the
TGS name of the target realm) instead of or in addition to the target
kdc.

---

From: Chaskiel M Grundman <[email-masked]>
Date: Thu, 03 Feb 2005 14:30:23 -0500

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

> 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
I was not suggesting that the EKU check be removed.