Hi Alan, On 2/5/19 3:13 PM, Alan DeKok wrote: > On Feb 5, 2019, at 12:19 AM, Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: >> Do you have experience with such cross method resumption? Are there any >> deployments that make use of this? > There are no deployments that make use of it. It's worked in my testing. > >> My initial reaction is that such cross method session resumption should >> be forbidden. That is because EAP-TLS has different security properties >> where both the peer and server are mutually authenticated with TLS and >> certificates. Mixing it with other EAP methods that use TLS only for >> server authentication complicates the security properties and proofs. > I'm not sure how. > > Cross-method session resumption is essentially just changing byte 5 (type) > of the EAP conversation. Pretty much everything else remains the same. > > In the implementations I've seen, that really *is* the difference. No one > is going to implement TLS over EAP 5 times: once for EAP-TLS, then TTLS, > PEAP, TEAP, FAST, ... > > Instead, they use a common EAP layer, and a common TLS layer. Only once > the TLS session has been established is there any method-specific (i.e. > inner-tunnel) code run, and data exchanged. > > So it's not clear to me how doing session resumption with byte 5 == 0x0d > (EAP-TLS) is fine, but doing it with byte 5 == 0x15 (TTLS) is insecure. Indeed, TLS based EAP method implementations typically use a common underlying TLS implementation.
But session resumption is not simply about changing one byte in the EAP conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03 (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03), a server is issuing a NewSessionTicket only after receiving the TLS Finished from the client, at which point it has authenticated the client identity. What you are suggesting is that the server should issue a NewSessionTicket even before the client has been authenticated (which is the case for other TLS based EAP methods) and then only use that for resumption. This is significant difference. Also, client authentication with an easy-to-guess password inside a TLS tunnel is different than client authentication with a certificate. Which is why I stated the difference in security properties and proofs. I still maintain my initial position that such cross-method resumption should be forbidden. --Mohit > >> Also, EAP methods that only use TLS for the outer tunnel (TTLS, PEAP, >> etc.) typically begin with an anonymous NAI for privacy. What NAI would >> such peers use if they rely solely on TLS based resumption? > The answer here is one of two things: > > a) the authentication server caches user information bases on the TLS session > ID > > b) the authentication server encrypts user information, and sends it to the > client as part of the session ticket. > > Either method allows the authentication server to resume the session based > on the *real* NAI of the user. > > This has *always* been the problem with TLS-based session resumption. > > My concern here is that this practice has been implemented and widely > deployed for many years. The problem of (and solution for) the anonymous NAI > and TLS-based session resumption has been known for a long time. > >> As a co-author of draft-ietf-emu-eap-tls13, I don't think we should >> support such cross method resumption. If anything, this should be >> discouraged/forbidden. > I'm happy to do that, I'd just like to understand the reasons behind doing > it. > > Alan DeKok. > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
