Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
RFC 5723
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert No Objection
INTRODUCTION, paragraph 13: > Abstract Is long, and overlaps with the introduction a lot.
(Jari Arkko; former steering group member) (was Discuss) Yes
(Pasi Eronen; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Alexey Melnikov; former steering group member) No Objection
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.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
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.
(Lisa Dusseault; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
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.
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection