Subject: RE: PKINIT-22 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 28 Jan 2005 03:30:31 -0800

In addition,

 Our existing clients only send the leaf cert.

 TLS allows both leaf certs and certificate chains.

The client may not have the full certificate chain (exclude the root)
available.

-- Larry

-----Original Message-----
From: Love [mailto:[email-masked]] 
Sent: Thursday, January 27, 2005 1:11 PM
To: Sam Hartman
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: PKINIT-22 comments

Sam Hartman <[email-masked]> writes:

>     >> The certificate chain(s) MUST NOT contain the root CA
>     >> certificate.
>
>     dcross> Will you allow only the leaf (end entity) certificate to
>     dcross> be sent to the KDC and let the server build the chain?  Is
>     dcross> this optional?
>
> Speaking as an individual, I'm uncomfortable with adding more optional

> things to the protocol.
>
> OTOH, a mostly offline client may not have sufficient data to build a 
> cert path.

I think client should send as much of the chain as possible, and the CA
try to fix up an acceptable chain with the pieces it have available.

>     dcross> A client MAY send only the leaf certificate to the KDC and
>     dcross> it SHOULD send all certificates in the chain necessary to
>     dcross> build a path to a trust acnhor on the KDC"
>
> I'm not sure this text is sufficient to guarantee interoperability.
>
>     >> 4.  The certificates field contains an X.509 public key
>     >> certificate chain that the client will use to verify the KDC's
>     >> signature over the ReplyKeyPack.  This field may only be left
>     >> empty if the client included a kdcCert field in the
>     >> PA-PK-AS-REQ, indicating that it has the KDC's certificate.
>     >> The certificate chain MUST NOT contain the root CA certificate.
>
>     dcross> We propose: A client MAY send only the leaf certificate to
>     dcross> the KDC and it SHOULD send all certificates in the chain
>     dcross> necessary to build a path to a trust anchor on the KDC.
>
> Isn't this text kdc to client?

Yes, the quoted text is from the server->client. If the text was moved
up to the right section I would find it good.

> In conclusion, you seem to be proposing fairly significant changes to 
> the cert path handling for pkinit at a very late stage in the 
> protocol.  I'm concerned about this.

Its not like the KDC needs to be able to handle this anyway, I'm not too
worried.

Love

---

From: Sam Hartman <[email-masked]>
Date: Fri, 28 Jan 2005 17:28:06 -0500

My concern is that the protocol needs to be sufficient that clients
and kdcs from different vendors are interoperable.  How can we do that
if some send full chains and some do not.  

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 28 Jan 2005 17:36:34 -0500

> if some send full chains and some do not.

I think this is perhaps a policy issue, not a protocol or implementation 
issue.  All clients should be capable of transmitting the full chain, but 
obviously cannot do so if they have not been configured with a complete set 
of certificates.  In a deployment in which clients are not provided with 
their full certificate chain (which actually seems like it could be a 
common case), obviously the KDC must be configured with access to the 
intermediate certificates it will need.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Martin Rex <[email-masked]>
Date: Mon, 31 Jan 2005 20:59:24 +0100 (MET)

>  TLS allows both leaf certs and certificate chains.

Sorry, but for TLS this is incorrect.  TLS **REQUIRES** both, server and
clients to include all certificates from intermediate CAs.
TLS explicitly says, that only the final rootCA certificate may
optionally be omitted (to clear up an ambiguity of the SSLv3 spec).

Quoting from rfc-2246 "TLS v1.0", section 5.6.2 Server certificate

   certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

   The same message type and structure will be used for the client's
   response to a certificate request message. Note that a client may
   send no certificates if it does not have an appropriate certificate
   to send in response to the server's authentication request.

> The client may not have the full certificate chain (exclude the root)

Personally, I think that it is a horrible and broken design to allow
a client not to know it's certificate chain up to the rootCA certificate.

I think that the forward path should always be included, also for
Kerberos PKINIT.  I do agree that this increases the handshake message(s)
with additional information which the KDC will often already have,
but I do really have a problem with requiring the KDC to go searching
intermediate certificates, because that is quite a large DoS attack
surface.

So personally, I would prefer if the KDC was *NOT* supposed to
lookup missing certificates in the clients certification path.

Maybe you remember the discussion of the SSL-DoS with large keys in
client certificates.  The idea to reduce the attack surface is
to make certification path validation from root to leaf instead
of leaf to root (which is what most implementations have traditionally
been doing) -- with the effect that you will not do (potentially costly)
computations with a key from a certificate you don't trust.

Having the server search for intermediate certificates is a bad idea.

-Martin