Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
On Wed, 12 Aug 2020 at 07:17, Mohit Sethi M wrote: > 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=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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
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=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 wrote: >> On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M >> 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
Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
On Aug 11, 2020, at 8:40 AM, Terry Burton wrote: > > On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M > 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
Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M 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. 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. Hi Mohit, Agreed, that's clear. Typo: "sever" > 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. No disagreement here. > 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. 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 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. 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
Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
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
Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
On Aug 10, 2020, at 11:58 AM, Terry Burton wrote: > 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. 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. > > 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. 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. > 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. If so, that should be clarified. The ticket is an opaque blob to the client. > 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? I agree. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
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
