On Feb 22, 2019, at 2:46 AM, John Mattsson <[email protected]> wrote: > > I think Section 2.2 of RFC 5216 do discuss this issue, but it does not > explicitly mention resumption. The text is also too soft.
I think that section discusses an entirely different issue, that has nothing to do with resumption. > Suggestion to add to Section 2.2 of EAP-TLS 1.3 > > "The identity presented in the EAP-Response/Identity is unauthenticated > information, and SHALL NOT be used for access control or accounting purposes. > Note that this also applies to resumption." This text means that resumption is impossible in all practical networks. Why? Because the user was originally authenticated via the credentials they provide: the certificate. As per Section 2.2, any policies applied to that user are applied based on those credentials. When resumption happens, those credentials are not supplied. The only ID provided is the EAP-Response/Identity, which systems are forbidden from trusting. So we now have resumption where we don't know the identity of who is resuming. We don't know what policies were applied to them previously. We don't know what policies to apply to them now. Therefore, any *practical* resumption is impossible. In my opinion, the document MUST give guidance for implementors and site administrators: * if resumption is used, the implementation MUST cache sufficient information for the system to make appropriate policy decisions on resumption * resumption MUST be rejected if no cached information is available, as we have no idea what policies to apply * the document MUST discuss the use of EAP-TLS in other protocols such as PPP, PANA, RADIUS, and Diameter. Just a mention that they exist is fine. * These protocols MAY carry additional information about the user and/or the machine involved. e.g. MAC, switch IP, port, etc. * When systems make policy decisions on that additional information, the systems MUST be aware that the additional information can be different between the original authentication and any resumption * This difference creates a "Time of check, time of use" (TOCTOU) security issue with the policies. i.e. The user can leverage the TOCTOU issue to get one policy applied for the original authentication, and a different policy applied for resumption. * That difference allows users to exploit the system, and get access that they should not have. * Implementations SHOULD add such information to the above cache for the session, so they can look for discrepancies between the original authentication and resumption * where there are discrepancies, the resumption SHOULD be rejected. I don't understand why there's so little concern about people being able to PWN your network. It's a disaster. We can't just paper over this issue. It's a major security flaw that's designed into the protocol. It needs to be addressed. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
