Hi Hannes, This text and guidance was specifically requested by working group members like Alan. Unless the text is wrong, I don't see any point in removing it. Other TLS-based EAP methods are obviously free to use parts of this text relevant to them. Note that their resumption and authorization might be even more complex as some decisions may depend on the inner authentication method.
--Mohit On 10/21/20 12:00 PM, Hannes Tschofenig wrote: Hi all, 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 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. 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. 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. 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. 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. Reading more carefully one can notice that the actual update to EAP-TLS is hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered Vulnerabilities". Section 5.8 says: " it is RECOMMENDED for EAP peers to not use EAP-TLS with TLS 1.2 and static RSA based cipher suites without privacy. This implies that an EAP peer SHOULD NOT continue the handshake if a TLS 1.2 EAP server responds to an empty certificate message with a TLS alert message. " Section 5.10 says: " EAP-TLS implementations SHOULD mitigate known attacks and follow the recommendations in [RFC7525] and [I-D.ietf-tls-oldversions-deprecate]. " Interestingly, RFC 7525 does not talk about EAP (and instead focuses on applications like HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the abstract). RFC 7525, for example, does not mandate OCSP. It also recommends RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to be contradiction here. 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. 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. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
