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 On 8/11/20 5:57 PM, Alan DeKok wrote: > On Aug 11, 2020, at 8:40 AM, Terry Burton <terry.bur...@gmail.com> wrote: >> On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M <mohit.m.se...@ericsson.com> >> wrote: >>> 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. > Is there more information which needs to be cached? If so, are there > examples? > >>> 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. >> 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. > I agree. It's a minor point, but clarifying it is helpful. > >> 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? > 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. > > _______________________________________________ > 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
