Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Jun 2009 01:27:42 +0300

I'm not so sure about that. The authentication in the IKE_AUTH exchange that follows the resumption only proves that the (new) responder can decipher the ticket (or has access to the ticket database).

Presumably a "cluster" of gateways backing each other up would have the same IDr, but if they're using (for example) IPv4 or IPv6 addresses as IDr, these IDrs could be different.

IOW I don't see much security value in mandating that the responder show the same IDr, although I can't think of a really good reason why they would not.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Friday, May 29, 2009 21:46

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?

Email secured by Check Point

---

From: <[email-masked]>
Date: Fri, 5 Jun 2009 14:23:06 +0200

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

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 12 Jun 2009 22:08:57 +0300

Hi Pasi,

Sorry for the late reply.

I believe most people would NOT expect a properly terminated (deleted) IKE
SA to be resumed. To give one example, suppose I "downsize" a user and
revoke his access rights. Today I will simply terminate (=delete) all his
existing SAs, and then will rely on the next IKE setup to revalidate the
user with the AAA server, which will correctly fail. Resumption would bypass
this check.

We could add a flag to the 2 notifications for the gateway to signal to the
client that it implements a different semantics, i.e. it is willing to
resume a previously deleted SA. Do you think this use case is worth the
added complexity?

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 05, 2009 15:23
> To: Yaron Sheffer; [email-masked]
> Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-
> 04.txt
> 
> Yaron Sheffer wrote:
> 
> <snip>
> Scanned by Check Point Total Security Gateway.

---

From: <[email-masked]>
Date: Wed, 17 Jun 2009 20:06:40 +0200

Yaron Sheffer wrote:

> I believe most people would NOT expect a properly terminated
> (deleted) IKE SA to be resumed. To give one example, suppose I
> "downsize" a user and revoke his access rights. Today I will simply
> terminate (=delete) all his existing SAs, and then will rely on the
> next IKE setup to revalidate the user with the AAA server, which
> will correctly fail. Resumption would bypass this check.

If you want to make sure the downsized user doesn't come back and
bypass the AAA server, you need either ticket-by-reference or some
gateway-side state to prevent use of tickets that have been revoked.

In either case, it seems the gateway could prevent resumption in cases
where the gateway closed the IKE_SA, but still allow it if the client
closed the IKE_SA, no?

(BTW, in case of ticket-by-value, the gateway doesn't need per-ticket 
"black list" -- e.g. Eric Rescorla's "stateless tokens" draft suggested 
using a fixed-size Bloom filter to keep track of tickets that should not
be accepted any more.)

But it seems regardless of whether we allow resuming a properly
closed IKE_SA or not, this is an issue that should be discussed
in the Security Considerations section. If most people would
expect revoking access rights to work the way you describe, it might 
come as a surprise that it does not, when using ticket-by-value...

> We could add a flag to the 2 notifications for the gateway to signal
> to the client that it implements a different semantics, i.e. it is
> willing to resume a previously deleted SA. Do you think this use
> case is worth the added complexity?

It seems we're looking at this from quite different angles -- to me,
*not* allowing resumption here is added complexity, since it's 
more difficult to implement than allowing resumption...?

Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Jun 2009 00:06:46 +0300

I agree with Yaron that it should be the way it is now described in the draft. If either side deleted the IKE SA, then it should not come back to life through session resumption. Specifically, the client should not get reconnected without authentication. The laptop example is excellent. If I close my laptop in Tel Aviv, and fly to Stockholm, and some guy from baggage handling gets at my laptop, they should not be able to resume a session to my workplace. I should need to authenticate again (if I was dilligent enough to disconnect the session).

With a ticket-by-reference scheme, this is easy - the gateway deletes the ticket from the store when the IKE SA is deleted. With ticket-by-value this doesn't work. After a crash, the gateway gets presented with a valid ticket, and has no way of knowing whether the IKE SA associated with that ticket has or has not been closed.  The gateway could keep a blacklist (ticket revocation list?) but that really does add lots of complexity.

I think the spec should reduce this to a SHOULD, with an explanation in security considerations about what it means for ticket-by-value and ticket-by-reference.

Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Peny Yang <[email-masked]>
Date: Tue, 23 Jun 2009 11:06:18 +0800

Dear all:

Sorry for the late comments.
I went through the -06 version of IKEv2 session resumption draft.
Basically, I agree with more of the content expect for the new
IKE_SESSION_RESUME exchange.

Well,  we've discussed pros and cons of IKE_SA_INIT and
IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus
is still not fully achieved on this item. So far, I still prefer to
choosing extended IKE_SA_INIT for ticket presenting. This solution can
 be found in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01

As a summary, the virtues are as follows:
1) RFC5077 (TLS session resumption) also uses the similar scheme,
which extends the message of clienthello with session ticket
extension. The extended IKE_SA_INIT solution has the similar way. It's
easy to extend the base IKEv2 protocol stack to support session
resumption.
2) Considering the case of failing session resumption, the extended
IKE_SA_INIT solution can save one round trip.
3) As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated
after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way
need less code to be supported compared with IKE_SESSION_RESUME.

The down side:
1) some people thought the way of extended IKE_SA_INIT will make the
base IKEv2 protocol stack more complex. IMHO, it's implementation
specific.

Again, I still support to use extended IKE_SA_INIT for ticket
presenting instead of IKE_SESSION_RESUME.

Thanks
BRG
Peny

On Sat, May 16, 2009 at 4:06 AM, Paul Hoffman<[email-masked]> wrote:
> 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