On Oct 7, 2010, at 10:50 PM, Keith Welter wrote:
Yoav Nir <y...@checkpoint.com<mailto:y...@checkpoint.com>> wrote on 10/07/2010 12:26:36 PM: > I was not suggesting to use SK_d itself. Sorry, I misread your note. You clearly did not suggest using SK_d itself. > > RFC 5996 says this: > > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } > = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) > > > I suggest replaceing/augmenting it with this: > > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri | SK_rr} > = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) > > Where SK_ri and SK_rr are x number of bits each (128? 256? same as > the SK_d?) and these can be used for re-authentication later. First, to level-set, I assume that we are talking about key generation during an IKE_AUTH that occurs on a new IKE SA rather than the alternative approach you described of doing a subsequent IKE_AUTH exchange on the original IKE SA. I'm confused by what you suggest here though. Wouldn't the augmentation go in the data to which prf+ is applied, rather than the output? For example: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >> = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | SK_ri | SK_rr ) << augmented data from which to derive keys >> Is that what you meant? It seems to me that any piece of keying material from the old IKE SA that both sides incorporate into the key generation for the new IKE SA ought to be sufficient. So here is another option to consider: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >> = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | prior SK_d ) << augmented data from which to derive keys >> Nope. I just meant that in the original IKE SA creation, you generate some more values and keep them (in both sides). Later, when we do a re-auth, the peers prove linkage to the old SA by including these SK_ri and SK_rr in the REAUTH_SA notification. I didn't mean to change the calculation of the keys in the new SA, just produce some more material.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
