Subject: Re: [IPsec] Resuming the session resumption discussion

From: "xuke" <[email-masked]>
Date: Thu, 16 Oct 2008 17:44:11 +0800

Hi, all

Basically, I agree with Yoav that the "ticket" concept is very similar
to the "stub" concept.
We did once thought to store the stub in the corresponding client
separately. And, in our draft, we also analyzed this case.
However, In the case of stub co-located with IPsec Client, the stub
MUST be perfectly protected to prevent the malicious attackers from
cracking the stub, if they can obtain the stub on the link.  Actually,
from previous experiences, even if the stub is strongly encrypted,
there still has the risk. With the development of harware in accord
with the Moore's Law, the capability of computing equipment will be
increased step by step. Sometime, somehow, the brutal force decryption
of the stub/ticket encryption method may be possible.  And, there is
also posibility that the currently safe encryption algorithm may be
proved to be mathematically solvable.  So, in our draft, it is only
optional to transport the stub on the untrusted network, even if it
can be protected strongly.

And, If we see it from the client point of view, the client does not
need to maintain a data structure to store the stubs.
Lastly, in the mobile network, the transfer of stubs over the air at
client side surely have much more service cost than doing it over the
fiber in network side.

All in all, to keep the client to be simpler, easier for upgrade in
the future and keep the stub safer, personally, I'd rather to keep the
stub in the network side.

xuke
Tsinghua University

> <co-chair hat on>
>
> We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below.
>
> The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says.
>
> Extra points are awarded for not copying this entire message in your response. :-)
>
> --Paul Hoffman
>
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 16 Oct 2008 16:00:17 -0700 (PDT)

Hello,

  I'm not sure what "perfectly protected" means but if one uses a
key-wrapping technique with provable security (like RFC 5297-- AES-SIV,
which is in AUTH48 state and should be published very shortly) then
an attack against the ticket should be no more possible than an attack
against the IPsec traffic itself. These tickets must use deterministic
authenticated encryption and provided the thing that's being wrapped in
the ticket is a cryptographic key, like SK_d, the randomness it adds
will allow the ticket protection scheme to achieve semantic security.

  Dan.

On Thu, October 16, 2008 2:44 am, xuke wrote:
>> We now have revised drafts from the two parties who has published
>> earlier drafts on session resumption. The (truncated) announcements are
>> below.
>>
>> The WG should start discussing what we want from session resumption and
>> which of these two drafts (or what ideas from each of these two drafts)
>> is of interest to the WG. As a reminder, I start off with what our
>> charter says.
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 20 Oct 2008 19:45:04 +0200

<co-chair hat off>

Seen from a protocol point of view, it is critically important that the
ticket (or stub) is secured. But the contents of the ticket is much less
critical, since it is opaque to the client anyway.

Draft-tschofenig mentions that the ticket can contain the actual IKE
(subset-) state, or it can contain a reference (pointer) to such state,
which is presumably stored on the gateway or near it. Quoting:

	Ticket reference:  A pointer to a ticket.  When resolving the
      reference it obtains the ticket.

	In subsequent sections we use the term ticket and thereby refer to
both the ticket per value and by reference, unless indicated otherwise.

(And yes, we could do a better job of mentioning this concept in Sec. 5,
where we describe the ticket in detail.)

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
xuke
Sent: Thursday, October 16, 2008 11:44
To: ipsec
Subject: Re: [IPsec] Resuming the session resumption discussion

Hi, all

xuke
Tsinghua University

> <co-chair hat on>
>
> We now have revised drafts from the two parties who has published earlier
drafts on session resumption. The (truncated) announcements are below.
> The WG should start discussing what we want from session resumption and
which of these two drafts (or what ideas from each of these two drafts) is
of interest to the WG. As a reminder, I start off with what our charter
says.

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 20 Oct 2008 20:35:47 +0200

Dear authors,

I would not like to offend how your authors are doing here.

But we do carefully read through your previous draft and your "update" part
of the new draft,
Nothing could be found related to the "ticket reference".

In such case, something would better be reminded that if some idea has been
invented by the other draft, and you would like to use it by some revised
form, please do refer to that draft.

Many thanks

-Hui

2008/10/20 Yaron Sheffer <[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 20 Oct 2008 20:56:55 +0200

Hi Hui,

Yes, we should have cited your draft. And we could have had a more detailed
description of the changes from the previous version.

Note however that the idea of server-side storage of crypto protocol state
has been around for ages, e.g. in the TLS "session cache" notion (RFC 2246).

Thanks,

            Yaron

  _____  

From: Hui Deng [mailto:[email-masked]] 
Sent: Monday, October 20, 2008 20:36
To: Yaron Sheffer
Cc: [email-masked]; ipsec
Subject: Re: [IPsec] Resuming the session resumption discussion

Dear authors,

Many thanks

-Hui

<co-chair hat off>

Thanks,
       Yaron

-----Original Message-----

xuke

Hi, all

xuke
Tsinghua University

_______________________________________________
IPsec mailing list
IPsec at ietf.org <http://ietf.org/> 
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 20 Oct 2008 22:19:05 +0300

Since we got asked by the group to get rid of the ticket format
recommendations I believe we don't need to talk about the content at all. 
As such, it could be anything. We could call it ticket blob. 

I guess that should make everyone happy. 

Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Yaron Sheffer
	Sent: 20 October, 2008 21:57
	To: Hui Deng
	Cc: ipsec; [email-masked]
	Subject: Re: [IPsec] Resuming the session resumption discussion

	Hi Hui,

	Yes, we should have cited your draft. And we could have had a more
detailed description of the changes from the previous version.

	Note however that the idea of server-side storage of crypto protocol
state has been around for ages, e.g. in the TLS "session cache" notion (RFC
2246).

	Thanks,

	            Yaron

	________________________________

	Dear authors,

	But we do carefully read through your previous draft and your
"update" part of the new draft,

	In such case, something would better be reminded that if some idea
has been invented by the other draft, and you would like to use it by some
revised form, please do refer to that draft.

	Many thanks

	-Hui

	<co-chair hat off>
	
	Seen from a protocol point of view, it is critically important that
the
	ticket (or stub) is secured. But the contents of the ticket is much
less
	critical, since it is opaque to the client anyway.
	
	Draft-tschofenig mentions that the ticket can contain the actual IKE
	(subset-) state, or it can contain a reference (pointer) to such
state,
	which is presumably stored on the gateway or near it. Quoting:

	       In subsequent sections we use the term ticket and thereby
refer to
	both the ticket per value and by reference, unless indicated
otherwise.
	
	(And yes, we could do a better job of mentioning this concept in
Sec. 5,
	where we describe the ticket in detail.)

	Thanks,
	       Yaron
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of

	xuke

	Hi, all
	
	Basically, I agree with Yoav that the "ticket" concept is very
similar
	to the "stub" concept.
	cracking the stub, if they can obtain the stub on the link.
Actually,
	increased step by step. Sometime, somehow, the brutal force
decryption
	
	And, If we see it from the client point of view, the client does not
	need to maintain a data structure to store the stubs.
	Lastly, in the mobile network, the transfer of stubs over the air at
	client side surely have much more service cost than doing it over
the
	fiber in network side.
	
	All in all, to keep the client to be simpler, easier for upgrade in
	the future and keep the stub safer, personally, I'd rather to keep
the
	stub in the network side.
	
	xuke
	Tsinghua University
	
	> We now have revised drafts from the two parties who has published
earlier
	drafts on session resumption. The (truncated) announcements are
below.
	> The WG should start discussing what we want from session
resumption and
	which of these two drafts (or what ideas from each of these two
drafts) is
	of interest to the WG. As a reminder, I start off with what our
charter
	says.
	>
	> Extra points are awarded for not copying this entire message in
your
	response. :-)

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 20 Oct 2008 22:43:25 +0300

I thought about using the term "ticket blob" again and I think it is a
really good idea. 
It puts a stronger emphasis on the fact that the document is not supposed to
specify the content of the payload. 

I guess I will make this change to the draft. 

Thoughts? 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Hannes Tschofenig
>Sent: 20 October, 2008 22:19
>To: 'Yaron Sheffer'; 'Hui Deng'
>Cc: 'ipsec'; [email-masked]
>Since we got asked by the group to get rid of the ticket 
>format recommendations I believe we don't need to talk about 
>the content at all. 
>	From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Yaron Sheffer
>	Yes, we should have cited your draft. And we could have 
>had a more detailed description of the changes from the 
>previous version.
>
>	 
>
>	Note however that the idea of server-side storage of 
>crypto protocol state has been around for ages, e.g. in the 
>TLS "session cache" notion (RFC 2246).
>
>	 
>
>	Thanks,
>
>	            Yaron
>
>	 
>
>	But we do carefully read through your previous draft 
>and your "update" part of the new draft,
>
>	In such case, something would better be reminded that 
>if some idea has been invented by the other draft, and you 
>would like to use it by some revised form, please do refer to 
>that draft.
>
>	 
>
>	Many thanks
>
>	 
>
>	-Hui
>
>	From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of
>
>	xuke
>	> Extra points are awarded for not copying this entire 
>message in your
>	response. :-)
>	>
>	> --Paul Hoffman
>	>

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Oct 2008 16:39:11 -0400

The term "opaque ticket" may work better for people from diverse cultures.

Russ

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 20 Oct 2008 15:50:01 -0700 (PDT)

Well, strictly speaking it says "detailed contents" so I guess it
depends on what the word "detailed" means.

  If nothing is said on the matter I fear that the scenario that Xuke
mentioned will happen. Just because there are no interoperability
requirements on some particular part of a protocol does not mean we
can't recommend (or even insist upon) behavior. There is precedence for
recommending behavior on things that have no interoperability impact.

  If the opaque blob is a reference or index into some server-maintained
context and has no sensitive components then there really isn't much to
worry about but if the opaque blob contains cryptographic keying material
then I don't think we can be silent on the matter.

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Oct 2008 11:08:27 +0200

Getting rid of a format may be OK, but your draft should list  
everything that has to be inside the ticket, even though it's possible  
to figure it out from the protocol.

And maybe we also need a document to explain the terms blob, ticket,  
token, stub and opaque, and when each is appropriate :-)

Yoav

---

From: "xuke" <[email-masked]>
Date: Tue, 21 Oct 2008 19:24:15 +0800

Hi, Dan

Basically, I agree with your point. That's one of the reason we put
the client co-located stub as an option in the draft.
By the way, one thing for sure, the stub in the network side is PURELY safe.

Thanks
xuke