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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
