Subject: Re: a change to the signature processing in IKEv2

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 23 Jan 2003 01:41:53 +0200 (IST)

In a message posted to this list on Dec 31st
http://www.vpnc.org/ietf-ipsec/mail-archive/msg02846.html
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"...

Hugo

---

From: [email-masked]
Date: Wed, 22 Jan 2003 23:15:17 -0500

>    responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)].

Point of clarification. We have to say whether it's the whole IDi payload,
or just the data portion, or the data portion plus the type. My preference
would be the while IDi payload, since I believe it's important to cover the
type and it's easier to specify the whole thing than to list subparts.

I have been resistant to this sort of change in the past believing it to be
overkill. But I'll grant that it does make it harder for future changes to
the protocol to introduce subtle problems (as illustrated by the SLA
discussion), so I'm now inclined to go along unless someone objects.

This does have an interaction with another discussion. In various
proposals, the IDi field replaced with other (authentication method
dependent) fields. This would commit us to always having IDi and IDr fields
even if the information they contain duplicates information elsewhere. I
can live with that... does anyone else object??

In legacy authentication, I proposed that any shared secret established by
the legacy authentication be used to compute the MAC for the client's AUTH
field, and that if the legacy authentication method doesn't produce such a
shared key then the client never sends an AUTH field. This is instead of
somehow mixing that shared key into SKEYSEED. This implies that the key is
no stronger than the Diffie-Hellman group used, but that has to be true
when using digital signatures and seems acceptable here. Do you have any
objections?

> I am wrong here please let me know.

SK_a keys are used to compute a MAC over IKE packets. Currently, the only
MAC
allowed is the negotiated prf, and I can't imagine why anyone would make it
anything else. If a different MAC were used, I would presume that the same
MAC computed over IDi would be what you should sign. I don't think that
needs
saying, but there might be a natural place for the words.

> support for that change I can offer some text.

I agree this would increase the robustness of the protocol against someone
revising the specification of the protocol in the future in a way that
makes the protocol less secure, but I also believe that it adds significant
specification complexity so I continue to oppose it.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 24 Jan 2003 05:12:57 +0200 (IST)

see below

> type and it's easier to specify the whole thing than to list subparts.

From the cryptographic point of view the MAC (or prf) needs to contain any
information that suffices to identify the signer to the other peer. 
The data portion of the ID payload is enough for this but adding the whole
payload as you suggest is perfectly ok too.

> discussion), so I'm now inclined to go along unless someone objects.

I don't object. :)

> can live with that... does anyone else object??

This issue is unrelated to the change I proposed. IDr should be anything
that suffices for I to identify who the peer (responder) to the exchange
is. Similarly for IDi. Without such  information there would be no notion
of "authentication" in the protocol.
 
> when using digital signatures and seems acceptable here. Do you have any

This issue, too, is unrelated to the change I sugested.
In any case you are right about the key being no stronger than the DH
group. Since this is true for the signature mode, and even for the
preshared mode with strong (say 128-bit random) key, then I see no
objection that the same property will hold for the password-based
protocols covered by SLA.

> saying, but there might be a natural place for the words.

I suggest that the draft will make it clear that prf is the function to be
used for key derivation and also for the integrity protection function in
the "encrypted payload" (it is also used explicitly in the current
specification for the AUTH computation under preshared mode). 
Currently, this dual use of the prf is a "de-facto specification"
since the ciphersuites do not accomodate different functions for prf and
for integrity. So it is better to say this explicitly. The only reason
that one may want a MAC different than the prf is to speed up the MAC
computation in SK{}. Indeed, there are MAC functions that are much faster
than prf's. But this speed advantage is irrelevant in IKE. For example,
by replacing the prf (for integrity) with a 10 times faster MAC you may
get (at most) a speed-up of IKE of 1% (this is so so since the computation
time in ike is fully dominated by the signature and DH operations).

> specification complexity so I continue to oppose it.

No surprise here...

Hugo