Hi Alan, On 2/5/19 5:48 PM, Alan DeKok wrote: > On Feb 5, 2019, at 10:18 AM, Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: >> 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. > Yes... > >> 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. > No, that's not what I'm saying. I'm not sure why there's confusion. > > I'm saying this: > > 1) user is authenticated via EAP-TLS as normal > > 2) user gets a session ticket for fast session resumption > > 3) user tries to resume the session using the session ticket. > > My questions here are about (3). > > a) Can the user resume via EAP-TLS? Clearly, yes. > > b) Can the user resume via TTLS? In practice, very likely, yes > > OK... so should we disallow (b)? If so, why? If not, why not? > >> 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. > That's true, but is only one part of the situation. > > What about doing an EAP-TLS session, and then resuming via TTLS? That is > a strong authentication with a certificate. How is that resumption > *quantitatively different* from resuming via EAP-TLS? Peer/Client authentication in stage 1 of EAP-TTLS is optional. So there is probably no difference if you do EAP-TLS first and then possibly use EAP-TTLS resumption. But the other way, EAP-TTLS/EAP-PEAP first and then EAP-TLS resumption is not the okay. That is because you can't know how and when the client was authenticated with EAP-TTLS/EAP-PEAP. > > In that situation, the difference *is* exactly octet 5 of the EAP packet. > So again, what *other* difference would forbid that kind of session > resumption? > > We also PEAP with inner MS-CHAP, versus TTLS with inner MS-CHAP. In that > case, both methods have similar data for inner authentication. So why forbid > cross-method session resumption? > > Or authenticating via TTLS with client certs, and resuming via EAP-TLS. > For that situation, they have similar security properties. > > In the end, if a site administrator says "I allow passwords and session > resumption", that should work. I still don't see any quantitative difference > when session resumption is done while changing octet 5 of the EAP packet. > Saying "security properties" when only octet 5 has changed isn't a convincing > argument. > > Maybe the answer here is "we have no idea what cross-method session > resumption means, and therefore we forbid it". > > That's a good answer. But if there are reasons for doing so, I wish to > understand those reasons. I think we are in agreement that there is not good reason to allow such cross method resumption and that this should be forbidden as such.
--Mohit > > Alan DeKok. > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
