Subject: [IPsec] Question on RFC 5723 Session Resumption

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Aug 2020 20:51:55 -0400 (EDT)

Hi,

We are working on implementing IKEv2 Session Resumption.
https://tools.ietf.org/html/rfc5723

We are only looking at ticket_by_value at this point.

It is unclear to me what is the behaviour related to Delete/Notify.
The RFC only takes into account situations where the connectivity is
lost and any delete/notify messages would no longer be received by
the responder. It states:

 	When the client wishes to recover from an interrupted session

But a client could use this mechanism when it wants to go to sleep and
tell the server this as well to avoid liveness probes. So the initiator
could send a delete, then come back later and use its ticket. This would
allow the responder to remove the state without waiting on liveness
timeouts to trigger cleanup of the vansihed client's state.

If the responder does not keep any state (which is the goal here) then it
would not know this session ticket belongs to an IKE SA that was deleted
by the initiator versus deleted by the responder's liveness/timeouts. The
RFC gives no guidance on this.

Similarly, if the responder keeps no state of the tickets it issued, it
would not be able to detect a ticket being used more than once without
the lifetime it set within the ticket itself.

When multiple gateways can read each others encrypted tickets, you could
also not prevent a ticket from being used more than once.

We are interested to know if any implementer bothered to track the issued
tickets and remove them from a list when received back (or timed out)

We are also interested to know if anyone prevents resuming a session
on the server side if the server has received delete/notifies for that
IKE SA.

Paul & Nupur

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 27 Aug 2020 10:46:58 +0300

Hi Paul and Nupur,

I would also be interested to know what people implemented, because what you're suggesting, while possibly "the right thing", is clearly counter to the RFC. Sec. 6.2 and Sec. 9.8 are rather clear that no matter who deleted the IKE SA, the ticket is revoked and must not be used, and in fact the gateway must keep some limited state to ensure it.

So if you want to stay compliant with the RFC, IMHO you'd need a new notification for this "delete".

The case of a cluster of gateways is not handled by the RFC. This is alluded to at the end of the Introduction.

Thanks,
	Yaron

On 8/27/20, 03:52, "IPsec on behalf of Paul Wouters" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Paul & Nupur

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Aug 2020 11:18:24 -0400 (EDT)

> I would also be interested to know what people implemented, because what you're suggesting, while possibly "the right thing", is clearly counter to the RFC. Sec. 6.2 and Sec. 9.8 are rather clear t…

You are right that section 6.2 is clear, but it does not take into
account the asynchronous nature of the client or server deleting
the IKE SA and the other peer not getting that notify.

So the phrase "no matter who deleted the IKE SA" is interesting. If a
client "vanishes", it is expected that the server would cleanup state.
Otherwise, the RFC would have just been about sending a notify to
"freeze DPD/liveness probes" and leaving state dormant on both sides.

It is inevitable that the server will either linger the state, or
delete it. If deleting it should be interpreted as "no longer suitable
for resume" than we are left with "lingering the state". At which
point I guess we can accomplish the same with only MOBIKE, and we
should move this RFC to Historic.

What I liked about resume is that the client can legitimately "vanish"
and cheaply restart without the server losing state or having to keep
all states around for too long. Eg with MOBIKE you run the risk of
the server removing state before the client re-surfaces and sends a
MOBIKE UPDATE message, and the client has to go from scratch with a
new DH. With resume, we avoid the DH and we can appear from a new
location. And the ticket expiry within the ticket ensures the server
won't start too old session tickets handed out.

> So if you want to stay compliant with the RFC, IMHO you'd need a new notification for this "delete".

Or update the RFC with a clarification that delete's are allowed, but
that the server who deleted a state, upon getting a ticket MUST check:

- It's configuration is unchanged from when the ticket was issued (we do that)
- The ticket's issue time plus the configuration's lifetime is not in
   the past
- The IKE SA should not have been rekeyed [tricky without keeping state]

> The case of a cluster of gateways is not handled by the RFC. This is alluded to at the end of the Introduction.

that was an unfortunate easy way to not address the problem of syncing
state between servers :)

Paul

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Aug 2020 14:54:47 -0400

> - The IKE SA should not have been rekeyed [tricky without keeping

If the ticket was issued at time A (which is in the ticket), and the IKE SA
rekey time is intervals of time B, then had the SA been active alive at time
A+B, it would have been rekeyed, right?
So, if the current time is > A+B, then the IKE SA should have been rekeyed?

But, you alude to it requiring state, so there must be something I don't understand.

    >> The case of a cluster of gateways is not handled by the RFC. This is
    >> alluded to at the end of the Introduction.

    > that was an unfortunate easy way to not address the problem of syncing

Can you explain what the problem is if the ticket is used more than once
(with different gateways) within the time B?

It seems that this is the only thing that would require state to be exchanged.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 28 Aug 2020 17:12:16 +0300

Hi Paul & Nupur,

> tickets and remove them from a list when received back (or timed out)

We don't (as for now). We implemented ticket_by_value, so server is stateless.
 
> on the server side if the server has received delete/notifies for that

We don't (as for now). We rely on client's honesty :-)
This is probably wrong and needs to be fixed...

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Aug 2020 12:07:39 -0400 (EDT)

