[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: representation of IKE DH shared secret
On Wed, 21 Apr 1999 01:54:47 EDT you wrote
>
> For a similar case, that of the KE payload, RFC 2409 does specify the
> more about the representation in section 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
> with zeros.
>
> [This doesn't actually say "padded up to be an integral number of
> octets", but I assume that this is meant. Should it be stated?]
>
> [This seems to contradict 3.2:
> KE is the key exchange payload which contains the public
> information exchanged in a Diffie-Hellman exchange. There is no
> particular encoding (e.g. a TLV) used for the data of a KE payload.
> I think we do have a particular encoding.]
I'm obviously not enough of a pedant so let me try to be one. Webster says:
"encode: to convert (as a body of information) from one system of
communication into another." So if the KE payload was, say, MIME then we
would have an encoding. The information is not converted into another
system. It's not an encoding. It's no contradiction.
> => I think that RFC 2409 should have specified the representation to
> be used for the DH shared secret.
>
> If it is agreed that this is a problem, what is the appropriate way to
> deal with it?
Is this a problem? We seem to have gotten a score (or so) interoperable
implementations as its written but maybe that's just because a D-H
secret hasn't been produced yet that began with 8 bits of zero. But
somehow I doubt it.
The way to proceed is to write up some suggested text and send it to
the list. If no one complains I'll add it to the next rev which will be
out Real Soon Now.
Dan.
Follow-Ups:
References: