Hi all, I think the draft is now in quite good shape. It would be good to get some reviews. One thing that I would like to discuss is what the draft should say about various extensions and mechanisms. In particular:
- Revocation ------------------------------------------------------ RFC 5216 says: "EAP-TLS peer and server implementations MUST support the use of Certificate Revocation Lists (CRLs)" "EAP-TLS peer and server implementations SHOULD also support the Online Certificate Status Protocol (OCSP)" "EAP-TLS peers and servers SHOULD implement Certificate Status Request messages" draft-ietf-emu-eap-tls13-03 adds: "The use of Certificate Status Requests to determine the current status of the EAP server's certificate is RECOMMENDED." For EAP-TLS where the peer often does not have internet connection OCSP stapling is often by far the most appropriate mechanism. Is it time to make Certificate Status Requests (OCSP stapling) mandatory to implement for EAP-TLS with TLS 1.3? My view would be yes, OSCP stapling is solving a lot of issues with revocation, especially for EAP-TLS. I think OCSP stapling should be mandatory to support and maybe also mandatory to use... What is the working group's opinion about revocation mechanisms? - Fragmentation due to large certificates ------------------------------------------------------ draft-ietf-emu-eap-tls13-03 says: "EAP-TLS peers and servers SHOULD support and use the Cached Information Extension as specified in [RFC7924]." draft-ms-emu-eaptlscert-01 says: "The extension however necessitates a successful full handshake before any caching. This extension can be useful when, for example, when a successful authentication between an EAP peer and EAP server has occurred in the home network." As fragmentation of large certificates is a large problem in EAP-TLS deployments, would it make sense to mandate support and or use of RFC 7924 when TLS 1.3 is used? Also, in IETF 102 we discussed cached information and the possibility for the client to cache the server's certificate from a dropped handshake. I though more about this and I cannot see any cryptographic problems with the client caching the server's certificate from a dropped handshake. The client can verify the certificate anyway, but the server may not have time to prove possession of the private key before the handshake is dropped. Getting certificates out-of-band is common in many cases. The only problem I can see is that an attacker could try to fill the peer's memory storage by sending certificates to the client, but this does not give any amplification and could easily be mitigated by the client only caching a single or very few certificates. As fragmentation of large certificates is a large problem in EAP-TLS, my view would be that we should specify that the peer can cache certificates from a dropped handshake. With this change is it likely almost always possible to do EAP-TLS even if the authenticator drops the connection after 40-50 packages. If we decide to do this, we should tell the TLS working group that we are planning this and ask for their view. (Note that the whole Fragmentation section in draft-ietf-emu-eap-tls13 should be updated when draft-ms-emu-eaptlscert gets adopted by the WG). /John -----Original Message----- From: John Mattsson <[email protected]> Date: Wednesday, 14 November 2018 at 13:50 To: "[email protected]" <[email protected]> Subject: FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt Hi, We have updated the draft according to the discussion and conclusions at IETF 103. - New figure showing the message flow for EAP-TLS client rejection of NewSessionTicket - The draft did not mention that TLS has both warning and fatal alerts. We changed "TLS Alert Message" to " TLS Fatal Alert" and added a few sentences that describe the difference. "Figures 4, 5, 6, and 7 illustrate message flows in several cases where the EAP peer or EAP server sends a TLS fatal alert message. TLS warning alerts generally mean that the connection can continue normally and does not change the message flow. Note that the party receiving a TLS warning alert may choose to terminate the connection by sending a TLS fatal alert, which may add an extra round-trip, see [RFC8446]." - Made it mandatory to always conceal the username in the Identity Response. This led to smaller changes in several places. -- Text were updated to reflect this is mandatory -- Changed "Identity (MyID)" to "Identity (Anonymous NAI)" in all figures -- Removed the "privacy" figure as that is no longer needed. Instead the section refer to Figure 1. - Added "and all Post-Handshake messages have been sent" to page 3. The new sentence reads: "After the TLS handshake has completed and all Post-Handshake messages have been sent, the EAP server sends EAP-Success." - Several editorials. Cheers, John -----Original Message----- From: "[email protected]" <[email protected]> Date: Wednesday, 14 November 2018 at 13:20 To: Mohit Sethi <[email protected]>, John Mattsson <[email protected]> Subject: New Version Notification for draft-ietf-emu-eap-tls13-03.txt A new version of I-D, draft-ietf-emu-eap-tls13-03.txt has been successfully submitted by John Mattsson and posted to the IETF repository. Name: draft-ietf-emu-eap-tls13 Revision: 03 Title: Using EAP-TLS with TLS 1.3 Document date: 2018-11-14 Group: emu Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tls13-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ Htmlized: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-03 Abstract: This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP- TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 provides significantly improved protection against pervasive monitoring by mandating use of privacy. This document updates RFC 5216. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
