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. > 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
