Subject: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption

From: Terry Burton <[email-masked]>
Date: Mon, 10 Aug 2020 16:58:30 +0100

Hi,

Reading "Using EAP-TLS with TLS 1.3" I find the text potentially
misleading when it comes to resumption within TLS 1.3, specifically
for the case where the peer wishes to re-validate the certificate
originally provided by the server during the initial handshake using
only its locally cached data and without redoing the handshake, e.g.
to determine that the original certificate hasn't expired or been
revoked.

5.7.  Resumption
   ...
   To perform resumption in a secure way, the EAP-TLS peer and
   EAP-TLS server need to be able to securely retrieve authorization
   information such as certificate chains from the initial full
   handshake.
   ...
   There are two ways to retrieve the cached information from the
   original full handshake.
   ...
   The second method for retrieving cached information is
   via [RFC5077] or [RFC8446], where the TLS server encapsulates the
   information into a ticket and sends it to the client.  The client can
   subsequently do resumption using the obtained ticket.  Note that the
   client still needs to cache the information locally.

In TLS 1.3, the PSK ticket is defined as being encrypted using a key
that only the server knows. Even without encryption, the format for
the ticket is opaque to the client with only a suggested format
presented in RFC 8446.

How is the original handshake data determined? A casual reading of the
text seems to imply that the client performs some verification using
the encapsulated information within the ticket.

However I believe that the intent is to use the full PSK blob, or some
digest thereof, as a key to lookup the corresponding cached handshake
data.

Perhaps this could be made clearer?

Thanks,

Terry

---

From: Alan DeKok <[email-masked]>
Date: Mon, 10 Aug 2020 14:42:08 -0400

> to determine that the original certificate hasn't expired or been

  I suspect that the client needs to cache the server certificate, and associate it with the session ticket.  The certificate can then be re-validated on fast reconnect.

>   client still needs to cache the information locally.

  Hmm... yes, it should be nice to discuss *what* information is cached, and why it is cached, and what is done with it to re-validate it.

> the encapsulated information within the ticket.

  If so, that should be clarified.  The ticket is an opaque blob to the client.

> Perhaps this could be made clearer?

  I agree.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 11 Aug 2020 08:10:59 +0000

Hi Terry,

Section 5.7  "Resumption" says:

> When resumption occurs, it is based on cached information at the TLS
>    layer.  To perform resumption in a secure way, the EAP-TLS peer and
>    handshake.  We use the term "cached data" to describe such
>    information.  Authorization during resumption MUST be based on such
>    cached data.  The EAP peer and sever MAY perform fresh revocation
>    checks on the cached certificate data. 

This text indicates what needs to be cached and seems pretty clear to me.

The next question is how to lookup the cached information. This is what 
the text says currently:

>    original full handshake.  The first method is that the TLS server and
>    client cache the information locally.  The cached information is
>    identified by an identifier.  For TLS versions before 1.3, the
>    identifier can be the session ID, for TLS 1.3, the identifier is the
>    PSK identity.  The second method for retrieving cached information is
>    client still needs to cache the information locally.  The following
>    requirements apply to both methods.
The first mechanism is obvious, both sides store the information from 
the initial handshake and lookup using the Session ID or the PSK identity.

In the second mechanism, the server can avoid storing information. It 
instead puts that information in the PSK or the session ticket and sends 
it to the client. However, the client still needs to store information 
from the original handshake. This is why there is the sentence "Note 
that the client still needs to cache the information locally.". The 
client can't obviously read the contents of the ticket or the PSK.

Do you have some concrete suggestion on improving the text? We are happy 
to edit or receive pull requests on github: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13

Would this be better:

>    via [RFC5077] or [RFC8446], where the TLS server avoids storing
>    information locally and instead encapsulates the information into a
>    ticket or PSK and sends it to the client.  Note that the client still
>    needs to cache the information locally.  The client can subsequently
>    do resumption using the obtained ticket. 
--Mohit

