[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a change to the signature processing in IKEv2



On Thu, 9 Jan 2003, Derrell Piper wrote:

> Hugo,
> 
> There's been scant discussion about this since your post.  I've now 
> read your SIGMA paper and I like the first change you proposed.  I 
> think explicitly moving the identity binding MAC into the signature 
> definition is a very good change for all the reasons you noted.  I 
> would like to see this incorporated into the next revision of the IKEv2 
> draft, prior to the February submission.

I would like too. It is up to the editor now.
Now that version 04 is out I will send explicit language to incorporate
this change. It really is a triviality from the point of view of spec and
implementation.

 > 
> Regarding the second change, I'm generally in favor of what you 
> proposed.  I've always thought that the authenticator should include 
> all of the information transmitted by a peer.  I have in the past heard 
> arguments about wanting to limit the amount of data being signed, which 
> often results in an additional MAC step being applied before the 
> signature.  What are your thoughts here?  Clearly with SLA we weren't 
> concerned with this since we proposed a 'sign it all' signature, but I 
> bring it up here because the generalized IKEv2 change may imply some 
> potentially long certificate chains will now be included with the 
> addition of messages 3 and 4.

It would really be a better design that each party  signs the two messages
it sends, that is, each party signs ALL the information it sends in the
exchange (including stuff that may be added to the exchange at some future
revision...)
But this change is less trivial than the above one, in particular as you
say because of the potentially long certs that would get included
automatically. It is no big deal since hashing this information is very
fast, yet it may have a psychological effect on people. Also, signing two
messages instead of one makes the spec a bit more complicated due to the
need to concatenate the information and possibly move the signature to the
end of the message. None of this is big deal but I will not "fight" for
it.

Thanks for the support.

Hugo

> 
> Derrell
> 
> On Monday, December 30, 2002, at 04:38 PM, Hugo Krawczyk wrote:
> 
> >
> > 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
> >
> 
>