Subject: PKINIT-22 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 24 Jan 2005 09:29:15 -0800

Posted for David Cross ([email-masked]) from Microsoft:

Section 2:
> The advantage afforded by the TGT is that the client need explicitly  
> request a ticket and expose his credentials only once.  The TGT and 
> its associated session key can then be used for any subsequent 
> requests.

This is hard to read.

we propose:

  The advantage afforded by the TGT is that the client
  exposes his long-term secrets only once.  The TGT and
  its associated session key can then be used for any subsequent
  service ticket requests. 

> As defined, Kerberos authentication exchanges use symmetric-key

Insert reference: As defined in [CLAR]

> One cost of using
> symmetric-key cryptography is that the keys must be shared,

s/cost/disadvantage/

Section 3:
 
> 1.  The client indicates the use of public-key authentication by
 >     including a special preauthenticator in the initial request.
This
 >     preauthenticator contains the client's public-key data and a
 >     signature.

Note that the public-key data does not mean raw public-key. It accepts
only x509 certificates.

>    2.  The KDC tests the client's request against its policy and
trusted
>      Certification Authorities (CAs).

s/its policy/its authentication policy/

> md5WithRSAEncryption-CmsOID               10

This should be deprecated for security reasons

Section 3.2.1

> The certificates field MUST contain at least a signature
>       verification certificate chain that the KDC can use to verify
the
>       signature over the AuthPack.  

S/signature verification certificate chain/public key certificate
chain/.  

I think you want to be more explicit and refer to x.509 only.

> The certificate chain(s) MUST NOT
>        contain the root CA certificate.

Will you allow only the leaf (end entity) certificate to be sent to the
KDC and let the server build the chain?  Is this optional?

Section 3.2.2

What happens if the certificate is malformed or the wrong type?  What if
the chain is invalid?  What if the server cannot build a proper chain?

For id-pkekuoid, Microsoft defined a EKU "1.3.6.1.4.1.311.20.2.2", these
two EKU OIDs should be considered equivalent.

A client MAY send only the leaf certificate to the KDC and it SHOULD
send all certificates in the chain necessary to build a path to a trust
acnhor on the KDC"

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

We propose: A client MAY send only the leaf certificate to the KDC and
it SHOULD send all certificates in the chain necessary to build a path
to a trust anchor on the KDC.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Jan 2005 18:07:21 -0500

dcross> Posted for David Cross ([email-masked]) from
    dcross> Microsoft: Section 2:
    >> The advantage afforded by the TGT is that the client need
    >> 1.  The client indicates the use of public-key authentication
    >> by including a special preauthenticator in the initial request.
    dcross> This
    >> preauthenticator contains the client's public-key data and a

    dcross> Note that the public-key data does not mean raw
    dcross> public-key. It accepts only x509 certificates.

Not quite true.  In the DH case the public key (static DH value) is
not in a cert.

There is a cert involved in that case.

    dcross> s/its policy/its authentication policy/

    dcross> Section 3.2.1

    >> verification certificate chain that the KDC can use to verify
    dcross> the
    >> signature over the AuthPack.

    dcross> S/signature verification certificate chain/public key
    dcross> certificate chain/.

No, you want signature verification in there.

    dcross> I think you want to be more explicit and refer to x.509
    dcross> only.

Why?

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

    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.

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

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.

--Sam

---

From: Love <[email-masked]>
Date: Thu, 27 Jan 2005 22:11:24 +0100

> OTOH, a mostly offline client may not have sufficient data to build a

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.

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

> 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