Making it mandatory to use an anonymous NAI will be a huge issue in enterprise where the infrastructure, device and enterprise identity is owned by the enterprise. There is no proxy or third party provider.
Seeing "[email protected]" across all network infrastructure is not going to be acceptable. Why not provide a flag that can be passed in the EAP exchange from the supplicant that enables this behavior so users with full control of their device can use this while enterprise or other use cases that require real identity can configure the supplicant to provide a different flag? tim On 11/14/18, 7:50 AM, "Emu on behalf of John Mattsson" <[email protected] on behalf of [email protected]> wrote: 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 _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
