Subject: ECC PKINIT WGLC summary

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 2 Mar 2006 17:02:53 -0800

Tolga Acar ([email-masked]) suggested we should add references to
X9.63. I agree.
He also suggested adding a section making P-256 and P-384 required. I
agree.

Note that his original comments were not posted to this list.

Stefan at Microsoft cautioned that the PKINIT KDF was not blessed by
NIST SP800-56. we discussed this issue offline. Here is my response: the
PKINIT KDF was invented by Paul, Sam, and Dan Simon and me. We basically
looked over the existing modern KDFs in IKEv2, TLS, X9.42/RFC2631, and
ended up with a KDF that basically followed BCP86.  We believe the
PKINIT KDC is weak for a number of reasons, and it would be the first
thing to be changed if we are going to update PKINIT, but an immediate
change is not justified.

Stefan and I would drive to make the PKINIT KDF an approved scheme. At
present, I would not propose any changes w.r.t. the KDF algorithms.

Chaskiel Grundman suggested excellent text changes describing how the
reply key is derived from ZZ, I support his changes.

-01 has incorporated all the changes mentioned above.

Here is the diff ouput.  Please review. Thanks.

6197,199c197,199
<    ECDH public key value and the domain parameters [IEEE1363] for its
<    ECDH public key in clientPublicValue of the PA-PK-AS-REQ message
<    [PKINIT].
---
>    ECDH public key value and the domain parameters [IEEE1363] [X9.63]
>    for its ECDH public key in clientPublicValue of the PA-PK-AS-REQ
>    message [PKINIT].
210c210
<         id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
---
>         id-ecPublicKey (Elliptic Curve Diffie-Hellman [ECCPKALGS])

247,249c247,252
<    If ECDH is negotiated as the key delivery method, both the KDC and
<    the client calculate the shared secret value and derive the reply
key
<    as follows:
---
>    If ECDH is negotiated as the key delivery method, then the
PA-PK-AS-
>    REP and AS reply key are generated as in Section 3.2.3.1 of
[PKINIT]
>    with the following difference: The DHSharedSecret is the
x-coordinate
>    of the shared secret value (an elliptic curve point);
DHSharedSecret
>    is the output of operation ECSVDP-DH as described in Section 7.2.1
of
>    [IEEE1363].
251,263d253
<    1) Let DHSharedSecret be the x-coordinate of the shared secret
value
<       (an elliptic curve point).  DHSharedSecret is the output of
<       operation ECSVDP-DH as described in Section 7.2.1 of [IEEE1363].
< 
<    2) DHSharedSecret is first padded with leading zeros such that the
<       size of DHSharedSecret in octets is the same as that of the
<       modulus, then represented as a string of octets in big-endian
<       order.
< 
<    3) The DHSharedSecret value derived above is used as input to the
<       octetstring2key() function to derive the AS reply key k, as
<       described in Section 3.2.3.1 of [PKINIT].
< 

> 
> 6.  Interoperability Requirements
> 
>    Implementations conforming to this specification MUST support curve
>    P-256 and P-384.
> 
>