Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
draft-ietf-ipsecme-ikev2-resumption-09

[Ballot discuss]
This is a well written specification and I was about to vote Yes on it.
However, I thought I saw a few small errors and I wanted to talk to you
to see if we can determine if these really are errors and whether we
need to correct them.

1. The document says:

> Specifically, the SK_xx values are required to
> protect the IKE_AUTH payloads.

At this point in the text, SK_xx has not been defined (I suppose you mean
"any shared key values established by IKEv2"), or even any specific
SK value mentioned. This came out of the blue for me at least. Please
clarify what you meant.

Also,

> AUTH = prf(SK_px, )
>
> Each of the initiator and responder uses its own SK_p value, taken
> from the newly generated IKE SA, Section 5.1.

SK_px does not appear in the document, what is it? Neither SK_px or
SK_xx have been used in RFC 4306 either. What about SK_p, do you mean
SK_pr and SK_pi? Again, please be specific in what you actually mean.
Listing which SK values you actually mean here along with their
references might be helpful.

2. The document says:

> When passing a ticket by value to the client, the ticket content MUST
> be integrity protected and encrypted.
>
> A ticket by reference does not need to be encrypted, as it does not
> contain any sensitive material, such as keying material

There are multiple levels of crypto here, perhaps you want to be more
explicit here. You mean that the encryption above is for the ticket
content, but for sure the IKE exchange where you receive the ticket
has to be encrypted, because otherwise it would be easier to
open up a DoS attack where you can create half-ready resumption IKE
SAs if you saw a ticket fly by. The document did say this earlier:

  Although the IKE SA is not fully valid until the completion of the
  IKE_AUTH exchange, the peers must create much of the SA state
  (Section 5) now.  Specifically, the SK_xx values are required to
  protect the IKE_AUTH payloads.

3. The document says:

> A man-in-the-middle may try to eavesdrop on an exchange to obtain a
> ticket by value and use it to establish a session with the IKEv2
> responder.  Since all exchanges where the client obtains a ticket are
> encrypted, this is only possible by listening in on a client's use of
> the ticket to resume a session.  However, since the ticket's contents
> are encrypted and the attacker does not know the corresponding secret
> key, a stolen ticket cannot be used by an attacker to successfully
> resume a session.  An IKEv2 responder MUST use strong encryption and
> integrity protection of the ticket to prevent an attacker from
> obtaining the ticket's contents, e.g., by using a brute force attack.
>
> A ticket by reference does not need to be encrypted.  When an
> adversary is able to eavesdrop on a resumption attempt, as described
> in the previous paragraph, then the ticket by reference may be
> obtained.  A ticket by reference cannot be used by an attacker to
> successfully resume a session, for the same reasons as for a ticket
> by value.  Moreover, the adversary MUST NOT be able to resolve the
> ticket via the reference, i.e., access control MUST be enforced to
> ensure disclosure only to authorized entities.

This text does not explain the issue that I brought up in item 3.
I would like to see that the half-created state problem is mentioned
in the security considerations text.

[Ballot comment]
I'm assuming that the malicious corrpution or deletion of stored tickets has only a small disruptive affect on session recovery. That is, an attempt will be made to recover the ticket before dropping abck to the current processing rules (pre-this-draft).
---
The use of ! rather than | in protocol object figures is unusual, but not illegal.
---
Section 7 identifies the different notification messages by "notification numbers" but the subsequent subsections (7.1 etc.) use the term "Notify Message Type". According to the IANA section and the registry, the latter term is correct.

[Ballot comment]
Michael Sneed notes in his OPS-DIR review the following:

Section 9.1 of the "Security Considerations"  could use some clarification: the inability of an attacker to use a stolen unencrypted "ticket by reference" is explained as "for the same reasons as for a ticket by value", but for a "ticket by value" the explanation is that the ticket is encrypted.

[Ballot discuss]
This is a good document, and I support its publication.  There is one issue that I would
suggest addressing - probably in the security considerations - before publication, though.

When an IKEv2 responder decides to provide a ticket for session resumption to an IKEv2
initiator, they are implicitly trusting the initiator to manage this ticket to ensure that new
sessions are not created for a different user.  Specifically, Section 6.2 states that "when
credentials associated with the IKE SA are invalidated (e.g. when a user logs out), the ticket
MUST be deleted."  This requirement can only be enforced by the responder, so a rogue
IKEv2 responder could misuse the ticket without user knowledge.

It seems the IKEv2 responder is extending greater trust to the initiator when providing
a ticket than when they accept the initial connection.  I have no problem with that, but
suspect it should be highlighted somewhere.

[Ballot discuss]
This is a good document, and I support its publication.  There is one issue that I might need
to be addressed - probably in the security considerations - before publication, though.

