Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-03

From: Keith Welter <[email-masked]>
Date: Tue, 19 Apr 2011 08:49:25 -0700

> I contacted Hugo Krawczyk, the SIGMA author, and he agreed to 
> evaluate the security considerations of the draft.  He's busy at the
> moment though so we won't be able to pick-up the thread for a couple 
weeks. 

I reviewed the draft with Hugo and he explained that it is critical to 
sign something fresh (as opposed to something cached as proposed in the 
current version of the draft) and something that binds the data to the SA 
should be included (e.g. the SPIs).  The approach Hugo suggested was that 
the initiator should first send the responder the data to sign.  In 
practice this works out to four messages.  For example:
1) Host A generates some fresh data (i.e. a nonce) and sends it to host B 
("here, sign my data")
2) Host B signs the fresh data from host A and sends it back ("ok, I 
signed your data, now you sign what I just sent")
3) Host A verifies the signature from host B, signs the data from host B 
and sends it back ("ok, I verified your data and signed it")
4) Host B verifies the signature from host A and responds with success or 
failure

The original version of the draft satisfied these requirements but the 
current version does not. 

The current version of the draft takes the approach of allowing a modified 
IKE_AUTH exchange on the original IKE SA, subsequent to the initial 
exchanges, for the express purpose of reauthentication.  It does not 
provide for signing fresh nonces. 

The original version of the draft used the initial exchanges to 
reauthenticate the IKE SA (as is normally done in IKEv2) but added a 
notification mechanism indicating that the new IKE SA should inherit the 
old child SAs, thereby eliminating the round-trips that would have been 
required to re-establish equivalent child SAs under the new IKE SA. 

Therefore, I believe the approach taken in the original version of the 
draft is the best way forward for eliminating the unnecessary round-trips 
needed to re-establish child SAs during IKEv2 reauthentication (as well as 
solving the other problems identified by the draft).

> 
> > > 2. There is one point I'd still like technical input on, namely the 
> > > security considerations of signing the previous AUTH payload sent by 
the 
> > > host in the modified IKE_AUTH exchange (section 5 of the draft). 
Yoav 
> > > suggested this approach, it sounded fine to me, I ran it by a 
> couple of my 
> > > colleagues (Scott Moonen and David Wierbowski) who thought it sound 
fine 
> > > too so I used it in the new draft.  I'd feel better if another 
subject 
> > > matter expert said, "yes, that is fine."  Bonus points if the SME 
can 
> > > offer a sentence or two justifying why this mechanism is as secure 
as the 
> > > authentication operation that takes place during the initial 
> exchanges. It 
> > > would be nice to include that information in the security 
considerations 
> > > section of my draft.  More specifically, RFC 5996 section 2.15 
> > > "Authentication of the IKE SA" says, "It is critical to the security 
of 
> > > the exchange that each side sign the other side's nonce."  Is 
itnecessary 
> > > to include nonces in the signed data in the proposed modified 
IKE_AUTH 
> > > exchange?  I don't think so, but since I don't know why it was 
necessary 
> > > as part of the signed data in the initial exchanges I don't 
feelqualified 
> > > to assert that formally.
> > 
> > In the initial authentication the signing of the IKE_SA message proofs
> > that nobody has modified those packets. Note, that it does not sign
> > the IKE_AUTH message, as it is protected by the Integrity Checksum
> > Data field. So the signing of the message data is there just to
> > provide MAC for the first packets which are not MACed normally.
> > 
> > The real authentication happens when node signs the other ends nonce
> > and his own MACed ID.
> > 
> > Read the SIGMA documentation for more details:
> > 
> >    [SIGMA]    H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
> >               Authenticated Diffie-Hellman and its Use in the IKE
> >               Protocols", Advances in Cryptography - CRYPTO 2003
> >               Proceedings LNCS 2729, 2003, <http://
> >               www.informatik.uni-trier.de/~ley/db/conf/crypto/
> > 
> crypto2003.html>._______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec