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

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 9 Nov 2008 13:11:46 +0200

To address your comment, Dan, I have added the recommended format back into
the document. 
See Appendix A in
http://tools.ietf.org/html/draft-tschofenig-ipsecme-ikev2-resumption-01 

Ciao
Hannes

>-----Original Message-----
>From: Dan Harkins [mailto:[email-masked]] 
>Sent: 21 October, 2008 01:50
>To: Hannes Tschofenig
>Cc: 'Hannes Tschofenig'; 'Yaron Sheffer'; 'Hui Deng'; 'ipsec'; 
>[email-masked]
>Subject: Re: [IPsec] Resuming the session resumption discussion
>
>
>  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.
>
>On Mon, October 20, 2008 12:43 pm, Hannes Tschofenig wrote:
>> 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?
>>
>>>-----Original Message-----
>>>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]
>>>Subject: Re: [IPsec] Resuming the session resumption discussion
>>>
>>>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
>>>
>>>
>>>
>>>	________________________________
>>>
>>>		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,
>>>
>>>
>>>
>>>	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]>
>>>
>>>	<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
>>>
>>>	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 <http://ietf.org/>
>>>	https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>
>>>
>>>	_______________________________________________
>>>	IPsec mailing list
>>>	[email-masked]
>>>	https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>	Scanned by Check Point Total Security Gateway.
>>>
>>>	_______________________________________________
>>>	IPsec mailing list
>>>	[email-masked]
>>>	https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>
>>>
>>>
>>>
>>>	Scanned by Check Point Total Security Gateway.
>>>
>>>
>>>_______________________________________________
>>>IPsec mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>

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