Hi, I have one concern with the current draft: how to gracefully handle the situation when PPKs on initiator and responder don't match (due to configuration error or PPK update). With the current draft this situation isn't handled at all: after creating Child IKE SA both peers will end up with new SA having different SK_* values on each side. As a result - the new SA won't be operable and the peers won't be even able to send back SYNTAX_ERROR notification over it (very similar to the same situation in IKEv1).
My idea to gracefully handle this situation is to use PPK_NOTIFY notification. Currently it contains no data, but it is possible to put something like prf(PPK, Nr) for initiator and prf(PPK, Ni) for responder in PPK_NOTIFY notification [0]. This would allow peers to verify that the other side does have the same key before actually using it. In case the check fails a peer can return AUTHENTICATION_FAILED over initial IKE SA. I only concern whether this would open some new attacks (like providing an oracle). Regards, Valery. [0] So that each side proves possession of PPK by applying it to random data, generated by peer. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
