<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
