Hi Yaron, Hmm... yes, probably adding a nonce there would solve the freshness issue.
Best regards, Pasi > -----Original Message----- > From: ext Yaron Sheffer [mailto:[email protected]] > Sent: 17 March, 2009 18:03 > To: Eronen Pasi (Nokia-NRC/Helsinki); [email protected] > Subject: RE: Issue (resumption): SK_* not necessarily fresh? > > Hi Pasi, > > Thanks for your extensive comments. > > One way to deal with the attack you present here is by adding > a nonce to the > responder's side: > > HDR, Ni, N(TICKET_OPAQUE'), [N+,] SK{...} --> > > <-- HDR, Nr', SK'{Nr, SAr2, [TSi, TSr], ...} > > Where Nr' is the new nonce, SK' depends on the ticket, Ni and Nr'. > > Would that resolve the freshness issue? > > Thanks, > Yaron > > > -----Original Message----- > > From: [email protected] > [mailto:[email protected]] On Behalf Of > > [email protected] > > Sent: Tuesday, March 17, 2009 12:15 > > To: [email protected] > > Subject: [IPsec] Issue (resumption): SK_* not necessarily fresh? > > > > <not wearing any hats> > > > > If an attacker replays a valid IKE_SESSION_RESUME request (and the > > gateway/gateway cluster does not have state to detect > this), then the > > SK_* keys used in the IKE_SESSION_RESUME response will not be fresh > > (since they depend only on the ticket and Ni). > > > > If the IKE_SA uses CBC mode encryption and HMAC for > integrity, that's > > probably not a very big problem. But if the IKE_SA uses CTR, CCM or > > GCM mode, it probably is. > > > > I already pointed out this to the authors in December 2007, but the > > latest draft doesn't seem to say anything about it yet. Back then, > > I argued that the simplest solution to this (and some other > > complexities) is a two-roundtrip-protocol, but if others > think saving > > one RTT is worth the extra complexity, this is one part of > that extra > > complexity that has to be addressed somehow... > > > > BTW, the COOKIE roundtrip in Section 4.3.2 does *not* solve this > > problem; a two-roundtrip version not having this problem would look > > something like this: > > > > HDR(A,0), Ni, N(TICKET_OPAQUE) --> > > <-- HDR(A,B), Nr > > [ calculate SKEYSEED = prf(old SK_d, Ni | Nr) ] > > HDR(A,B), SK { AUTH, [CP], SAi2, TSi, TSr, } --> > > [ AUTH = prf(SK_pi, <msg octets as in IKE_AUTH>) ] > > <-- HDR(A,B), SK { AUTH, [CP], SAr2, TSi, TSr } > > [ AUTH = prf(SK_pr, <msg octets as in IKE_AUTH>) ] > > > > Best regards, > > Pasi > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
