Subject: RE: PKINIT-26 changes: identifying the kdc certificates

From: "Paul Leach" <[email-masked]>
Date: Tue, 24 May 2005 09:22:30 -0700

> -----Original Message-----
> From: Sam Hartman
> Sent: Monday, May 23, 2005 11:53 PM
> To: Liqiang(Larry) Zhu
> 
[snip]
> 
> EKU is clearly efficient to be secure.
[Paul Leach] I don't understand this. An EKU without a name is not
sufficient. What do you mean by "efficient" -- that it is necessary? (As
in "necessary and sufficient"...)

The EKU can differentiate between multiple services on the same host.
(However, it does so in a way that is mechanism specific, and hence not
in general suitable for a generic, polymorphic, API; hence the reason
for our SRV record proposal now wending its way through PKIX.)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 May 2005 13:51:54 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    >> -----Original Message----- From: Sam Hartman Sent: Monday, May
    >> 23, 2005 11:53 PM To: Liqiang(Larry) Zhu
    >> 
    Paul> [snip]
    >>  EKU is clearly efficient to be secure.
    Paul> [Paul Leach] I don't understand this. An EKU without a name
    Paul> is not sufficient. What do you mean by "efficient" -- that
    Paul> it is necessary? (As in "necessary and sufficient"...)

Sorry I was being sloppy because it was late and there was a lot of
mail to read.

An EKU (implicitly plus dnsname with the domain-style realm in the
dnsname) is clearly sufficient to be secure.  The question about that
solution is whether it is impractical to implement because of CA
limitations.

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 May 2005 20:18:10 +0200 (MET DST)

> solution is whether it is impractical to implement because of CA

I think we should be careful in defining what exactly is mandatory to
implement.

And we should also take into consideration the odds of PKI infrastructure,
CA software capabilities and commercial CA (mis-)behaviour^H^H^H^H^H^H
business practices.

Example: although X.509v3 isn't exactly new, VeriSign still uses
an X.509v1 certificate for their RootCA.  An X.509v1 certificate does not
contain any extended attributes (like key usage) or basic constraints,
and therefore it also doesn't contain the Basic Constraint "allowed
to act as a CA" = TRUE marked critical.

So this means that an implementation of TLS in a Web Browser that
conforms to rfc2459 would have to reject a server certificate signed
by VeriSign -- but I don't see implementations doing this.

Not doing it is not necessarily a security problem, but it definitely
is a standards problem, i.e. the standard fails to address reality.

Actually, quite a lot of PKI software creates selfsigned X.509 certificates
when it generates a new keypair, and usually that can already be used
to test software which requires the use of PKI credentials.
I.e. I can run a Web-Server with SSL/TLS using a self-signed X.509v1
certificate and all of the Web-Browsers that I know will not abort
on the grounds that an X.509v1 certificate is not allowed and can not
be checked at all for keyUsage, extendedKeyUsage, basicContraints, etc.

I find it actually quite useful that I can use X.509v1 certificates
for testing things--in particular it extremely easy to issue certs
with near-indefinite lifetime that can be used for automated
software testing in a software build environment.

What I actually wanted to say:
I think it is fine to at least one particular verification procedure
and that this verification procedure MUST be implemented, so when
the attributes are present, they must be checked, and when the
check fails, the authentication MUST fail, and NO, NONE, NIL, ZERO
local policy may override this.
 
However when the necessary attribute(s) for the MUST implement
verification procedure are not present, then the verification can not
be performed.  Which is something entirely different than a
verification that failed.

So in the case that the verification can not be performed, it
should by default be treated like a failed verification, unless
there is a either a local verification available which determines
success or failure or there are future/alternative verification procedure(s)
available and applicable which can determine success or failure.

Mandating the presence of particular attributes in the certificate
or mandating a particular verification procedure where it is
obviously not applicable is going to be a nuisance for everybody
with very little benefit, if any.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 May 2005 14:57:12 -0400

I think I'm in agreement with Martin mostly.  I tend to believe
mandating the presence of the pkinit KeyPurposId in the EKU is
probably undesirable even if we define such anKeyPurposeId.  (Larry disagrees
here I believe; he wants to do something kind of complicated.)

