Subject: [IPsec] Questions about RFC 5723

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Jul 2019 16:16:59 -0400 (EDT)

Hi,

I'm a little confused about some parts in RFC 5723

The first is about which SA's can be resumed. The introduction leaves
this ambiuous:

 	To re-establish security associations (SAs) upon a failure recovery
 	condition is time-consuming,

It does not say IKE SA or IPsec SA. And I have a feeling it depends a
bit on what you call "resumption".

It then talks about resuming the IKE SAs.... Reading more, it seems
IPsec SA's are not "resumed" but "created from scratch"?

I also see:

 	If a client temporarily loses network connectivity (and the IKE SA
 	times out through the liveness test facility, a.k.a. "dead peer
 	detection")

This is also a little confusing for IKE and IPsec states, because the
liveness test is for an IPsec SA, not an IKE SA. But it is send via an
IKE SA. That is, if an IPsec SA has no outgoing traffic, there would
never be a check using IKE for this. So it is kind of misusing the fact
that the IKE SA is used for liveness tests to check on the status of
the IKE SA.

In 4.3.4 I see:

 	Following the IKE_AUTH exchange, a new IKE SA is created by both
 	parties, see Section 5, and a Child SA is derived, per Section 2.17
 	of [RFC4306].

Which Child SA? If the peers had more then one IPsec SA, how does one
determine which IPsec SA to generate key material for first? Because
this paragraph does not talk about a new CREATE_CHILD_SA, it looks as if
the child sa derivation would not need another Exchange, but I can find
no information on how this would be done, unless we just pull KEYMAT
from the new SKEYSEED, but then child SA and ordering is completely
unspecified and this could only work when there is a single IPsec SA for
the IKE SA?

And this is the really confusing part in section 5:

 	IKE and IPsec State after Resumption

 	During the resumption process, both peers create IKE and IPsec state
 	for the resumed IKE SA.  Although the SA is only completed following
 	a successful IKE_AUTH exchange, many of its components are created
 	earlier, notably the SA's crypto material

So here too it says "create IKE and IPsec state". Which IPsec state
first? Then it talks about "the SA" and "the SA's" ?

My guess is that we first pull key material for the IKE SA, and then for
one of the IPsec SA's (perhaps this document assumes there is only 1
IPsec SA for any IKE SA that can be resumed?). Or based on Note 6:

 	Note 6:  Since information about Child SAs and configuration payloads
 		is not resumed, IKEv2 features related to Child SA
 		negotiation (such as IPCOMP_SUPPORTED,
 		ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec [ROHCoIPsec]
 		and configuration) aren't usually affected by session
 		resumption.

Perhaps what is meant is that a session resumption only resumed a
childless IKE SA, and now the initiator must do CREATE_CHILD_SA's for
each IPsec SA it wants to have again (not really "resumption", as these
are created "from scratch" like regular CREATE_CHILD_SA?

Also, when using PFS, these CREATE_CHILD_SA's would do a DH again, at
which point one wonders why to do resumption at all if you have more
than one IPsec SA, as you would be doing DH's anyway for all children,
you might as well do one more for a regular IKE_SA_INIT ?

So the essense of my question is: Am I correct that an IKE session
resumption only resumes the IKE SA, and that all IPsec SA's need to be
re-negotiated using CREATE_CHILD_SA ?

Secondary question: When using pfs=yes, what is the envisioned behaviour
of CREATE_CHILD_SA? Do a new DH? Or is it assumed that resumption would
be an incompatible policy with pfs=yes ?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 12 Jul 2019 10:34:57 +0300

Hi Paul,

speaking as someone who implemented the IKE resumption.

> bit on what you call "resumption".

Only IKE SA is meant.

> IPsec SA's are not "resumed" but "created from scratch"?

Yes.

> that the IKE SA is used for liveness tests to check on the status of

I believe the authors meant that liveness check was triggered by traffic over IPsec SA,
but resulted in timeout of IKE SA and thus deletion of IKE SA and all its children.

> unspecified and this could only work when there is a single IPsec SA for

A single (pair of ) IPsec SA is created as result of IKE_AUTH following
IKE_SA_RESUME, as if it follows IKE_SA_INIT instead of IKE_SA_RESUME.
If more IPsec SAs are needed they are created via CREATE_CHILD_SA,
as usual.

> first? Then it talks about "the SA" and "the SA's" ?

The IPsec SA you want to encrypt traffic with.

Usually you have an outgoing traffic that triggers IPsec SA creation.
If you don't have IKE SA at the moment, you create one with IKE_SA_INIT
and then create IPsec SA for the traffic in the IKE_AUTH. 

With IKE resumption the only difference is that the initiator
somehow determines that it has a ready to use ticket from the responder
and instead of initiating IKE_SA_INIT it initiates IKE_SESSION_RESUME.
The IPsec SA related stuff in the IKE_AUTH (traffic selectors, algorithms 
negotiation, cfg payload etc) is not affected by resumption.

> are created "from scratch" like regular CREATE_CHILD_SA?

No, one IPsec SA can be created in the IKE_AUTH (usually the IPsec SA
you are in immediate need to protect the outgoing traffic).
Other IPsec SAs can be later created via CREATE_CHILD_SA.

> you might as well do one more for a regular IKE_SA_INIT ?

In any case you save on authentication (this may involve signature
computing/verification and probably human intervention in case of EAP).

> re-negotiated using CREATE_CHILD_SA ?

You are correct that IKE session resumption only resumes IKE SA.
However, one IPsec SA can be created in the IKE_AUTH as part
of session resumption, the others must be created via CREATE_CHILD_SA.

> be an incompatible policy with pfs=yes ?

With resumption you essentially re-use DH from the old (already deleted)
IKE SA for the IPsec SA that is created during resumption in the IKE_AUTH.
If it is not appropriate, then resume IKE SA as childless and create
all IPsec SAs via CREATE_CHILD_SA with DH.

Regards,
Valery.

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Jul 2019 10:34:55 -0400 (EDT)

> If more IPsec SAs are needed they are created via CREATE_CHILD_SA,

Ahhhhh I totally missed this part when reading the document. Things make
a lot more sense now. Thanks!

> computing/verification and probably human intervention in case of EAP).

Indeed. Thanks for the clarifications!

I guess formally, we would need to add the previous IKE traffic counters
to the current one, since these are all derived from the same DH.

(yes, for FIPS we need to ensure there is not more than 2^20 or so AES
packets of IKE traffic, even though reaching that would be quite the
accomplishment)

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 12 Jul 2019 18:39:24 +0300

Paul, please don't hesitate to submit an editorial erratum if you think 
one is needed. If you don't "get" this RFC, it probably means something 
is missing.

Thanks,
	Yaron