Subject: [IPsec] Ticket-by-reference and protecting the exchange

From: <[email-masked]>
Date: Tue, 18 Nov 2008 17:53:27 +0200

Tough chairs! Here's the answer I was going to say at the 
microphone:

The client does not (and cannot) know whether it's using
"ticket-by-value" (where the ticket contains the gateway's state, 
in encrypted form) or "ticket-by-reference" (where the ticket contains
only a pointer to state stored locally by the gateway), or even a
combination (some state is in the ticket, some is stored locally).

In *addition* to storing the ticket blob, the client has to store the
keys from the old IKE_SA (and this is done even if ticket-by-reference
is used -- since the client cannot know that). The client uses these 
keys to protect the resumption exchange. The gateway also needs these 
keys; it gets them from the ticket, or from its local storage (using 
the ticket as a pointer).

If the gateway is using ticket-by-reference, and there's a cluster of
multiple gateways, the cluster members need to communicate somehow
(and obviously this communication needs to be secured somehow).
This protocol is explicitly beyond the scope of the charter.

(BTW, if the gateway uses ticket-by-reference, things work 
pretty much the same way as draft-xu-ike-sa-sync, except that 
the terminology is slightly different, and this document doesn't
say anything about how multiple gateways communicate, possibly
via some database server, called "stub bank" in draft-xu-...).

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 18 Nov 2008 09:59:14 -0600

Thanks Pasi for the explanation.

On the other hand, can you point to the normative text in the draft
where it captures what you just said.
Also, the draft include the following text, just as an example:

"
4.2.1.  Protection of the IKE_SESSION_RESUME Exchange

   The key material is derived from the ticket, as follows:

        {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)

   where SK_d_old is the SK_d value of the original IKE SA, as retrieved
   from the ticket.  Ni guarantees freshness of the key material.  SK_d2
   is used later to derive the new IKE SA, see Section 4.5.
"

How does that fit with what you just mentioned?

Thanks!

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Tuesday, November 18, 2008 9:53 AM
> To: [email-masked]
> Subject: [IPsec] Ticket-by-reference and protecting the exchange
> 
> "ticket-by-value" (where the ticket contains the gateway's 
> state, in encrypted form) or "ticket-by-reference" (where the 
> ticket contains only a pointer to state stored locally by the 
> gateway), or even a combination (some state is in the ticket, 
> some is stored locally).
> 
> In *addition* to storing the ticket blob, the client has to 
> store the keys from the old IKE_SA (and this is done even if 
> ticket-by-reference is used -- since the client cannot know 
> that). The client uses these keys to protect the resumption 
> exchange. The gateway also needs these keys; it gets them 
> from the ticket, or from its local storage (using the ticket 
> as a pointer).
> 
> If the gateway is using ticket-by-reference, and there's a 
> cluster of multiple gateways, the cluster members need to 
> communicate somehow (and obviously this communication needs 
> to be secured somehow).
> the terminology is slightly different, and this document 
> doesn't say anything about how multiple gateways communicate, 
> possibly via some database server, called "stub bank" in 
> draft-xu-...).
> 
> Best regards,
> Pasi

---

From: <[email-masked]>
Date: Tue, 18 Nov 2008 18:09:13 +0200

Hi Ahmed,

Ah, now I see where the confusion comes from! 

The text should say something like "The key material is derived from
old SK_d as follows: [...]  The client has stored the old SK_d
together with the ticket itself.  The gateway obtains SK_d either 
from the ticket, or from locally stored state."

The draft doesn't actually say what the client has to store.
I guess the authors assumed it's obvious that the client stores
both the ticket, and it's own IKE_SA state (SK_d, algorithms,
etc.) -- but the draft should of course explicitly say that.

Best regards,
Pasi 

> From: ext Ahmad Muhanna [mailto:[email-masked]] 
> Sent: 18 November, 2008 17:59
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [IPsec] Ticket-by-reference and protecting the exchange
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 18 Nov 2008 08:26:08 -0800

Ok, I see the 'offending' text now: "where SK_d_old is the SK_d value of 
the original IKE SA, as retrieved
    from the ticket. "

That's true for the gateway (as clarified later in the draft); the 
client has that state without having to retrieve from the ticket. 
That's the entire premise.

cheers,
Lakshminath

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 18 Nov 2008 10:27:31 -0600

Hi Pasi,
Comments inline.

> The text should say something like "The key material is 
> derived from old SK_d as follows: [...]  The client has 
> stored the old SK_d together with the ticket itself.  The 
> gateway obtains SK_d either from the ticket, or from locally 
> stored state."
> 
> I guess the authors assumed it's obvious that the client 
> stores both the ticket, and it's own IKE_SA state (SK_d, algorithms,