On 8/10/20 6:58 PM, Terry Burton wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Terry Burton <[email-masked]>
Date: Tue, 11 Aug 2020 13:40:01 +0100

> This text indicates what needs to be cached and seems pretty clear to me.

Hi Mohit,

Agreed, that's clear.

Typo: "sever"

> the initial handshake and lookup using the Session ID or the PSK identity.

No disagreement here.

> client can't obviously read the contents of the ticket or the PSK.

I agree with the sentiment, but the current text seems a bit
"Sherlock": Once you've eliminated all other possibilities whatever
remains must be the case. I think it should directly state that the
client uses the opaque ticket or PSK as a key to identify the cached
information corresponding to the original session. Whereas the server
may use the decoded content of the ticket or PSK to achieve the goal
of remaining stateless.

Aside: The latter part might be obvious since shifting the burden of
storing the server-side state from the server to the client is the
whole point of ticket/PSK schemes. However it's not obvious to me that
the additional goal introduced by this RFC of performing a deep
revalidation of the authorisation data (resume-time certificate
checks, etc.) is shared with the RFC5077 or RFC8446 whose concern
appears to be with lightweight bootstrapping of the connection using
the original parameters. (Maybe I have missed something?) If that's
true then as Alan mentions, perhaps it is worth enumerating the types
of information that should be stored in the ticket to facilitate the
resume-time authorisation check rather than merely to reestablish the
crypto parameters required to perform an abbreviated handshake?

> >    do resumption using the obtained ticket.

IMO, that's better.

How about:

> The second method for retrieving cached information is via [RFC5077] or [RFC8446], where the TLS server avoids storing information locally and instead encapsulates the information into a ticket or PSK, which it encrypts using a key that only the server knows, and sends to the client. Note that the client still needs to cache the original handshake information locally and will use the opaque ticket or PSK to lookup this information during resumption, however the server is able to decrypt the ticket or PSK to obtain the original handshake information.

I think this emphasises that the ticket is opaque to the client yet
clear to the server, and that it is the blob itself that is used by
the client to lookup the information in its cache. This gives the
correct intuition for why the scheme works without needing to
understand the detail in the aforementioned RFCs to read between the
lines.

Terry

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Aug 2020 10:57:58 -0400

>>>   information such as certificate chains from the initial full

  Is there more information which needs to be cached?  If so, are there examples?

> may use the decoded content of the ticket or PSK to achieve the goal

  I agree.  It's a minor point, but clarifying it is helpful.

> crypto parameters required to perform an abbreviated handshake?

   Just re-checking 5.7, it should also have a discussion on expiring the cached data.  How long should it be cached for on each side?  I'd like to see some discussion.

  My $0.02 is that the cached data MUST expire no later than the expiry time of any certificate involved.  i.e. client, server, or any cert in the CA chain.

  Perhaps it would also be good to suggest that expiry times SHOULD be no longer than 48h?

  I also note:

   The above requirements also apply if the EAP server expects some
   system to perform accounting for the session.  Since accounting must
   be tied to an authenticated identity, and resumption does not supply
   such an identity, accounting is impossible without access to cached
   data.

  It would be good to add a sentence such as:

	Therefore systems which expect to perform accounting for the session SHOULD cache an identifier which can be used in subsequent accounting.

  In RADIUS, this would involve sending back User-Name or CUI in the Access-Accept.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 12 Aug 2020 06:17:12 +0000

Hi Alan and Terry,

Thank you again for the feedback. I have updated the text in github:
https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html#rfc.section.5.7

Here is the diff for your convenience:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

We'll submit the new version once we have sufficient implementation 
experience with the use of the close_notify alert.

--Mohit

---

From: Terry Burton <[email-masked]>
Date: Wed, 12 Aug 2020 14:15:29 +0100

> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

Thanks Mohit. I believe that update successfully addresses the issues
that I raised.