Subject: Format of PKINIT messages.

From: Jan Nordqvist <[email-masked]>
Date: Wed, 10 Dec 2003 21:36:18 -0800

I am new to the mailing list so please apologize me and let me know if this is an inappropriate posting.

I have a few questions / comments to the group regarding the PKINIT extension to Kerberos 5:

When Diffie-Hellman key-exchange is used to establish authenticity with PKINIT, the pkinit draft(s) state that an initial number of bytes from the computed Diffie-Hellman shared secret, corresponding to the key-length of the used symmetric encryption algorithm are to be used as the symmetric encryption key. There is no mentioning as to how those bytes will be processed to make up the actual key. If the encryption method is DES for example, will this byte string simply have one bit in each byte replaced by the corresponding parity-bit to produce a appropriate DES-key? How are the (unlikely) key-values that end up corresponding to the DES weak or semi-weak keys treated? Should they be "fixed" the standard Kerberos way by ex-or'ing with 0x00000000000000f0, or should the KDC pass back a KDC_ERR_KEY_TO_WEAK error?

Another question, is regarding the format and treatment of the SignatureAlgorithmIdentifier object inside of SignerInfo in the PKINIT messages. RFC-3370 states that if the algorithm in AlgorithmIdentifier is rsaEncryption, md5WithRSAEncryption or sha1WithRSAEncryption, the parameters field MUST be NULL. At least one freely available PKINIT implementation, however, does not accept AS-replies with the NULL object inside of the AlgorithmIdentifier.
Is there a consensus within the group how this construct should be implemented and treated by clients?

Jan Nordqvist
Amenity Networks

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Dec 2003 11:49:21 -0500

>>>>> "Jan" == Jan Nordqvist <[email-masked]> writes:

    Jan> When Diffie-Hellman key-exchange is used to establish
    Jan> authenticity with PKINIT, the pkinit draft(s) state that an
    Jan> initial number of bytes from the computed Diffie-Hellman
    Jan> shared secret, corresponding to the key-length of the used
    Jan> symmetric encryption algorithm are to be used as the
    Jan> symmetric encryption key. There is no mentioning as to how
    Jan> those bytes will be processed to make up the actual key. If
    Jan> the encryption method is DES for example, will this byte
    Jan> string simply have one bit in each byte replaced by the
    Jan> corresponding parity-bit to produce a appropriate DES-key?
    Jan> How are the (unlikely) key-values that end up corresponding
    Jan> to the DES weak or semi-weak keys treated? Should they be
    Jan> "fixed" the standard Kerberos way by ex-or'ing with
    Jan> 0x00000000000000f0, or should the KDC pass back a
    Jan> KDC_ERR_KEY_TO_WEAK error?

This is somewhat in flux.  

The Kerberos crypto framework defines a function called random to key
which takes a random bitstring and constructs a key.  In the case of
DES, it adds parity bits.  In the case of a key with more structure,
it might do something very complicated.

My hope is that the output of DH is passed directly in to this random
to key function.

---

From: Jan Nordqvist <[email-masked]>
Date: Thu, 11 Dec 2003 22:12:37 -0800

It is not intuitive from the textual description in the pkinit draft 
that the random to key function is to be used to convert the DH secret 
value. Can anyone in the group verify the use of the kerberos 
DES3random-to-key or an other method in PacketCable MTA device provisioning?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Dec 2003 13:18:31 -0500

>>>>> "Jan" == Jan Nordqvist <[email-masked]> writes:

    Jan>    It is not intuitive from the textual description in the
    Jan> pkinit draft that the random to key function is to be used to
    Jan> convert the DH secret value. Can anyone in the group verify
    Jan> the use of the kerberos DES3random-to-key or an other method
    Jan> in PacketCable MTA device provisioning?

When I said it was an open issue, that's exactly what I meant.  The
text in the draft is clearly wrong and the working group has not
decided what we should do on this issue.

---

From: Love <[email-masked]>
Date: Fri, 12 Dec 2003 22:07:48 +0100

Jan Nordqvist <[email-masked]> writes:

> It is not intuitive from the textual description in the pkinit draft that the
> random to key function is to be used to convert the DH secret value. Can
> anyone in the group verify the use of the kerberos DES3random-to-key or an
> other method in PacketCable MTA device provisioning?

The patch to heimdal that supposedly interops with packetcable pkinit, take
first 8 * 3 bytes of the dh key and fix up the parity bits and use that as
keys.

Love