[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a change to the signature processing in IKEv2
In a message posted to this list on Dec 31st
I requested to make a change to the signature processing in ikev2
in order to add to the cryptographic soundness and robustness of the
protocol (and, as a nice bonus, to secure SLA). See that message for the
rationale of that change.
I did not offer specific language then for the change since the ikev2
draft was in transition between 03 to 04 (and from 4 msgs to 6 msgs). Now
that 04 is out I can provide with the exact language necessary to specify
the change. The change takes 2-3 lines of text in the spec, 10 minutes of
programming, and 30 minutes of testing. It also adds several years of
extra cryptographic health to the protocol (and its derivatives)...
So here is the suggested change. The text that follows should
replace the first paragraph of section 4.15 (where the processing of the
signature operation is defined) in ikev2-04. No other change is needed.
The changes from the current paragraph are minimal and I marked them by
putting them under brackets [...].
4.15 Authentication of the IKE-SA
The peers are authenticated by having each sign (or MAC using a
shared secret as the key) a block of data. For the responder, the
octets to be signed start with the first octet of the first SPI in
the header of the second message and end with the last octet of the
last payload in the second message. Appended to this (for purposes
of computing the signature) [are] the initiator's nonce Ni (just the
value, not the payload containing it), [and a value MIDr computed as
prf(SK_ar,IDr). Note that neither the nonce Ni or value MIDi are
transmitted.] Similarly, the initiator
signs the first message, starting with the first octet of the first
SPI in the header and ending with the last octet of the last payload.
Appended to this (for purposes of computing the signature) [are] the
responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)].
That's all. I gave the name MID to the added value to mean "Mac'ed ID".
The name is not strictly necessary since there is no need to refer to
this MID value in any other place of the spec (except for rationale).
BTW, I am assuming that the keys SK_a are intended for use as keys to the
negotiated prf (and not, for example, to key a different MAC function). If
I am wrong here please let me know.
Regarding the second change I suggested in my note of 12/31, namely, that
each peer signs ALL the information it sends during the exchange, I still
think that this change would improve the cryptographic design of the
protocol, but it also would add some specification complexity. If there is
support for that change I can offer some text.
In any case, I consider the introduction of the MID field as specified
above a first priority (in particular since it makes the protocol security
indpendent of the position of the identity in the exchange). Hopefully it
will make it to the ikev2 draft by the February's "deadline"...