On Mar 9, 2019, at 6:50 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > I have been following along the discussion, and I think that I missed the use > case. > Why are we having this discussion?
It's good to understand the edge conditions of the protocol. Otherwise, it might have designed-in flaws. Or, implementations might be vulnerable to attacks which aren't discussed in the specification. > alan> i.e. a user starts with EAP-TLS, and then tries to "resume" his > alan> session, but this time uses TTLS. It's not clear that anything in the > alan> spec forbids or prevents this. > > What's in it for the user? s/user/attacker/ Answer: lots. Systems may have different policies for different EAP types. Being able to undetectably change EAP types seems bad. The issue is larger than just resumption with different EAP types. It's the whole set of information around the authentication. All of that data is unsecured, and can be forged. > Is this an attack? Yes. If the user changes the unauthenticated data associated with the EAP session (MAC address, switch port, etc), it may be possible to bypass poorly designed policies. e.g. changing the EAP-Request / Identity field. > Does it avoid an interaction with a human? > Does it enable mobility between different networks? > Does this avoid some interaction with a two-factor authenticator? It bypasses security policies. That seems bad. The other huge issue is how do we enforce policies with TLS resumption? The EAP-Request / Identity is insecure and can be forged. So that can't be relied on. Maybe the EAP server doesn't associate *any* policy data or authentication credentials with that TLS session. In that case, you can "resume", but we have no idea *who* is being "resumed", or what policies should be applied to that user. That seems like a rather enormous security issue. Since nothing in the protocol prevents people from playing games with it, attackers *will* play games, with unknown consequences. It therefore seems prudent to discuss these issues. Also to give guidance on the possible attacks. And, to give guidance on good practices. I think the issue of "resumption across EAP methods" is a minor one, but it has opened up a series of additional issues which need addressing. The previous EAP-TLS spec was written largely to describe EAP-TLS and nothing more. Realistically, EAP-TLS is almost always used inside of a larger ecosystem. It is therefore also prudent to discuss how these systems can interact, and what security issues may arise from this interactions. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
