Hi Yaron, Thanks for the comments.
Yeah, I have seen one application that implements High Availability by sending DH secret + KE + Nonces. Concerning the RFC that deals with the security issues resulting from this behavior, are you talking about Yoav's RFC - IPsec Cluster Statement?. If not, could you please tell me which RFC are you mentioning? So, as this is a known issue (Case #1), there is no problem to disallow it. Other point from previous discussions: I just wanted to add that in the Case #3, Valery and I had some offline discussions about it, and we found out that actually the SK_p*_old are not used to compute Session Resumption's AUTH payload. Instead, SK_d_old is used to compute it. This means that we actually can avoid SK_p* to be included in the IKE_SA Context Parameters (with a Mandatory flag). If anyone thinks SK_p* might be needed for some other exchange, please point that out through the mailing-list. Thank you, Kind Regards, Daniel Palomares 2014-03-06 11:35 GMT+01:00 Yaron Sheffer <yaronf.i...@gmail.com>: > Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED, >> SK_*, keymat for Child SA and AUTH payload content.Anyway, once the >> exchange >> is complete, the nonces, appeared in this exchange, may be discarded. >> Actually, you have 3 choices to exchange IKEv2 keying information >> between nodes in cluster: >> 1. Send your private DH key, peer's KE content and nonces. In this case >> other nodes will recalculate all keys from the very beginning. >> 2. Send SKEYSEED and nonces. >> 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*, >> as these >> keys are used only during authentication (unless you implement >> Session Resumption, >> but it also depends on how you store the tickets - by value or by >> reference). >> All approaches are equally possible. There seems to be some >> security and performance benefists for approach 3, but somebody >> may argue. Implementation may use any of this approaches >> and I don't think it's good to mandate the only approach, >> Regards, >> Valery. >> >> > Actually, I would suggest that we disallow (or "deprecate") option #1. > IKEv2 explicitly allows for DH secrets to be shared between SAs (this is > not a good idea, but people do it for performance reasons), and we even > have an RFC to deal with the security issues resulting from this behavior. > So a node would be sharing more than it bargained for. > > Thanks, > Yaron >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
