Hi Pasi, Thanks for your review. Please see my comments below.
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> pasi.ero...@nokia.com
> Sent: Friday, May 29, 2009 21:47
> To: ipsec@ietf.org
> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-
> 04.txt
>
> <not wearing any hats>
>
> 1) First, sending a comment I already sent to the mailing list on
> March 17:
>
> In TLS session resumption, resumption basically creates a new TLS
> "connection" (using information from local session cache, or ticket in
> case of RFC5077), and does *not* really resume the old connection.
> The old connection can still exist (and the session resumption
> handshake won't cause it to be closed), or it could have been
> interrupted earlier, or it could have been cleanly closed earlier.
>
> 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.
>
> 2) The draft is currently very vague about the use cases for this
> mechanism. As the discussion has shown, there's more than one use
> case, and folks clearly have different opinions about which of them
> are important and which are not.
>
> However, being vague makes the draft quite difficult to understand for
> a reader that hasn't participated in the discussions. I think the
> draft should mention that there are several different use cases, and
> give concrete examples (but not take an opinion about which of them
> are important or not). Perhaps something like this (going somewhere in
> Section 1):
>
> Possible situations where the mechanism specified in this document
> could be useful include the following (note that this list is not
> meant to be exhaustive, and any particular deployment may not care
> about all of these):
>
> - If a client temporarily loses network connectivity (and the IKE
> SA times out), this mechanism could be used to re-establish the
> SA with less overhead (network, CPU, authentication infrastructure)
> and without requiring user interaction for authentication.
>
> - If the connectivity problems affect a large number of clients
> (e.g., a large remote access VPN gateway), when the connectivity
> is restored, all the clients might reconnect almost simultaneously.
> This mechanism could be used to reduce the load spike for
> cryptographic operations and authentication infrastructure.
>
> - Losing connectivity can also be predictable and planned; for
> example, putting a laptop to "stand-by" mode before travelling.
> This mechanisms could be used to re-establish the SA when
> the laptop is switch backed on (again, with less overhead and
> without requiring user interaction for authentication).
>
>
[YS] Agree, pending the above discussion.
> 3) Section 1, 2nd paragraph should also mention one additional reason
> someone might have for using this mechanism (even if roundtrips or CPU
> time is not an issue): doing the authentication from scratch could
> require user interaction.
>
[YS] Yes.
>
> 4) Some aspects of the protocol are described very thinly. For example:
>
> - Section 4.2 describes what message is sent by the gateway, but not
> what the client should do when it receives it
> - Section 4.3 just says the gateway "accepts the ticket", but not
> all the steps involved in this (there's lot about this in Sections 5
> and 6 though)
> - Section 4.3 says the client initiates an IKE_AUTH exchange, but
> doesn't say much about how this differs from an ordinary IKE_AUTH
> exchange (except for AUTH payload)
> - Section 4.4 it's possible to use N(COOKIE) in IKE_SESSION_RESUME,
> but nothing else (e.g. in IKE_SA_INIT request, N(COOKIE) must
> always be the first payload -- but the message diagram earlier
> puts other notifications at the end. Which is it?)
>
> For all of these, I'm sure the authors have some idea how this is
> supposed to work -- but I don't think the current text is very likely
> to lead to interoperable implementations. I'd recommend taking
> Sections 4.1...4.6, 4.8, 5 and 6 and doing a reorganization for that
> text (Section 4.7 could probably be separate).
>
[YS] OK. I disagree on some of the editorials (some of the crypto is better
off in a separate section), but on the whole I agree and will reorganize the
text.
> 5) Section 5 and 6 present roughly the same information, and need to
> be combined. Currently, the table I sent was just added to the end of
> the old text (and some of the old text was plain wrong -- for example,
> the client cannot obviously take the SA value from the ticket).
>
> 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?
> 7) Section 9.6, "using channel security" sounds like it would
> refer to the IKEv2 encrypted payloads -- but that would be clearly
> wrong?
[YS] The ticket is "self protecting". I will reword.
>
> 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.
> 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). 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.
> Best regards,
> Pasi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