> So, if the current time is > A+B, then the IKE SA should have been rekeyed?

Yes, so that part is not the problem.

> But, you alude to it requiring state, so there must be something I don't understand.

We added a suspend commend, but since that deleted states on the
initiator, it ended up sending delete's to the server. The server
deleted the IKE SAs. Now the client can resume a connection that
technically was ended by Delete.

This is similar to the client not sending deletes, and the server
triggering its own deletes based on liveness - the client isn't going to
respond to liveness probes while suspended.

If the client comes back with a valid ticket within the valid expiry
time, the server does not know if A) the IKE SA was already deleted
and the ticket theoretically should no longer be valid or B) the server
deleted the IKE SA due to liveness timeouts and the client comes back
with tickets to resume this.

> (with different gateways) within the time B?

So this indeed is the important question for all of these cases. What is
the harm? Because why does the RFC state that deleted IKE SAs should not
be resumed?

We are re-using an SK_d, but does that influence the amount of crypto
done under an IKE SA (FIPS issue)? The livetimes would already be
covered by the above - just don't let the ticket be valid for longer
than the creation time plus rekey time.

It would be really nice if we can keep the server side to need to
require zero state. If we ignore those two issues mentioned, we can
do that.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2020 16:42:18 -0400

> with tickets to resume this.

the server should behave the same way regardless of who deleted the SA.

    > the harm? Because why does the RFC state that deleted IKE SAs should not

I think that maybe the intention was that IKE SAs deleted by the server due to
operator action should never be resumed.   Because the user changed their
password, or their 2FA was compromised, or ...
Maybe the state-lite way is that the identity that involved in the deleted
state is marked as needing re-authentication.

    > require zero state. If we ignore those two issues mentioned, we can

I agree.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 29 Aug 2020 12:40:27 -0400 (EDT)

> It seems that either the client shouldn't send deletes, or:

But not sending a delete will just result in the server sending liveness
probes and deleting the client shortly after the client suspends
quietly. If you want IKE Resume to work in the real world with Liveness,
you basically have to ignore that the client and server delete the SA.

> the server should behave the same way regardless of who deleted the SA.

Then IKE Resume as an RFC can simply never work. No connection could
ever be resumed.

> password, or their 2FA was compromised, or ...

That is all covered by the lifetime of the session ticket. The ike
lifetime timeout (or rather, the re-authentication timeout) should be
set and honoured - whether the connection is active or suspended. So
as long as the server doesn't issue ticket lifetimes beyond the re-auth
lifetime - everything is good.

> state is marked as needing re-authentication.

That information is in the encrypted ticket by way of ticket lifetime.
No need for the server to keep state or state-lite.

>    > require zero state. If we ignore those two issues mentioned, we can

Another approach is to add a notify to MOBIKE to tell the server to
disable liveness probes, allowing the client to go to sleep without
fear or losing the state on the server. It can then also sleep for
some time and come back up with an MOBIKE update message. It wouldn't
allow the server to delete the state but it does allow the client to
go to extended periods of sleep without fear of not being able to
continue with the existing Sa.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 31 Aug 2020 05:10:45 +0300

> It seems that either the client shouldn't send deletes, or:

I think the original idea is that if the client or server send explict
delete, that is supposed to mean that IKE SA is deleted, and all
information about it should be deleted, including resumption. 

> the server should behave the same way regardless of who deleted the SA.

If the server deletes the IKE SA, because of liveness failure, that is
not explicit delete, i.e. not something that happened based on the
adminstrative action or similar, but instead it could be just
temporary failure in the network. So if the server deletes IKE SA
because of livenss check failures it should not mean that resumption
state or the IKE SA is permanently deleted. 

> state is marked as needing re-authentication.

This is what I think the RFC tries to say. I.e., if either end
explictly did adminstrative action to delete the IKE SA, then it
should not be possible to do resumption to it.

Of course if the user crendentials were compromised or
re-authentication is required that means that the configuration of the
server has changed for that user, and then ticket should be invalid
because the configuration is different.

Normally the ticket is encrypted with key that is changed every time
the server configuration changes, which means changing the server
configuration will invalidate all tickets. If this is not wanted for
change which only affects certain user, then ticket should contain
user identification number or similar, and the configuration serial
number for that user, and every time something changes in the user
configuration which requires revoking outstanding tickets, the
configuration serial number for that user is incremented. If client
tries to use ticket which has wrong configuration serial number for
user, then server will simply reject that ticket.

