Subject: Re: [IPsec] Question on RFC 5723 Session Resumption

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Sep 2020 10:33:27 -0400 (EDT)

On Mon, 31 Aug 2020, Michael Richardson wrote:

> Tero Kivinen <[email-masked]> wrote:
>    > 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.
>
> This is probably a rather bad thing.

> 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.

What we did for libreswan was to add a connection serial number and
place this in the encrypted ticket. So if the ticket is presented, the
connection serial is looked up. If it does not exist, the ticket is
invalid. Whenever the connection template is reloaded, meaning the
connection configuration could have changed, the serial number is
changed. This ensures that a reloaded connection on server invalidates
all issued tickets.

We are planning to use an encryption key that is generated every once in
while (prob 24h) and we will keep the last replaced key around for a
little while as well. We are still looking at the best working lifetimes
and how we will interact these with ike lifetime, ipsec lifetime and
re-authentication lifetime.

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

If you keep that around on the server in a dormant state, you will
quickly connect too many of these when you have thousands of clients
continuously reconnecting. And a lot of lookups to delete these old
IKE SA's when the client has started a new one without resumption. I
don't see a use case for this, provided an errata clarifies the liveness
triggered server deletes and the client suppresses deletes when it has
a ticket to resume and its state says it should remain up.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Sep 2020 18:22:07 +0300

Paul Wouters writes:
> On Mon, 31 Aug 2020, Tero Kivinen wrote:
> 
> > 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.
> 
> I agree, but that is not what the RFC says. Perhaps this would qualify
> for an Errata ?

Note, that when liveness check fails there is NO delete to be sent
over the IKE SA, thus IKE SA is not deleted, it was just deemed to
have failed. If any implementation sends Delete notification when
liveness check fails that is a bug...

RFC7296 says:

----------------------------------------------------------------------
2.1. Use of Retransmission Timers
...
   IKE is a reliable protocol: the initiator MUST retransmit a request
   until it either receives a corresponding response or deems the IKE SA
   to have failed.  In the latter case, the initiator discards all state
   associated with the IKE SA and any Child SAs that were negotiated
   using that IKE SA.
----------------------------------------------------------------------

I.e., there is no delete notification sent, and IKE sa is not deleted,
initiator just discards all state associated with IKE SA (and this
would be the SGW side doing and failing the liveness checks). If the
stateless resumption is used, then there is no state in SGW side
anyway to be stored, so when client comes back with resumption request
then server recreates the state.

RFC5723 explitly says that "In particular, when an IKE SA is deleted
by the client or the gateway, the client MUST delete its stored
ticket.", which would mean active delete operation, not just
destroying of state because of liveness failures.

Also 3 is quite clear that losing network connection and ike sa timing
out because of liveness tests does NOT invalidate ticket, as this is
expected case where ticket is used to reconnect. Same with suspending
laptop. 

> > 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
> 
> 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.

You use mobike if your IP-addresses changes, but IKE SA is still
active. You use resume if you were away so long that IKE SA state was
cleared out on the SGW.

> 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.

Modifying MOBIKE so that there is one new NO_ADDRESSES notification
which says there will not be any addresses for the client, not even
the one over which this message came in, and then server should simply
blackhole all communications for this client until it comes back and
gives some addresses (and of course disable liveness checks). If IKE
SA or Child SA expires or needs to be rekeyed then as packets are
blackholed, the SGW acts just like the operation timedout, i.e.
descards IKE SA state).

In that case when client comes back and tries to do mobike, it will
fail with INVALID_IKE_SPI as the SGW has descarded state for that IKE
SA, so client can do resumption to get IKE SA back.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Sep 2020 18:34:26 +0300

> This is probably a rather bad thing.

If server configuration is changed to require AES-GCM instead of 3DES
then I think all active tickets needs to be invalidated to make sure
they do not work. Easiest way is to change the ticket encrypting key.
Or if configuration is changed so that tunnels to 10.0.0.0/8 is no
longer allowed...

Global configuration changes are quite rare, and most implementations
I know do not bother checking whether existing IKE SAs match the new
policy or not, but simply delete all IKE SAs and recreates them.

Of course things that do not affect existing IKE SAs like adding new
users, or new networks etc are not really such global changes, and do
not require IKE SAs to be recreated.