When an IKEv2 responder decides to provide a ticket for session resumption to an IKEv2
initiator, they are implicitly trusting the initiator to manage this ticket to ensure that new
sessions are not created for a different user.  Specifically, Section 6.2 states that "when
credentials associated with the IKE SA are invalidated (e.g. when a user logs out), the ticket
MUST be deleted."  This requirement can only be enforced by the responder, so a rogue
IKEv2 responder could misuse the ticket without user knowledge.

It seems the IKEv2 responder is extending greater trust to the initiator when providing
a ticket than when they accept the initial connection.  I have no problem with that, but
suspect it should be highlighted somewhere.

[Ballot comment]
Well-written and understandable doc.  I have one small editorial comment:

From section 5:

  Note 1:  The authenticated peer identity used for policy lookups may
            not be the same as the IDi payload (see Sec. 3.5 of
            [RFC4718]), and if so, MUST be included in the ticket.  Note
            that the client may not have access to this value.

What is the condition to be checked by "if so" and what is to be included based on that condition?  It would be clearer to include text that explicitly describes the condition and what is to be included.

[Ballot comment]
This is a useful document.
Some minor comments/questions below:

4.3.1.  Prologue

  Tickets are intended for one-time use, i.e. a client MUST NOT reuse a
  ticket.  A reused ticket SHOULD be rejected by a gateway.  Note that
  a ticket is considered as used only when an IKE SA has been
  established successfully with it.

Isn't this a recipe for DoS attacks?


7.1.  TICKET_LT_OPAQUE Notify Payload

  The data for the TICKET_LT_OPAQUE Notify payload consists of the
  Notify message header, a Lifetime field and the ticket itself.  The
  four octet Lifetime field contains a relative time value, the number
  of seconds until the ticket expires (encoded as an unsigned integer).

I suggest saying that the Lifetime is encoded in network byte order.

[Ballot comment]
4.3.1.  Prologue

  Tickets are intended for one-time use, i.e. a client MUST NOT reuse a
  ticket.  A reused ticket SHOULD be rejected by a gateway.  Note that
  a ticket is considered as used only when an IKE SA has been
  established successfully with it.

Isn't this a recipe for DoS attacks?


7.1.  TICKET_LT_OPAQUE Notify Payload

  The data for the TICKET_LT_OPAQUE Notify payload consists of the
  Notify message header, a Lifetime field and the ticket itself.  The
  four octet Lifetime field contains a relative time value, the number
  of seconds until the ticket expires (encoded as an unsigned integer).

I suggest saying that the Lifetime is encoded in network byte order.

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Internet Key Exchange Version 2 (IKEv2)
Parameters" registry at
http://www.iana.org/assignments/ikev2-parameters

ACTION 1:

In the "IKEv2 Exchange Types" registry:

Value Exchange Type Reference
-------- -------------------------- ---------
TBD IKE_SESSION_RESUME [RFC-ipsecme-ikev2-resumption-07]


ACTION 2:

In the "IKEv2 Notify Message Types - Status Types" registry:

Value NOTIFY MESSAGES - STATUS TYPES Reference
------------ -------------------------------- ---------
TBD TICKET_LT_OPAQUE [RFC-ipsecme-ikev2-resumption-07]
TBD TICKET_REQUEST [RFC-ipsecme-ikev2-resumption-07]
TBD TICKET_ACK [RFC-ipsecme-ikev2-resumption-07]
TBD TICKET_NACK [RFC-ipsecme-ikev2-resumption-07]
TBD TICKET_OPAQUE [RFC-ipsecme-ikev2-resumption-07]

Here is my document shepherd write-up for IKEv2 Session Resumption (draft-ietf-ipsecme-ikev2-resumption-06.txt). Please consider it for publication.

--Paul Hoffman

I am the document shepherd for this document, inasmuch as I am the co-chair of the IPsecME WG, and the other co-chair is the lead editor on the document. I have personally reviewed this version of the document and, in particular, believe this version is ready for forwarding to the IESG for publication.

The document was reviewed heavily in the WG and went through many significant revisions and re-reviews. I would note that the WG Last Call got almost no comments, but I feel comfortable with the level from the earlier reviews. That is, I do not have concern that it needs more review before IETF LC. I know of no IPR statements on the work.

The WG consensus for this work is fairly strong, although two WG members have expressed (repeated) support for a version with one less round trip that had more security issues. As the responsible co-chair, I asked a few times to be sure that there were no other supporters, and heard none.

Yes, it passes I-D nits. Yes, the references are sane and no downrefs are needed. The IANA considerations point to the sections of the document where new entries need to be added to already-existing registries, and no new registries are needed.

Technical Summary

This document describes an efficient way to resume an IKEv2 session after it has been closed. This avoids having to re-run the key exchange protocol from scratch, which can be onerous if EAP authentication is involved. The protocol uses an opaque ticket that can be stored by the client or in a centralized storage location.

Working Group Summary

The document has rough consensus of the IPsecME WG.

Document Quality

There was interest in this protocol from many vendors, but none have come forward to say that they have implemented it.