One area where I disagree with Martin is that I don't believe the
presence or absence of the EKU should influence the success or failure
of the verification except as provided for by 3280.

Restating to be more concrete, here are things I think would be reasonable:

* EKU must be present and must contain pkinit KeyPurposeId (Martin and I both think this creates interoperability challenges, but I at least think it would be reasonable for the WG to go down this path).

* EKU may be present.  If it is present then it must either contain
  the pkinit KeyPurposeId or the any purpose ID.  If it is not present
  then it is not a problem for the verification.

* EKU may be present.  If dnsname is used then EKU must be present and
  must contain the pkinit KeyPurposeId.  I think this is what Larry
  wants.  I consider it overly complicated but think it is something
  the WG may want to adopt.

What I think would be problematic is:

* EKU may be present.  If present it must contain the pkinit
    KeyPurposeId.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 May 2005 15:10:25 -0500

> of the verification except as provided for by 3280.

Taking Martin's comments at face value I think this can only mean one
thing: we may need two required KDC cert authorization methods -- one
that does not require EKUs or subjectAltNames, for folks with crappy
CAs, and one that does, for folks with decent CAs.

That might certainly simplify this discussion.

The method for PKIs with lousy CAs is simple: pre-share the KDC certs to
the clients.

The method for PKIs with decent CAs is also simple: require that the KDC
EKU to be present and the krb5 princ name other name for the KDC's TGS
name too.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 25 May 2005 18:11:56 -0400

On Wednesday, May 25, 2005 02:57:12 PM -0400 Sam Hartman 
<[email-masked]> wrote:

> probably undesirable even if we define such anKeyPurposeId.  (Larry
> disagrees here I believe; he wants to do something kind of complicated.)
>
> * EKU must be present and must contain pkinit KeyPurposeId (Martin and I
> both think this creates interoperability challenges, but I at least think
> it would be reasonable for the WG to go down this path).
>

For the moment, I'll speak not as chair, but as an individual network 
operator using Kerberos and planning to eventually deploy PKINIT.  From 
that viewpoint, my concern is pretty simple:

It is common for the same name to be used for several services, managed by 
different groups.  For example, the name 'CS.CMU.EDU' names a DNS domain, 
and a Kerberos realm, and a mail domain, and may name a web server.  All of 
these are managed by different people, with varying levels of 
communication, trust, and accountability to each other.  Particularly, the 
people who run web servers, the people who run the mail servers, and the 
people who manage DNS contents are all _not_ trusted to manage Kerberos. 
They don't get to log in to the KDC's, and they certainly don't get to 
issue tickets.  I don't want any of those people to be able to impersonate 
the KDC, and I don't want any insecurities in the services they run to 
compromise Kerberos.

What that means, I think, is that it MUST NOT be possible for any Kerberos 
client - particularly one I do not control - to become confused into 
thinking that a certificate issued for one of those other services belongs 
to an entity which is allowed to act as a KDC.  It's not good enough to say 
"configure your Kerberos clients to require the EKU", because I don't 
control all the clients that might want to talk to my realm.  And, it's not 
good enough to say "don't give those other services certs without a 
restrictive EKU", because I don't control the well-known CA's and I may not 
have any ability to prevent such a cert from being requested or issued. 
This is especially true since the default policy of many CA's is to issue 
certs with no EKU.

To accomplish that, I think we need to REQUIRE that clients accept a KDC's 
certificate only there is some indication that it is intended for use with 
Kerberos.  I can think of several possible such indications:

- Presence of the pkinit KDC keyPurposeId
- Presence of the pkinit KDC keyPurposeId or the any purpose ID
- Presence of an appropriate KerberosPrincipalName SAN
- Presence of stefan's proposed SRV SAN, with appropriate contents
- Client has been pre-configured with the KDC's cert or public key
- Some vendor-specific extension

I think we need to pick at least one mechanism (one of these or some other 
proposal) to REQUIRE clients to implement.  We can specify more than one, 
but there needs to be at least one required-to-implement method, and I 
think there needs to be a requirement that certificates not satisfying any 
method known to the client be rejected.

-- Jeff