Subject: [IPsec] Proposed text for working items of IKE session resumption

From: Peny Yang <[email-masked]>
Date: Tue, 20 Jan 2009 21:18:07 +0800

Hi, IPsecme folks:

We had quite a lot of discussion in the list and Minneapolis meeting.
We collected the comments on the pros and cons of
ticket-by-value/ticket-by-reference, and related protocols. Hereby, we
proposed the text as below. Your comments are more than welcome.

Thanks a lot
BRG
Peny

Text Proposal
###########################################
1) Format of Ticket (TbV and TvR)

Original text:
none.

Proposed text:
5.5 Format of TbV and TbR
The TvV/TvR will be included in the ticket field of TICKET_OPAQUE
(section 4.4) payload when it's requested by client or presented to
gateway.

0                            1                          2
            3
0 1 2 3 4 5 6  7 8  9  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 01
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-++
 !V!Rers!
             !
+-+-+-+-
           +
~                             Encrypted Ticket                              ~
!
                !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
V bit: 0 - TbV, 1-TbR
Rers (3 bit): Reserved.

2) Protocol of ticket presenting
After section 4.3

Proposed Text:
4.2.2. Presenting a ticket by extension of IKE_SA_INIT

This document also supports the way of utilizing the generic IKEv2
IKE_SA_INIT exchange for session resumption. The client may initialize
a regular IKE exchange without enclosing the TbV/TbR in the
IKE_SA_INIT message. The client SHOULD NOT enclose the payloads of
N(TICKET_OPAQUE), [N+,] and SK {IDi, [IDr,]}, unless it knows that the
gateway supports it.
The client should decide when it can use the IKE_SA_INIT exchange to
do the session resumption, after it detects the interruption of IKEv2
responder. The client's decision may be based on the local policies.
The ticket is only for one-time use, on matter it's on network side or
client.

When IKEv2 client detects the interruption of IKEv2 responder and
decides to use the extension of IKE_SA_INIT exchange for session
resumption, It will send the IKE_SA_INIT message as below:

    Initiator                                                     Responder
  -----------                                                       -----------
HDR, SAi, KEi, Ni, N(TICKET_OPAQUE), [N+,]
                                SK {IDi, [IDr,], [Ticket ID]} -->
      Figure: Ticket presenting by client

The exchange type in HDR is set to 'IKE_SA_INIT'. KEi value is
collected from the the old unexpired IKE_SA in client.

When the IKEv2 gateway receives a IKE_SA_INIT with the payload of
N(TICKET_OPAQUE). It MUST check the Ticket type in the V bit. If it's
a TbR, gateway will use the reference to get the full content of
ticket from somewhere in the network side. How to retrieve the ticket
by reference is out of the scope in this document. If it's a TbV,
gateway can get the content of ticket from this IKE_SA_INIT message.
After ticket validation, one of the following steps if it supports the
extension defined in this document:

o If this IKE_SA_INIT message for session resumption is valid for
gateway, it will accept it and the follow-up CREATE_CHILD_SA exchanges
can be initiated by client.
  Initiator                Responder
  -----------                -----------
                     <--  HDR, SK {IDr}

             Figure: IKEv2 gateway accepts the ticket
the exchange type in HDR is set to 'IKE_SA_INIT'.

o  It responds with an regular IKE_SA_INIT response as defined in
RFC4306, if it rejects the ticket for any reason (such as the example
mentioned in section 4.2.1).  In that case, the initiator can fall
back to the regular IKE procedure.

o  When the responder receives a ticket for an IKE SA that is still
active and if the responder accepts it, then the old SAs SHOULD be
silently deleted without sending a DELETE informational exchange.

4.2.2.1 Protection of the IKE_SA_INIT extension for session resumption.
The way is the same as defined in section 4.2.1.1

4.2.2.2 DoS case for IKE_SA_INIT extension for session resumption.
When receiving the first message of the IKE_SA_INIT exchange for
session resumption, the gateway may decide that it is under a
denial-of-service attack. This document relies on the anti-DoS
mechanism of generic IKE_SA_INIT exchange in RFC4306.

3) Message Protection
After section 7.8

Proposed text:

7.9 Protection in IKE_SA_INIT exchange for session resumption
This document relies on the anti-DoS and reply protection mechanism of
generic IKE_SA_INIT exchange in RFC4306.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Jan 2009 14:17:09 +0200

> proposed the text as below. Your comments are more than welcome.

As the Ticket-by-reference vs Ticket-by-value is completely local
matter for the gateway, I do not see any reason to make it visible for
the client at all.

The gateway can use any format it like to store that information,
including using something like you propose (if it supports both), or
just use value directly (if it only supports values, thus always knows
it will get tickets by value all the time), or just use reference
directly (in case it only supports that).

Why is there any need to make standardized format for distinguishing
ticket-by-reference and ticket-by-value?
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Jan 2009 15:25:37 +0200

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tero Kivinen
>Sent: 21 January, 2009 14:17
>To: Peny Yang
>Cc: [email-masked]; Hui Deng
>Subject: [IPsec] Proposed text for working items of IKE 
>session resumption
>
>Peny Yang writes:
>As the Ticket-by-reference vs Ticket-by-value is completely 
>local matter for the gateway, I do not see any reason to make 
>it visible for the client at all.
>
>The gateway can use any format it like to store that 
>information, including using something like you propose (if it 
>supports both), or just use value directly (if it only 
>supports values, thus always knows it will get tickets by 
>value all the time), or just use reference directly (in case 
>it only supports that).
>
>Why is there any need to make standardized format for 
>distinguishing ticket-by-reference and ticket-by-value?
>--
>[email-masked]

---

From: Peny Yang <[email-masked]>
Date: Wed, 21 Jan 2009 23:31:57 +0800

> ticket-by-reference and ticket-by-value?
[Peny] We propose this, because some people gave the comments that
it's better to have a format for TbV and TbR. And, we made the V bit
visible because it's easier for the Gateway to decide the follow-up
actions by this
V bit, before de-cryption of ticket. And if some vendors would like to
store the tickets and en/de-cryption functions in a separated
equipment other than the gateway, this visible V bit provides more
flexibility.

Peny

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Jan 2009 14:53:32 +0200

> equipment other than the gateway, this visible V bit provides more

There is no need to put anything like that to the draft. The gateway
implementation can implement the format as it likes, and it can
include V bit or whatever if it feels like it as the ticket format
should be completely gateway local implementation matter.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 Jan 2009 10:36:36 -0500

formats for either type of token, given that it is outside the scope 
of this work to enable interoperability among different SGs.

Steve