> 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 protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
