Subject: Re: [Emu] EAP-TLS 1.3 - TLS extensions and mechanisms

From: "Cappalli, Tim (Aruba Security)" <[email-masked]>
Date: Wed, 14 Nov 2018 14:13:52 +0000

I think mandatory support and use of stapling is a great idea. There have been so many changes across platforms the past few years w.r.t. status checks during an EAP exchange which has caused significant admin and end user headache. This solves that by making it consistent while adding the security value of revocation checks for the server identity.

Mandating support for the Cached Information Extension also seems like a good idea given the uptick of EAP-TLS usage and larger chains. I'd definitely be interested in hearing the TLS WGs opinion on this before being comfortable with mandating use.

tim

On 11/14/18, 9:04 AM, "Emu on behalf of John Mattsson" <[email-masked] on behalf of [email-masked]> 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 <[email-masked]>
    Date: Wednesday, 14 November 2018 at 13:50
    To: "[email-masked]" <[email-masked]>
    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-masked]" <[email-masked]>
    Date: Wednesday, 14 November 2018 at 13:20
    To: Mohit Sethi <[email-masked]>, John Mattsson <[email-masked]>
    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-masked]
    https://www.ietf.org/mailman/listinfo/emu