Hi Hannes, Thanks. I like the friendly banter. I could probably find the commit which says "SHOULD mitigate known attacks" and blame it on John. I will change it to MUST. :)
I have opened an issue to explain the relationship to RFC 7525: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/16. Please be rest assured that I don't get any money for publishing RFCs. Let alone any extra payment based on the number of pages. I did not write the code for session resumption but (together with my colleague) we have tested wpa_supplicant and freeRadius EAP-TLS resumption and it works. As said, Alan wanted the text. Here is one of the long discussion threads on this issue: https://mailarchive.ietf.org/arch/browse/emu/?q=Notes%20on%20session%20resumption%20with%20TLS-based%20EAP%20methods Let's wait and see what he has to say. We are happy to update once there is some consensus on how much of the text should stay. --Mohit On 11/2/20 11:37 AM, Hannes Tschofenig wrote: Hi Mohit, I have now read the email from Terry and he is not suggesting the original text. He is, in fact, correcting misleading text in your draft. IMHO the entire text in Section 5.7 reads a bit like you are giving implementation guidance. That would be great if John or you had written such code. I don’t know whether you have. You are given the reader the impression that there is a problem with session resumption. I don’t believe there is a problem and I gave you reasons in my email. On the second topic. Here is my remark about the wrong reference and my suggestion to address it: 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. If you want to reference RFC 7525 you should say what recommendation you want to carry over. If you don’t do that then the text should not be in contradiction of what is said in eap-tls13. Given your email with the dramatic title “Moving towards less security in 2020”, I am surprised that the reference to known attacks and the deprecation of old TLS versions receives a “SHOULD” rather than a “MUST”. Feels out of balance to me and this makes me believe that the update to RFC 5216 has not been given too much thoughts by the group and by the authors. My guess is that most implementers use the latest version of TLS 1.2 code already anyway, which comes with sensible defaults. Do you have a different experience? Ciao Hannes From: Mohit Sethi M <mohit.m.se...@ericsson.com><mailto:mohit.m.se...@ericsson.com> Sent: Monday, November 2, 2020 9:59 AM To: Hannes Tschofenig <hannes.tschofe...@arm.com><mailto:hannes.tschofe...@arm.com>; Mohit Sethi M <mohit.m.se...@ericsson.com><mailto:mohit.m.se...@ericsson.com>; emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216 Hi Hannes, As said, we added this text based on the request of working group members. There were comments and additions to this text by Terry Burton for example: https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption We are happy to update the draft with whatever the working group decides. About your comment "Most readers who focus on TLS 1.2 in EAP-TLS will never get to see those because they are hidden in the document.". I certainly hope that's not true because: this draft updates RFC 5216, and, the abstract says "This document also provides guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216." Could you also please clarify "You are referencing the wrong documents.". Thank you for being patient. :) --Mohit On 11/2/20 9:51 AM, Hannes Tschofenig wrote: Hi Mohit, I hope you understand that I am worried about three things in my email below: 1. You are putting text into an EAP method that applies to EAP itself. Nothing prevents the EMU group to work on a document that clarifies EAP usage in document that updates the EAP spec, if the described issue is important. 2. You are making changes to the use of TLS 1.2 in EAP-TLS in a document that focuses on TLS 1.3 use in EAP-TLS. Most readers who focus on TLS 1.2 in EAP-TLS will never get to see those because they are hidden in the document. 3. You are referencing the wrong documents. If you look at this case as a working group chair then you might see the points I am trying to get across. Ciao Hannes From: Mohit Sethi M <mohit.m.se...@ericsson.com><mailto:mohit.m.se...@ericsson.com> Sent: Saturday, October 31, 2020 6:06 PM To: Hannes Tschofenig <hannes.tschofe...@arm.com><mailto:hannes.tschofe...@arm.com>; emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216 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 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 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
