Subject: RE: pkinit comments: confirming kdc certificates

From: "Paul Leach" <[email-masked]>
Date: Thu, 3 Feb 2005 15:02:14 -0800

IMO, the KDC's cert should be a server cert, not a client cert. Similar
to the cert used by a web server, except that instead of the host FQDN,
it should contain the realm FQDN and the id-pkkdcekuoid.

Alternatively, the FQDN could be name used in the SRV record lookup:
i.e., of the form _tcp._kdc.realm (if I remember the SRV RFC correctly).

-----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: Love <[email-masked]>
Date: Fri, 04 Feb 2005 14:32:59 +0100

I think either of _tcp._kerberos.f.q.d.n or or a server-cert with the name
of the realm would be fine, with preferance to the later.

I think it also should be combined with hostname/ipaddress.

Doing hostname/ipaddress based authentisation inconvenient.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 04 Feb 2005 10:58:37 -0500

> i.e., of the form _tcp._kdc.realm (if I remember the SRV RFC correctly).

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.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Feb 2005 10:39:44 -0600

> non-DNS-style realm names.

Why?  Such realms would not be using DNS SRV RRs to find KDCs...

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 07 Feb 2005 20:04:14 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Feb 2005 23:57:05 -0600

> that.  Unbreaking it only for DNS-style realms is insufficient.

My point is that clients not using DNS to find the KDC could be told to
rely on pre-sharing of KDC certs.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 08 Feb 2005 12:03:52 -0500

On Monday, February 07, 2005 11:57:05 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> talking to the legitimate AS for its realm, and as it stands, PKINIT
>> breaks  that.  Unbreaking it only for DNS-style realms is insufficient.
>

Not necessarily.  Suppose you have a realm with an X.500-style realm name, 
whose clients find the KDC's by doing a lookup against an X.500 directory. 
If access to the directory is secured by Kerberos, or not at all, then you 
need to be able to verify you are talking to the right KDC without 
depending on access to the directory being secure.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Feb 2005 11:08:34 -0600

> depending on access to the directory being secure.

Such configurations could be considered out of scope for this I-D and
left to another.  I'm not saying they should, unless resolving this item
proves controversial.