[Ahmad]
Yes, the whole draft is written with "Ticket with Value" in mind. I
believe it needs to have both types in mind. IMO, the changes will be
considerable, although mainly clarification of how it works with "Ticket
by Reference". BUT, it will introduce new normative text on the client,
for example.

Because currently the draft allows the client to basically use session
resumption at any time. What does this mean to the client?

Where the client needs to save the IKE_SA state? In a non-volatile
memory? How the lifetime will be saved? etc.

Thanks again!

Best Regards,
Ahmad
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of [email-masked]
> > > "ticket-by-value" (where the ticket contains the 
> gateway's state, in 
> > > encrypted form) or "ticket-by-reference" (where the 
> ticket contains 
> > > In *addition* to storing the ticket blob, the client has to store 
> > > the keys from the old IKE_SA (and this is done even if 
> > > ticket-by-reference is used -- since the client cannot 
> know that). 
> > > The client uses these keys to protect the resumption 
> exchange. The 
> > > gateway also needs these keys; it gets them from the 
> ticket, or from 
> > > its local storage (using the ticket as a pointer).
> > > 
> > > If the gateway is using ticket-by-reference, and there's 
> a cluster 
> > > of multiple gateways, the cluster members need to communicate 
> > > somehow (and obviously this communication needs to be secured 
> > > somehow).
> > > (BTW, if the gateway uses ticket-by-reference, things work pretty 
> > > much the same way as draft-xu-ike-sa-sync, except that the 
> > > terminology is slightly different, and this document doesn't say 
> > > anything about how multiple gateways communicate, 
> possibly via some 
> > > database server, called "stub bank" in draft-xu-...).
> > > 
> > > Best regards,
> > > Pasi

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 18 Nov 2008 08:33:03 -0800

Actually, I am not so sure whether we need to write all that, if indeed 
the consensus is that we need to be agnostic.

How the client manages its IKEv2 and IPsec state is none of the IETF's 
business really.  As Tero pointed out, we made a mistake in saying stuff 
about lifetime.  The current plan is to delete the lifetime stuff to be 
consistent with 4306.

regards,
Lakshminath

---

From: <[email-masked]>
Date: Tue, 18 Nov 2008 18:33:45 +0200

Ahmad Muhanna wrote:

> believe it needs to have both types in mind. IMO, the changes will
> be considerable, although mainly clarification of how it works with
> "Ticket by Reference". BUT, it will introduce new normative text on
> the client, for example.
> 

I agree that more text and clarifications is needed, but I don't think
it's related to ticket-with-value vs. ticket-by-reference.

The client does not know whether the gateway is using
ticket-with-value or ticket-by-reference, so it behaves exactly 
the same way in both cases. For example, the client needs to save 
its own IKE_SA state in both cases.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 18 Nov 2008 18:37:46 +0200

Hmm... I think we probably need some text clarifying what the
client stores (the ticket and its own IKE_SA state) and advice
saying this shouldn't be stored forever, and such. But much of 
that text wouldn't be normative in nature.

Best regards,
Pasi 

> From: ext Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: 18 November, 2008 18:33
> To: Ahmad Muhanna
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange
> 
> Actually, I am not so sure whether we need to write all that, if
> indeed the consensus is that we need to be agnostic.
> 
> How the client manages its IKEv2 and IPsec state is none of the
> IETF's business really.  As Tero pointed out, we made a mistake in
> saying stuff about lifetime.  The current plan is to delete the
> lifetime stuff to be consistent with 4306.
> 
> regards,
> Lakshminath
> 
> >>>    from the ticket.  Ni guarantees freshness of the key 
> material.  
> >>> SK_d2

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 18 Nov 2008 10:41:27 -0600

> > considerable, although mainly clarification of how it works with 
> I agree that more text and clarifications is needed, but I 
> don't think it's related to ticket-with-value vs. ticket-by-reference.
> 
> ticket-with-value or ticket-by-reference, so it behaves 
> exactly the same way in both cases. For example, the client 
> needs to save its own IKE_SA state in both cases.
[Ahmad]
Agreed; I am using this to clarify my point:)
But seems that we are in agreement that at least the draft needs to be
clarified and most importantly be consistent throughout. I will share my
rest of the comments when I have a chance.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 19 Nov 2008 09:47:44 +0200

On Nov 18, 2008, at 6:26 PM, Lakshminath Dondeti wrote:

> Ok, I see the 'offending' text now: "where SK_d_old is the SK_d  
> value of the original IKE SA, as retrieved
>   from the ticket. "
>

I think it can be fixed by replacing "retrieved from the ticket" with  
"retrieved using the ticket" and making it refer only to the gateway  
side.