On Mon, 31 Aug 2020, Benjamin Kaduk wrote:
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 ?
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
