Subject: Re: [IPsec] [ipsecme] #73: Ticket location: prefer server-side ticket

From: "Hui Deng" <[email-masked]>
Date: Tue, 20 Jan 2009 21:18:13 +0800

Hi, all:

As we discussed in Minneapolis on IKEv2 session resumption, hereby we
propose some text to this work item.
Please comment it.
Thanks in advance

-Hui

Text Proposal
***************************************************************

1) Location of Ticket

(a)
Original text:
In section 2: Terminology (line 10 of page 4):
Ticket:  An IKEv2 ticket is a data structure that contains all the
    necessary information that allows an IKEv2 responder to re-
    establish an IKEv2 security association.

Proposed text 1 in section 2: Terminology (line 10 of page 4):
Ticket:
An IKEv2 ticket is a data structure that contains all the necessary
information that allows an IKEv2 responder to re-establish an IKEv2
security association. The location of this data structure could be on
the IKEv2 client or on the network side. If it's on IKEv2 client, it
must be encrypted as specified in section 7. If it's on network side,
it could be reachable for the IKEv2 gateway and referenced by
Ticket-by-Reference (TbR)

Ticket by Reference (TbR):
A data structure presented to IKEv2 client with reference to uniqe
IKEv2 ticket of current IKEv2 client stored on network side.

Ticket by Value (TbV):
A data structure presented to IKEv2 client with full-bodied data
structure of ticket.

(b)
Proposed text 2 in section 5 after 5.2:

5.3 Location of ticket
The full-bodied content of ticket could be stored on client or network side.
If it's stored on client, it will be put in TbV. TbV presenting and
requesting can be found in section 4.  The way of TbV encryption can
be found in section 7.
If it's stored in the network side, the operators shall allocate the
non-volatile memory space for gateways to store the tickets of all the
clients. How to build the ticket storage is out of the scope. This
ticket storage must be reachable for IKEv2 gateway. The reference of
the ticket is defined in 5.4.

5.4 ticket reference.
When ticket is stored in network side, it should be referenced by
ticket reference. The content of ticket reference can be defined by
operators. It could be following types, but not limited to them:
o The operator specific ticket ID.
o The combination of IDi, IDr and old SPIr.
In this case, the ticket reference must be encrypted as defined in
section 7 and put in TbR. TbR presenting and requesting can be found
in section 4.

2) Protocol of ticket presenting
(a)
Proposed text: section 4.2. after the third paragraph
The document supports two methods to present a ticket by client.
o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's defined in
section 4.2.1
o A extension to generic IKEv2 IKE_SA_INIT exchange. It's defined in
section 4.2.2

(b)
Proposed text: section 4.2. before the fourth paragraph
4.2.1 Presenting a ticket by IKE_SESSION_RESUME

(c)
4.2.1 ==> 4.2.1.1

(d)
4,2,2 Presenting a Ticket: The DoS Case
==> 4,2,1.2 Presenting a Ticket by IKE_SESSION_RESUME: The DoS Case

(e)
4.2.3. Requesting a ticket during resumption
==> 4,2,1,3, Requesting a ticket by IKE_SESSION_RESUME during resumption

2008/12/7 ipsecme issue tracker <[email-masked]>

> #73: Ticket location: prefer server-side ticket
>
> ---------------------------------+------------------------------------------
>  Reporter:  [email-masked]  |       Owner:  [email-masked]
>     Type:  defect               |      Status:  new
>  Priority:  normal               |   Milestone:  milestone1
> Component:  ikev2-resumption     |    Severity:  Active WG Document
>  Keywords:                       |
>
> ---------------------------------+------------------------------------------
>  The document should recommend "by reference", in preference to "by value"
>  tickets; or make "by reference" a MUST, and "by value" a SHOULD/MAY.
>  Mainly for the following two reasons:
>
>  - Less bandwidth, by not sending the ticket.
>  - IKEv2 messages, especially the first one, had better not be fragmented.
>
>  See http://www.ietf.org/mail-archive/web/ipsec/current/msg03355.html and
>  numerous follow-ups.
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/73>
> ipsecme <http://tools.ietf.org/ipsecme/>
>
>
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

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

Sorry. I should propose the text following this issue tracking number.
Please comment.

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.

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.

---

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

> the ticket is defined in 5.4.

I am not really sure, how much this kind of implementation details is
needed here. I think it would be better to just let this kind of
details for the implementors to decide, not try to dictate something
here.

For example that text says that you cannot make implementation where
the network crypto processors who normally take care of IKE SAs cannot
offload unused IKE SAs to the slowpath central processor with much
bigger RAM, as that RAM is not non-volatile.