Again if you want you can make your implementation so it matches the
policy and all existing IKE or Child SAs, and deletes only those IKE
or Child SAs which are against new policy, but that is quite
complicated thing to do, especially as you might not have stored all
information needed to match the policy (i.e., you might not have the
original certificate used to authenticate the specific IKE SA, so you
might not be able to match whether that has something that is no
required by new policy). 

>     > 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.
> 

Almost always there is some per user data anyways, most commonly the
password etc, and/or all kind policy information coming from the AAA
server...

I do not think people will configure remote users in such way, that
anybody with EE cert signed with that CA can log in... Almost always
they use EAP or similar and those have per user data.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Sep 2020 09:28:39 -0400 (EDT)

> they do not work. Easiest way is to change the ticket encrypting key.

Yes, this is why we (libreswan) add the conection serial created at
(re)load into the ticket. Even reloading the connection without a
change will invalidate all the issued tickets.

> policy or not, but simply delete all IKE SAs and recreates them.

for our implementation, global changes only take effect when reloading
the connection, so we are covered for this part.

> password etc, and/or all kind policy information coming from the AAA

I don't understand why user authentication needs to be "stored". If a
user changes a password, their current IKE SA is not invalidated. If
a user certificate revoked, the current IKE SA is not invalidated.
Those checks are only repeated at re-authentication time, and session
ticket lifetime's should only be allowed to upto the re-authentication
time before requirting a re-auth.

> they use EAP or similar and those have per user data.

I don't think this is relevant, provided session ticket lifetime's have
a max of issue time + re-auth time. You might even want to refuse the
ticket if it is within 1 rekey time of this maximum to prevent needing
a rekey before the normal rekey time.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Sep 2020 12:47:27 -0400 (EDT)

On Mon, 31 Aug 2020, Benjamin Kaduk wrote:

> 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.

So here is my first pass:

Abstract:

Current:

    A client can reconnect to a gateway from which it was disconnected.

New:

    A client can reconnect to a gateway from which it was disconnected,
    due to a network issue between the client and server.

Section 6.2:

Current:

    Each ticket is associated with a single IKE SA.  In particular, when
    an IKE SA is deleted by the client or the gateway, the client MUST
    delete its stored ticket.  Similarly, when credentials associated
    with the IKE SA are invalidated (e.g., when a user logs out), the
    ticket MUST be deleted.

New:

    Each ticket is associated with a single IKE SA.  In particular,
    when an IKE SA is deleted by administrative actions initiated by
    the client or due to the client receiving a Delete Notification from
    the gateway, the client MUST delete its stored ticket.  Similarly,
    when credentials associated with the IKE SA are invalidated (e.g.,
    when a user logs out), the ticket MUST be deleted. When the client
    deletes the IKE SA due to a failed liveness probe, the client MUST
    NOT send Delete Notifications and SHOULD keep the ticket to allow
    it to attempt a Session Resumption Exchange when the network outage
    has cleared.

Section 9.8:

Current:

    A misbehaving client could present a ticket in its possession to the
    gateway resulting in session resumption, even though the IKE SA
    associated with this ticket had previously been deleted. This is
    disallowed by Section 6.2.

New:

    A misbehaving client could present a ticket in its possession to
    the gateway resulting in session resumption, even though the IKE
    SA associated with this ticket had been terminated by the client
    or server during regular operations that included processing Delete
    Notifications. This is disallowed by Section 6.2. Note that during an
    outage, deletion of the IKE SA that is the result of failed liveness
    probes MUST NOT invalidate the ticket for resumption, as this behaviour
    is expected to occur during a network outage. Invalidating the ticket
    due to a liveness failure would make session resumption impossible.

I am confused a bit about 4.3.1:

Current:

 	a client MUST NOT reuse a ticket.  A reused ticket SHOULD be rejected by a gateway.

Why is there a SHOULD and not a MUST NOT ? With the SHOULD I guess I can
now ignore it (as we do in our implementation currently). We could
clarify here that the timing interactions of ike lifetime, re-auth
lifetime and ticket lifetime should prevent it from being used after
the user credentials have expired, but I don't think it is really needed
in the errata?

This one is also a little tricky:

      Note 3:  If the certificate has an iPAddress SubjectAltName, and the
             implementation requires it to match the peer's source IP
             address, the same check needs to be performed on session
             resumption and the required information saved locally or in
             the ticket.

We need to update our implementation to add this ip restriction into the
session ticket so we can compare it on resume without having the CERT.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 3 Sep 2020 10:49:31 +0300

