On Oct 21, 2020, at 5:00 AM, Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > the draft says it updates the earlier EAP-TLS version and claims that the > updates are related to > > * Section 5.6 Authorization > * Section 5.7 Resumption > > The content of Section 5.6 actually does not relate to EAP-TLS but is generic > to all EAP methods. I don't think it even belongs in an EAP method document.
The second paragraph is generic to all EAP methods. But it's explanatory, and doesn't offer specific security advice. The third paragraph is relevant to EAP-TLS, even if the first part true for all EAP methods. However, the second part refers to the PSK used for resumption, and is specific to EAP-TLS. As such, I believe that the text should stay. > The content of Section 5.7 claims that there are aspects of resumptions that > are not described in the earlier version of EAP-TLS. The focus is then on the > way how the cached data is stored, an implementation-specific aspect, that is > not specific to EAP-TLS because the concept of caching is used by other EAP > methods too. That's nice, but I don't recall any other document which discusses cached data with respect to EAP. Since we're updating EAP-TLS here, I think it's relevant. i.e. if we could refer to another document, that would be preferred. Since no other document exists, we need to discuss security considerations with respect to EAP-TLS. Even if the discussion is _also_ relevant to non-TLS EAP methods. > Then, there is a threat presented whereby the authorization information > changes between the full handshake and the resumption handshake. I believe > that this is not a threat that is unique to EAP-TLS because this can happen > even when there is no resumption. Yes. However, the identity used for authentication changes when doing resumption. This change means that authorization based on identities is more difficult than with "normal" authentication. As such, there are attacks unique to resumption which must be mitigated. Perhaps this point could be made more clear. i.e. instead of the focus being on cached data, the focus could be on changing identities, and how cached data can help detect and address that change. > Nothing prevents you from checking authorization again when you do resumption > though and even during an ongoing session. I would argue that there is a lot > of text in there that has nothing to do with EAP-TLS but rather concerns the > whole system in which EAP is used. If this is indeed a problem, I believe it > should be covered in a separate document. Given the time frame and the need to update EAP-TLS for TLS 1.3, I disagree. It is a problem, and it should be addressed here. > I don’t think it is a problem because extensions for RADIUS and Diameter have > been developed to address this issue to revoke authorization during the > lifetime of a session. This document should give guidance on how to implement EAP-TLS securely. RADIUS and Diameter don't help with issues such as the identity changing for resumption. > Here is where it gets confusing. The introduction says "This document defines > how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS > is used with older versions of TLS." To me, this does not sound like an > update. It doesn't not change earlier versions of EAP-TLS. But it gives new guidance. Perhaps this could be clearer. > At a minimum, I would clarify in the introduction what the updates to RFC > 5216 are. This will help those implementers that focus on a variant of > EAP-TLS that uses version 1.2. I agree. > As mentioned above, I don't believe Sections 5.6 and 5.7 belong to this > document. Leave it in there if someone in the group gets paid by the number > of published pages. Or if the authors wish to give practical, timely, advice to implementors of EAP-TLS. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