I think it is much better to just let that kind of implementation
details to the implementors to decide, as they heavily depend on the
scenario where the implementation is aimed for.

I think it is good to say things that mandate that tickets by value
MUST be encrypted, as that affects security. And it is good to say
that tickets by reference does not need to be encrypted, as they do
not contain any sensitive material (i.e all the sensitive material
(i.e. crypto keys and so on) is stored on the location pointed by the
reference), but that storage where that sensitive material is stored
MUST be protected so that only unauthorized access is not allowed.

> o A extension to generic IKEv2 IKE_SA_INIT exchange. It's defined in

I do not think we want to add yet another complication to the
IKE_SA_INIT by adding new extension for it. I think we should stick to
the simple and understandable exchanges, meaning lets just use the
separate IKE_SESSION_RESUME exchange. That allow modular building of
new exchanges, and that offers simplier implementations, meaning less
bugs...

We already had earlier discussion about this, but wanted to just send
my email telling that I am still against modifying IKE_SA_INIT
exchange for session resumption, and want to use separate
IKE_SESSION_RESUME exchange for it.
-- 
[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:38:18 +0200

>Hui Deng writes:
>I am not really sure, how much this kind of implementation 
>details is needed here. I think it would be better to just let 
>this kind of details for the implementors to decide, not try 
>to dictate something here.
>
>For example that text says that you cannot make implementation 
>where the network crypto processors who normally take care of 
>IKE SAs cannot offload unused IKE SAs to the slowpath central 
>processor with much bigger RAM, as that RAM is not non-volatile.
>
>I think it is much better to just let that kind of 
>implementation details to the implementors to decide, as they 
>heavily depend on the scenario where the implementation is aimed for.
>
>I think it is good to say things that mandate that tickets by 
>value MUST be encrypted, as that affects security. And it is 
>good to say that tickets by reference does not need to be 
>encrypted, as they do not contain any sensitive material (i.e 
>all the sensitive material (i.e. crypto keys and so on) is 
>stored on the location pointed by the reference), but that 
>storage where that sensitive material is stored MUST be 
>protected so that only unauthorized access is not allowed.
>

I again have to agree with Tero. These are nice details but go far too much
into the implementation space. 

>> Proposed text: section 4.2. after the third paragraph The document 
>> supports two methods to present a ticket by client.
>> section 4.2.1 o A extension to generic IKEv2 IKE_SA_INIT exchange. 
>> It's defined in section 4.2.2
>
>IKE_SA_INIT by adding new extension for it. I think we should 
>stick to the simple and understandable exchanges, meaning lets 
>just use the separate IKE_SESSION_RESUME exchange. That allow 
>modular building of new exchanges, and that offers simplier 
>implementations, meaning less bugs...
>
>We already had earlier discussion about this, but wanted to 
>just send my email telling that I am still against modifying 
>IKE_SA_INIT exchange for session resumption, and want to use 
>separate IKE_SESSION_RESUME exchange for it.

I am not seeing any need to change the current approach outlined in the
document. 

At http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74 some arguments were
provided by Peng for re-using the IKE_SA_INIT exchange, namely 
* simpler implementation 
* more efficient. 

As mentioned previously, Florian Tegeler has implemented the session
resumption code and  he did not find it complex to implement. Sure, there is
a learning curve to get into the specific IKEv2 code but it is not a large
enhance nor a large specification. For sure, the exact amount of time it
takes to implement this extension depends on the specific implementation of
IKEv2 and how easy it is to extend the code. 

I had a hard time to see the efficiency argument given that you are
presenting the ticket to a server that has previously provided you that
ticket. 

I am a bit reluctant to change the currently described approach just for the
fun of it. 

Ciao
Hannes

---

From: Hui Deng <[email-masked]>
Date: Wed, 21 Jan 2009 22:48:59 +0800

---

From: Hui Deng <[email-masked]>
Date: Wed, 21 Jan 2009 23:26:57 +0800

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 21 Jan 2009 18:19:49 +0200

Hi Hui, 

Tero wrote: 
		I think it is good to say things that mandate that
tickets by value
		MUST be encrypted, as that affects security. And it is
good to say
		that tickets by reference does not need to be encrypted,
as they do
		not contain any sensitive material (i.e all the
sensitive material
		(i.e. crypto keys and so on) is stored on the location
pointed by the
		reference), but that storage where that sensitive
material is stored
		MUST be protected so that only unauthorized access is
not allowed.

Hui wrote: 
	It looks good for me, thanks,

I believe that it is a good idea to add this text to the document. I
will make a text proposal. 

Thank you, Hui and Tero.  

Ciao
Hannes