Hi Alan, Thanks for your thorough review of version -16. Based on the suggested changes Joe made in GitHub issue #83, I have made commits to PR #83.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84 https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83 Below is a summary of the suggested changes to section 5 to address your comments: >From Alan's review of section 5 Section 5.1 says: [4] Cryptographic Negotiation: TLS 1.3 increases the number of cryptographic parameters that are negotiated in the handshake. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF hash algorithm, key exchange groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. Question: what does this mean in practice for EAP-TLS? i.e. this text describes a capability. It does not describe what that capability does, or how it benefits EAP-TLS. Joe: How about: "[4] Cryptographic Negotiation: The TLS layer handles the negotiation of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF hash algorithm, key exchange groups, and signature algorithm, see Section 4.1.1 of [RFC8446]." John: I made a commit based on Joe’s suggestion to shorten this down. Having this text is a requirement from RFC 3748 if I am correct. Section 5.2 says: No updates to section 5.2 of [RFC5216]. This isn't true. Section 2.2 has substantial new text with new requirements, and new security impacts. Joe: Add note that "Section 2.2 has additional discussion on identities." John: I added "Note that Section 2.2 has additional discussion on identities." Section 5.3 says: While certificates may have long validity periods, Comment: Certs issued by public CAs are generally short-lived, as in a year or so. It may be worth discussing this. Joe: It's not clear what to add here. John: Alan has a good point here. I suggest just deleting "While certificates may have long validity periods,". There is already text describing that certificates can have very short lifetimes. Section 5.4 says: Some deployments may permit no peer authentication for some or all connections. When peer authentication is not used, implementations MUST take care to limit network access appropriately for unauthenticated peers Q: Are these EAP server implementations? How does an EAP server limit network access for unauthenticated peers? Joe: This should be address by PR #83 modifications for section 5.6. John: Yes Section 5.7 says: There are a number of security issues related to resumption that are not described in [RFC5216]. The problems, guidelines, and requirements in this section therefore applies to all version of TLS. NIT: These requirements are for EAP-TLS, and not TLS. This document does not apply new security requirements to the TLS protocol Perhaps instead: There are a number of security issues related to resumption that are not described in [RFC5216]. The problems, guidelines, and requirements in this section therefore applies EAP-TLS when is used with any version of TLS. Joe: This comment should already be addressed by PR #83 or draft 16 text. John: Yes Section 5.7 says: If the EAP-TLS server or EAP client do not apply any authorization policies, NIT: EAP-TLS servers do not apply authorization policies. Perhaps explain that the EAP-TLS server is co-located with RADIUS / Diameter etc, and those apply policies. NIT2: It's not clear how an EAP client would apply authorization policies. Perhaps just remove the reference to the EAP client. Joe: Authorization should be discussed in the authorization section. Perhaps reword paragraph to: "The EAP-TLS server or EAP client MUST cache data during the initial full handshake sufficient to allow authorization decisions to be made during resumption. If cached data cannot be retrieved in a secure way, resumption MUST NOT be done." John: I made a commit based on Joes suggestion above. Cheers, John From: Joseph Salowey <[email protected]> Date: Friday, 18 June 2021 at 22:30 To: Alan DeKok <[email protected]> Cc: John Mattsson <[email protected]>, Bernard Aboba <[email protected]>, Mohit Sethi M <[email protected]>, EMU WG <[email protected]> Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok <[email protected]<mailto:[email protected]>> wrote: On Jun 17, 2021, at 12:04 PM, John Mattsson <[email protected]<mailto:[email protected]>> wrote: > I have made a single PR addressing all the currently listed issues in the way > suggested by Joe. > > https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files<https://protect2.fireeye.com/v1/url?k=8c954de0-d30e77f9-8c950d7b-8682aaa22bc0-57cef0b953c698ab&q=1&e=5f99d0b2-df4f-4e46-93ae-df1ccc285e5d&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fpull%2F83%2Ffiles> > > - Does PR #83 address the currently listed issues? I'll have to go through it and see. It's normally traditional to respond to reviews. And, to reply with proposed text for the document update. That process allows reviewers to quickly see if their issues have been addressed. The current use of GitHub makes this process rather more opaque. There are changes to the document pushed as commits, but it requires rooting through multiple commits and references in order to see which commit addresses which issue. The many commits of "updated document" make it more difficult to see what is changed, and why. [Joe] The github PRs make it easier to view the changes in the context of the document. I realize there may be a little bit of extra work to associate the changes to the issues, but this should be too difficult to do. > - Are there any other remaining issues that are not listed on GitHub? My review of a few days ago had extensive comments. It may be worth going through that and addressing each issue. Some of the items have been addressed, which is positive. However, it looks like all of my comments for Section 5 remain unaddressed. [Joe] I opened issue 84 (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84<https://protect2.fireeye.com/v1/url?k=27d05bf2-784b61eb-27d01b69-8682aaa22bc0-e47af421c50a8144&q=1&e=5f99d0b2-df4f-4e46-93ae-df1ccc285e5d&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fissues%2F84>) to track this. I think most of the section 5 issues have been addressed or can be addressed with simple changes. It's not clear what you wanted to address in section 5.3. Alan DeKok.
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
