ipsec November 2008 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumptio

Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00

From: Peny Yang <peng.yang.chn_at_nospam>
Date: Thu Nov 20 2008 - 15:36:12 GMT
To: "Tero Kivinen" <kivinen@iki.fi>


Hi, Tero:

Please check the lines:

On Wed, Nov 19, 2008 at 11:59 PM, Tero Kivinen <kivinen@iki.fi> wrote:
> Peny Yang writes:

>> Hey, Tero:
>>

> Then we disagree on this point, but I do not think it is productive to
> waste too much time for this point.

[Peny] Fine.

> True, I just wanted to point out that the current state machine is
> already quite complicated, and I would not like to make it any more
> complicated than it is now.

[Peny] Yeah. It's already complicated. But, some states need to be added, no matter we add new IKE_SESSION_RESUME or extend the IKE_SA_INIT. Do you have any good idea to avoid the modification of IKEv2 state machine?

> Not true, as IKE_SA_INIT does not have any protection as such, the
> contents of it is protected by the AUTH payload in IKE_AUTH exchange.
> There is no encrypted part in that, and in normally does not even have
> crypto context at that point. Adding encrypted SK {} part is designing
> new way to protect the mssages.

[Peny] You are right. In my opinion, the SK{} part is not necessary to present the ticket.

> I didn't really assume either one of those, as it does not matter.
> With ticket-by-reference the ticket would be so small that putting it
> to IKE_SA_INIT, but for ticket-by-value the actual ticket might be
> quite large.

[Peny] Thanks. You agree with us.

> Because DH is much more expensive than round trip, and in most common
> case there would not be extra round trip at all, as ticket is
> accepted.

[Peny] Firstly, I do not agree that DH is ALWAYS much more expensive than round trip. In some circumstances, such as in the wireless network with limited uplink, a round trip may be longer.

> Both. It does not matter whether ticket-by-reference or
> ticket-by-value is used, if the resumption is done part of IKE_SA_INIT
> the client MUST do Diffie-Hellman setup and generate the KEi payload
> which is part of the same message, just in case.
[Peny] I don't think it's a MUST to redo DH on client for session resumption. For regular IKEv2 session setup, the DH need to be done every time. For Session resumption, the KEi can be reused.

> KEi cannot be retrieved, as it is not present in client anymore, and
> you do NOT want to reuse the exponential that was used few hours ago
> when the original IKE SA was created. The KEi would need to be new and
> client would need to do the calculation. The KEi in the IKE_SA_INIT
> does not have anything to do with the old IKE SA, it might even be
> over different Diffie-Hellman group.

[Peny] For session resumption, it will not be over different DH group.

> You do assume that crypto library allows exponent reuse.
[Peny] Yes, I do assume reusing KEi on client.

> Some crypto libraries do not allow that, they will erase all information
> about the
> Diffie-Hellman pieces when the Diffie-Hellman calculation is finished.
> Actually security considerations section of RFC 4306 does assume that:
> It is assumed that all Diffie-Hellman exponents are erased from
> memory after use. In particular, these exponents MUST NOT be derived
> from long-lived secrets like the seed to a pseudo-random generator
> that is not erased after use.

[Peny] Well, basically, I agree that DH exponentiations will not be used for a long time according to RFC4306. However, I don't think RFC 4306 assumes to erase the DH exponentiations after the CALCULATION is finished. It just said the DH exponent is assumed to be erased after USE. If we need to USE it in the session resumption, I think RFC4306 does not oppose us from using it before the renewing of DH exponent. And, RFC4306 does not set the limit on reusing the DH exponentiations, as well. The extension of IKE_SA_INIT just uses the renewed DH exponent once during the session resumption. And in session resumption, it will not fall into different DH exchange group of previous DH exchange. Personally, I don't encourage using DH exponents for a long time. But, it's worthy to re-using it for the infrequent session resumption.



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec