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 > EAP-TLS server need to be able to securely retrieve authorization > information such as certificate chains from the initial full > 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: > There are two ways to retrieve the cached information from the > 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 > 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. 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: > 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 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: > 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 > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
