[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
wording for representation of IKE DH shared secret
Here is a possible wording change for RFC2409. I'm not saying this is
better than Tero's, but I think that combining some of the ideas might be
The Diffie-Hellman public values g^x and g^y, and the DH shared
secret values g^xy MUST be represented as a octet stream either to
be transmitted in a KE payload or to be input to a PRF or hashing
[There are several cases in which these values are fed to a
PRF or hash. To make the text more robust, I think it would
good to avoid enumerating the cases here. The examples I've
noticed are SKEYID, HASH, and IV.]
For values from a MODP group, the representation used is base 256,
in network order. The number of octets used MUST be the minimum
needed to represent corresponding the group modulus (which may be
more than is required for the actual value being represented).
[I would guess that saying "base 256" is not the accepted way
of describing this, but I don't know where the standard
network representation for binary numbers is described or how
to refer to it.]
For values from a Galois Field, ...
[I don't know how to say the right thing]
This could replace the existing paragraph in 5:
The Diffie-Hellman public value passed in a KE payload, in either a
phase 1 or phase 2 exchange, MUST be the length of the negotiated
Diffie-Hellman group enforced, if necessary, by pre-pending the value
| From: Tero Kivinen <firstname.lastname@example.org>
| I would suggest something like this:
| g^xy is the Diffie-Hellman shared secret. When this value is
| included in the SKEYID calculation as a input for prf it MUST
| be prepended with zero bits up to 8-bit boundary, so that it has
| same length in octects than group prime number p. When this value
| is used in the hash calculation it MUST be in network byte order.
| This is how all the interoperable implementations interpret the
| current document.
I don't think that this catches all the cases where this
representation must be used.
I hope that this helps,
email@example.com voice: +1 416 482-8253