Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-04.txt

From: [email-masked]
Date: Fri, 15 May 2009 09:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : IKEv2 Session Resumption
	Author(s)       : Y. Sheffer, et al.
	Filename        : draft-ietf-ipsecme-ikev2-resumption-04.txt
	Pages           : 27
	Date            : 2009-05-15

The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved.
In remote access situations, the Extensible Authentication Protocol
(EAP) is used for authentication, which adds several more round trips
and consequently latency.

To re-establish security associations (SAs) upon a failure recovery
condition is time consuming especially when an IPsec peer (such as a
VPN gateway) needs to re-establish a large number of SAs with various
end points.  A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.

In order to avoid the need to re-run the key exchange protocol from
scratch it would be useful to provide an efficient way to resume an
IKE/IPsec session.  This document proposes an extension to IKEv2 that
allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA.

A client can reconnect to a gateway from which it was disconnected.
The proposed approach requires passing opaque data from the IKEv2
responder to the IKEv2 initiator, which is later made available to
the IKEv2 responder for re-authentication.  We use the term ticket to
refer to the opaque data that is created by the IKEv2 responder.
This document does not specify the format of the ticket but
recommendations are provided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 May 2009 13:06:27 -0700

Greetings again. There has been almost no discussion on the -03 draft, and Yaron has made some small changes in the -04. As we discussed at the interim WG meeting, we would like to advance this before Stockholm.

Therefore, this is the beginning of the two-week WG Last Call, which will end May 29. The current document is at <http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-04.txt>.

Even if you have not read the document before now, please do so. Having fresh eyes on the document often brings up important issues. Send any comments to the list, even if they are as simple as "I read it and it seems fine". We would like to gauge how much support there is or isn't for this protocol.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 May 2009 19:21:18 -0700

[[ Just a nudge. It would be great to hear from folks who have read this document before the end of this week. If you are active in the WG but haven't read the document, please do: it's not that long. --Paul ]]

At 1:06 PM -0700 5/15/09, Paul Hoffman wrote:
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Fri, 29 May 2009 20:46:52 +0200

<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.)

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).

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.

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).

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).

7) Section 9.6, "using channel security" sounds like it would
refer to the IKEv2 encrypted payloads -- but that would be clearly
wrong?

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?

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)

Best regards,
Pasi

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 31 May 2009 19:16:27 +0300

Hi Pasi,

Thanks for your review. Please see my comments below.

	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, May 29, 2009 21:47
> To: [email-masked]
> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-
> 04.txt
> 
> <not wearing any hats>
> 
[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.
>     without requiring user interaction for authentication).
[YS] Agree, pending the above discussion.

> require user interaction.
[YS] Yes.
> 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.

> 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?

> refer to the IKEv2 encrypted payloads -- but that would be clearly
[YS] The ticket is "self protecting". I will reword.
> 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.

> method "MUST"s? (The gateway doesn't seem to really need those
[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. 
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 May 2009 12:17:34 -0700

>Or do you want to propose alternative text?

FWIW, I think "implementation-specific" is probably right here.

>gateways" group (it is able to decrypt the ticket). But that still sounds

Being a member of the "trusted gateways" group doesn't sound wrong to me: in fact, it sounds like the correct way to say it. If that group has just one member, so be it.

--Paul Hoffman, Director
--VPN Consortium