I would be very hesitant to mandate RFC 7924. Most EAP-TLS implementations use existing TLS libraries rather than implementing their own TLS stack. And many popular TLS libraries don't provide support for RFC 7924. Please look at : https://github.com/openssl/openssl/issues/5040 for example.
Using RFC 7924 even for dropped handshakes requires wider community review and should stay in draft-ms-emu-eaptlscert. We should try to keep the two drafts in sync but independent. For me, shipping draft-ietf-emu-eap-tls13 within a reasonable time (say within 6 months) is more critical. +1 on making OCSP stapling mandatory. --Mohit On 11/14/18 4:04 PM, John Mattsson wrote: > 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 <john.matts...@ericsson.com> > Date: Wednesday, 14 November 2018 at 13:50 > To: "emu@ietf.org" <emu@ietf.org> > 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: "internet-dra...@ietf.org" <internet-dra...@ietf.org> > Date: Wednesday, 14 November 2018 at 13:20 > To: Mohit Sethi <mo...@piuha.net>, John Mattsson <john.matts...@ericsson.com> > 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 > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