Anyways server or client should NOT invalidate tickets just because
it deleted the IKE SA because of liveness failures. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 31 Aug 2020 05:16:48 +0300

> you basically have to ignore that the client and server delete the SA.

That should not matter, the server should not invalidate tickets even
if there is liveness failures, as if it does that every time there is
transient network failure the resumption is useless. 

> continue with the existing Sa.

At one point I did propose an option for MOBIKE to send address update
without any addresses, i.e., saying that I will go to sleep so I will
not have any addresses you can use to connect to me, do not call me, I
will call you when I am back...

If I remember right people considered it too complex, and this was not
accepted even when it is described in the RFC4621 Section 5.4:

----------------------------------------------------------------------
5.4.  Zero Address Set Functionality

   One of the features that is potentially useful is for the peer to
   announce that it will now disconnect for some time, i.e., it will
   not be reachable at all. For instance, a laptop might go to suspend
   mode. In this case, it could send address notification with zero
   new addresses, which would mean that it will not have any valid
   addresses anymore. The responder would then acknowledge that
   notification and could then temporarily disable all SAs and
   therefore stop sending traffic. If any of the SAs get any packets,
   they are simply dropped. This could also include some kind of ACK
   spoofing to keep the TCP/IP sessions alive (or simply setting the
   TCP/IP keepalives and timeouts large enough not to cause problems),
   or it could simply be left to the applications, e.g., allow TCP/IP
   sessions to notice if the link is broken.

   The local policy could then indicate how long the peer should allow
   remote peers to remain disconnected.

   From a technical point of view, this would provide following two
   features:

   o There is no need to transmit IPsec data traffic. IPsec-protected
     data can be dropped, which saves bandwidth. This does not provide
     a functional benefit, i.e., nothing breaks if this feature is not
     provided.

   o MOBIKE signaling messages are also ignored. The IKE SA must not
     be deleted, and the suspend functionality (realized with the zero
     address set) may require the IKE SA to be tagged with a lifetime
     value since the IKE SA should not be kept alive for an undefined
     period of time. Note that IKEv2 does not require that the IKE SA
     has a lifetime associated with it. In order to prevent the IKE SA
     from being deleted, the dead-peer detection mechanism needs to be
     suspended as well.

   Due to its complexity and no clear requirement for it, it was
   decided that MOBIKE does not support this feature.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Sun, 30 Aug 2020 22:42:07 -0400 (EDT)

> transient network failure the resumption is useless.

I agree, but that is not what the RFC says. Perhaps this would qualify
for an Errata ?

> accepted

But it is possible, sort of. The client just sleeps and upon wake up
sends the UPDATE  without any addresses specified and the responder
will update to the address and port of the IKE header (after packet
was authenticated). But you are right in that with MOBIKE, we have no
way of saying "please suspend any liveness tests - I will be out of
the office".

I do think overall it would have been better to have 1 solution instead
of 2. But I think with supporting both, things can work the way we want.

For unexpected network outages we can switch interface using MOBIKE.
Like phone losing wifi briefly in the elevator. For expected downtime,
eg "phone is going to sleep mode" we can use RESUME to reconnect.

Resume does take two roundtrips over mobike taking one. So perhaps it
would still be nice to have the "out of office notify" to instruct
the server to disable liveness so MOBIKE can be used instead of RESUME.
However, that does take more resources on the server. But looking at
realy busy servers now - it is a stream of (re)connecting clients,
so I'll take any solution even if it needs state as it is less work
than all these new DH exchanges.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Aug 2020 13:34:45 -0400

Tero Kivinen <[email-masked]> wrote:
    > configuration will invalidate all tickets.

This is probably a rather bad thing.

    > If this is not wanted for

In many cases there is a single configuration "template" which applies to all
users who authenticate with a certificate from a certain CA, or with a login
matching some pattern.

In order to store the configuration serial number, on a per-user basis, then
some state is created a per-user basis.  This does not sound like a horrible
thing to me, but it is probably something new.

It seems that you see that deleting the CHILD (IPsec) SA on failure of a
liveness check is enough savings.  I don't know how universal this thought
process is.  Certainly, if one has limited hardware for IPsec slots, then it
conserves the expensive bit.

If one keeps the parent SA around, then one has some state in which to store
per-user data.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 31 Aug 2020 15:23:31 -0700

> I agree, but that is not what the RFC says. Perhaps this would qualify

I think an Errata Report would be appropriate for this topic.  Given that
we are still discussing the details, I suggest to iterate on the OLD/NEW
text on the list before actually submitting the report, though.

Thanks,

Ben