Hi Yaron, Thanks for that useful input. I think you mention rfc6989 and [http://cacr.uwaterloo.ca/techreports/2008/cacr2008-24.pdf]. We will have a close look at them.
Actually it is not a bad thing to reduce the number of ways to express keying information. BR, Daniel On Thu, Mar 6, 2014 at 6:11 PM, Daniel Palomares <daniel.palomares.i...@gmail.com> wrote: > 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 > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