Hi Paul,

>     due to a network issue between the client and server.

I don't like this change - it's too narrow and only talks about network issue. 
The disconnection can also be a result switching off power on a CPE,
or rebooting the device.

>     when a user logs out), the ticket MUST be deleted. 
>     When the client  deletes the IKE SA due to a failed liveness probe, the client

The following text:

>     MUST NOT send Delete Notifications and 

is unnecessary and technically incorrect, because if there is no connectivity
(as turned out after liveness probe failed), the client _cannot_ send any message to the server.
Please, remove it.

>     SHOULD keep the ticket to allow
>     is expected to occur during a network outage. 

Again, the network outage is not the only reason for deleting SAs - 
switching off power or rebooting the device can also occur.

>      Invalidating the ticket

I think this clarification is not necessary. 

> the user credentials have expired, but I don't think it is really needed

I guess that it's SHOULD, because if it were MUST, a stateless server implementation
would not be possible, even with ticket by value.

Regards,
Valery.

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Sep 2020 10:15:28 -0400 (EDT)

> The disconnection can also be a result switching off power on a CPE,

You are right.

> (as turned out after liveness probe failed), the client _cannot_ send any message to the server.

There are cases where the client thinks it can send them, but it should
not. Eg if it connected to a wifi AP that has no more uplink. If it
sends the delete, and the connection would briefly allow packet flow,
then the server would delete the state and invalidate any tickets. So
I think it is important to clarify. And "cannot" is just a subset of
"MUST NOT".

> switching off power or rebooting the device can also occur.

How about:

s/outage/interruption of service/      or: (planned or unplanned) interruption of service
s/during a network outage/in some situations, such as a network outage/

> I think this clarification is not necessary.

I think this discussion on the list shows that it is neccessary?

> would not be possible, even with ticket by value.

But that is a cop out. It should have explained in which cases it should
not be rejected. If this section had clarified the liveness probe
failure case, we would not be having any of this discussion and everyone
would have implemented it properly :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 3 Sep 2020 23:22:35 +0300

Hi Paul,

> >>     Each ticket is associated with a single IKE SA.  In particular,
when
> >>     When the client  deletes the IKE SA due to a failed liveness probe,
the
> client
> > (as turned out after liveness probe failed), the client _cannot_ send
any
> message to the server.

I fail to understand this. RFC7296 is very clear, that if exchange is timed
out,
IKE SA is silently deleted (Section 2.1):

Note, that RFC7296 doesn't say that you may/should/must send a
Delete payload in this case, it says that IKE SA state is discarded.
You cannot send DELETE notification over discarded SA.

And I disagree that "cannot" is just a subset of "MUST NOT".
"MUST NOT" means that you are able to do this, but it is forbidden.
You don't say: "you MUST NOT use TCP/UDP port number greater than 65535"
or "you MUST NOT exceed speed of light".

> >>     A misbehaving client could present a ticket in its possession to
the
> s/during a network outage/in some situations, such as a network outage/

Works for me.

> I think this discussion on the list shows that it is neccessary?

No, it is not necessary. You put all the requirements not to invalidate
ticket in this case in the preceding text. This sentence adds no additional
requirements, it just explains why these requirements are imposed.
You may leave it, but I don't think it's necessary...

Regards,
Valery.

> >>  	a client MUST NOT reuse a ticket.  A reused ticket SHOULD be
rejected
> by a gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Sep 2020 03:03:04 +0300

By first look the changes seemed way too big for errata, but it seems
they are getting narrowed down to something that could be actually
done by errata.

If we want to do something bigger we can of course do 5723bis and do
other things at the same time if needed.

> I think it is important to clarify. And "cannot" is just a subset of

This of course would require you to implement and use the window size
larger than one. If you use the default size of one, your one slot is
already in use by the liveness check, and you can't send the next
message until that is finished, and it will not be finished as network
is broken...

If your implementation actually uses window size larger than one, then
it could waste its resources and send the delete using next message
id, but I do not see any point in that. Why would any implementation
do that? If they are tearing down the connection because other end is
dead, why do the want to send message telling the other end the
connection is now dead, if it does not reach it.

Yes, you could have one way connection, where the other end can
actually receive messages but you do not receive replies, but I do not
think there is point of implementing feature for just such networks. 
-- 
[email-masked]