a change to the signature processing in IKEv2

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

This message contains a request for a change to the cryptographic
specifications of ikev2's signatures. It is a relatively easy change that
will add security to the protocol in the sense of making the protocol's
security more robust to changes (in particular new modes and variants such
as SLA). It will also improve the protocol by making its logic easier to
understand and analyze.

In a previous message I described an "identity misbinding attack" on SLA. 
I said there that this attack against the authenticity of the protocol is
NOT possible in IKEv2.  Indeed, IKEv2 provides strong authentication via
the combination of a digital signature on the DH exponentials and a MAC
on the signer's identity. This follows the "sign and mac" of the SIGMA
protocols which has been rigorously analyzed. Therefore I have no 
complaints about the security of IKEv2 as specified now (draft v3).

On the other hand, I do have a complaint (that I expressed several times in
the past) regarding the "robustness" of the IKEv2 design.
The problem is that the essential key-identity binding through a MAC
is achieved in IKEv2 in an indirect way that is not sufficiently explicit 
and thus it is prone to misunderstandings and mistakes in modified versions
of the protocol.  I have been saying (since Nov 2001) that sooner or later 
people will propose variants or changes that will fail to be secure due to
this design "obscurity". And indeed it happened sooner than later with the
design of SLA.

The problem is that IKEv2 authentication (and specifically key-identity
binding) depends on two elements:

(1) the MAC that is applied through the SK{} processing (which most people
understand as needed for identity protection, or encryption integrity,
rather than for the core authentication of the protocol)
(2) the transmission of the initiator's identity in message 3 and of the
responder's in message 4.

If you remove any of these elements, or move the identities to another
message, the protocol becomes insecure.
SLA is an example in which the authentication in message 4 (the responder's)
is moved to message 2 but SK{} (and its MAC) is not carried to that message. 
And it is not really the SLA designers fault: the SK{} processing includes
encryption while message 2 of SLA cannot be encrypted (since it contains KEr
which needs to be sent in the clear). Moreover, in SLA you do not care
about protecting the identity of the responder (the server) and thus the
SK{} processing is not only problematic but actually unnecessary.

Another case in which the protocol's security would break down is in the
following (not completely) hypotetical scenario. Assume that in some setting
you do not care about identity protection of the initiator. In this case it
makes a lot of sense to transmit this identity already in the first message
so that the responder can make policy decisions early on based on this
identity (this, btw, was one of the properties people liked/wanted in the
aggressive modes of IKEv1).  In this case, the authentication by the
initiator still occurs in message 3, but the identity is not included there
(since it was sent in message 1). However, while this change (or option) may
seem very reasonable the resultant protocol would fail to "identity
misbinding" attacks (i.e.  the basic "mutual belief" property is lost). 
Note that while the effect of such an attack is debatable in the specific
case of SLA, it is a major vulnerabiity in a general peer-to-peer key
exchange protocol as IKEv2.

As a fix to SLA and a general fix to this lack of robustness of IKEv2 I
propose the following change to the signature computation (the AUTH payload)
in IKEv2.

Currently IKEv2 defines that the signature is to be applied to the
concatenation of the peer's nonce and the contents of certain messages in
the protocol. The change I am asking for is to add to the signed information
also a value computed as MAC(SK_a,ID) where SK_a is is the MAC key already
computed by the protocol, and ID is the identity of the signer.  
More specifically, in the initiator's signature (in message 3) this
additional value will be MAC(SK_ai,IDi), while in the responder's signature
it will be MAC(SK_ar,IDr).

The computation of the keys SK_ai/SK_ar requires no additional processing
or change since they are already derived in IKEv2 for use in the MAC in SK{}.  
Also note that the value MAC(SK_a,ID) added to the signature computation
will NOT be transmitted but just re-computed by the receiving end when
verifying the signature, so it requires no new payload nor it increases the
length of messages.

Thus, while the proposed change adds negligible complexity relative to the
whole complexity of IKEv2 it provides for a significantly more robust and
easier to analyze design.  In particular:

(1) the signatures can be moved to any message where they make sense (e.g.
to message 2 in SLA) without loosing the protocols security
(2) the identities can be transmitted in any message (e.g. the initiator's
identity in message 1) without impacting the authentication of the protocol
(3) the MAC used in SK{} will be confined to two functionalities:
   (a) protecting the identity encryption against active attacks
   (b) protecting the authenticity of phase-2 information piggybacked 
       to msgs 3 and 4.

Then I would also suggest a second change that will reduce the need for
SK{} to functionality (a) (identity protection) only.  The idea is
to expand the signature's scope to the WHOLE information sent by each signer.
That is, I's signature will be applied to the full messages 1 and 3, while R's 
signature to the full messages 2 and 4. In this case the AUTH payload can be 
moved to the end of messages 3 and 4 (before the SK{} processing).  
Relative to what is signed today, this change has the cost that each
signature needs to be applied to two messages (instead of one message only). 
However making sure that you sign ALL the information sent by each party
makes a better design.  And, not less important, we make the MAC under SK 
only needed for identity protection.  In particular, the resultant protocol
can be proven secure even if the whole SK{} processing is omitted in case
that identity protection is not required. I consider this as a significant
robustness AND analytical advantage.

In any case, while I'd prefer to see both changes accepted, I still consider
the firsr one (adding MAC(SK_a,ID) to the signatures) as more significant
and needed independently of the second change (i.e. expanding the scope of
signatures).

If anyone opposes these changes (especially the first one) please explain
the rationale of this objection in a message to this list. I would suggest
that whoever wants to raise objections against these changes first reads the
SIGMA paper which addresses in much more detail the motivation and rationale
behind these changes (in particular, see section 5.4 of the paper). 
The url (again) is http://www.ee.technion.ac.il/~hugo/sigma.ps [.pdf]

Happy new year

Hugo