Yaron Sheffer wrote: <snip> > > The current ikev2-resumption draft, on the other hand, seems to > > assume a quite different model, where resumption replaces the old > > connection, and can be done only if the old connection was > > interrupted. > > > > This would seem to preclude one case discussed earlier: I close my > > laptop (cleanly) at work, commute, and reconnect at home (without > > having to do EAP again; e.g. type in one-time password). Or "switch > > off my phone (cleanly), fly to IETF meeting, and switch it back on". > > > > In case of IKEv2, having multiple parallel IKE connections is > > probably less common than with TLS (where it's very common), but > > to me it seems using the IKE_SESSION_RESUME handshake when the old > > IKE_SA was cleanly closed would be quite useful, and should be > > supported. (And making the "new connection" completely independent > > of the old one might simplify the protocol anyway.) > > > > (Or in other words: I'd propose changing Section 7.2, 1st paragraph, > > and making these MUSTs MAYs.) > > [YS] Let me answer at two levels, the principle of session > resumption and the particular use case you present. > > At the principle level, I think SSL/TLS history, going back to HTTP > 1.0, required support of many concurrent "cloned" sessions. Typical > use of IKE, at least for RA VPN, is different, preferring a single > instance per client. So much so that even the concept of > reauthentication was only recognized post 4306 (RFC 4478). > > Regarding the use case, most security policies will require you to > reauthenticate after a logout/suspend. But even if your scenario is > legit, I don't see why the current draft precludes the client from > implementing this behavior. > > One interesting use case that would support your view is setting up > simultaneous IKE SAs to multiple gateways, with no need to > authenticate to each one separately. But that's of course WAY out of > scope. > > Also, I believe your issue is NOT with the MUSTs in Sec. 7.2, it is > rather with the last paragraph of 4.3, quoted here: > > When the responder receives a ticket for an IKE SA that is still > active and if the responder accepts it, then the old SA SHOULD be > silently deleted without sending a DELETE informational > exchange. Consequently, all the dependent IPsec child SAs are also > deleted. This happens after both peers have been authenticated.
Note that my comment had two somewhat separate concerns: prohibiting parallel IKE SAs, and prohibiting using this mechanism when the IKE_SA was cleanly closed. I think you're right that parallel IKE SAs aren't really needed. But why the resumption mechanism can't be used if the session was termined cleanly instead of dead-peer-detection timeout? I think this restriction doesn't give us any benefits, and loses some flexibility.. <snip> > > 6) Section 6: The word "Unspecified" is probably wrong here -- > > this document has to specify these (but clearly an implementation > > doesn't have to include in the ticket any data it never uses). > > [YS] I have used "unspecified" as synonymous with "implementation > specific". Or do you want to propose alternative text? I don't think "implementation speific" is the right term either, If the implementation needs e.g. the certificates after resumption, it is *not* implementation specific whether they come from the ticket (or local store) or the new exchange. I think the text should say "From the ticket", with a note explaining that some implementations may not need this information during/after resumption, and in this case, it doesn't have to be stored anywhere. <snip> > > 8) The text about handling IDr is very unclear -- certainly the > > gateway can't start to use some other IDr in the new IKE_SA, > > without authenticating it? > > [YS] Unfortunately you are right, but this eliminates important > flexibility in naming the gateways. We *could* say that the client > trusts the gateway to identify itself, because the gateway is > clearly a member of the "trusted gateways" group (it is able to > decrypt the ticket). But that still sounds wrong. The gateway is part of the *same* group as the original gateway (who authenticated itself, probably with certificates) -- but that doesn't mean it's trusted to use someone else's SPD/PAD entries (for some other gateway/group of gateways than the original one). So on client, the IDr (used for SPD/PAD lookups) should come from the ticket/local storage, not from the new exchange... (unless the gateway actually authenticates it's really the new IDr) > > 9) Section 7.1: Why are storing SPIi/SPIr and the authentication > > method "MUST"s? (The gateway doesn't seem to really need those for > > anything) > > > [YS] SPIi/SPIr are used to identify the SA we are resuming (see > discussion above). That seems like an internal implementation detail... > The authentication method seems to be useful, e.g. to know that you > should expect a cert to be included. But yes, the auth method could > be left implementation-dependent. But the client does *not* include a certificate when doing resumption, so if the gateway expects to receive a cert, it will never get one? However, the draft should probably clarify that the ticket (or local storage) has to include the authenticated peer identity used for policy lookups -- which is not necessarily the same as IDi payload (see RFC 4718, Section 3.5). (And if the value from IDi isn't actually used for anything, it obviously doesn't have to be stored either.) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
