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.
> > 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 it necessary > > 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 feel qualified > > 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
