Subject: [Emu] FW: New Version Notification for draft-mattsson-eap-tls13-01.txt

From: John Mattsson <[email-masked]>
Date: Tue, 9 Jan 2018 13:46:41 +0000

Hi,

We have submitted an updated version of draft-mattsson-eap-tls13. The new version is a significant update based on the feedback and comments on the EAP and EMU mailing lists. The new version also fills in all the sections that was TDB in the -00 version.

- The draft now updates version updates RFC5216 (instead of obsoleting) and all text have been updated to make sure that the update stays compatible with all existing implementations of EAP-TLS.

- Added more text on what TLS 1.3 changes and why an update to RFC5216 is needed.

- As this is now an update, all duplicated text is removed, and the draft only describe the changes to message flow, messages, key derivation, privacy, etc. when TLS 1.3 is used. The new draft follows the structure of RFC5216 and lists updates (if any) to each section.

- Clearly stated that PSK authentication SHALL not be used (except for resumption).

- Due to the encrypted handshake in TLS 1.3 there is no longer any need for the EAP client to send and empty certificate list. A privacy section has been added that explains this.

- A key hierarchy section has been added specifying that when TLS 1.3 is used then Key_Material, IV, and Session-Id SHALL be derived from the exporter_master_secret using the TLS exporter interface.

Comments appreciated.

Cheers,
John
 
On 2018-01-09, 14:16, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-mattsson-eap-tls13-01.txt
    has been successfully submitted by John Mattsson and posted to the
    IETF repository.
    
    Name:		draft-mattsson-eap-tls13
    Revision:	01
    Title:		Using EAP-TLS with TLS 1.3
    Document date:	2018-01-08
    Group:		Individual Submission
    Pages:		15
    URL:            https://www.ietf.org/internet-drafts/draft-mattsson-eap-tls13-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-mattsson-eap-tls13/
    Htmlized:       https://tools.ietf.org/html/draft-mattsson-eap-tls13-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-eap-tls13-01
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-mattsson-eap-tls13-01
    
    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.

    
    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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Jan 2018 16:18:04 -0500

> We have submitted an updated version of draft-mattsson-eap-tls13. The new version is a significant update based on the feedback and comments on the EAP and EMU mailing lists. The new version also f…

  That looks a lot cleaner, thanks.

> - The draft now updates version updates RFC5216 (instead of obsoleting) and all text have been updated to make sure that the update stays compatible with all existing implementations of EAP-TLS

> - Added more text on what TLS 1.3 changes and why an update to RFC5216 is needed.

  Nit:

   This means that significant parts of
   the normative text in the previous EAP-TLS specification [RFC5216] no
   longer apply, and aspects such as privacy handling, resumption, and
   key derivation need to be handled differently.

  Instead of "no longer apply", I would say "are not applicable to EAP-TLS using TLS 1.3".  A simple "no longer applies" text could be interpreted as meaning it no longer applies to *any* variant of EAP-TLS.

> - As this is now an update, all duplicated text is removed, and the draft only describe the changes to message flow, messages, key derivation, privacy, etc. when TLS 1.3 is used. The new draft foll…

  Nit:

   The EAP server MUST authenticate with a certificate and SHOULD
   require the EAP peer to authenticate with a certificate.

  If the client certificate isn't provided, how is the client to be authenticated?  It may be better to say that the peer MUST authenticate itself initially with a certificate, and then MUST use a provisioned PSK for session resumption.  Only those two authentication methods are allowed.

> - Clearly stated that PSK authentication SHALL not be used (except for resumption).

  Why would PSK be forbidden?

  The TLS 1.3 spec clearly allows PSKs to be established out of band:

https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.2.2

  While RFC 5216 doesn't explicitly allow PSKs to be used, it doesn't forbid them or define how they're used.  The only other reference to EAP-TLS with PSK seems to be draft-otto-emu-eap-tls-psk-02.txt, from 2007.

  I guess my question here is how to allow PSK for session resumption, while forbidding the use of static keys everywhere else.

  Nit:

   ... If the client has received a NewSessionTicket
   message from the server, the client can use the PSK identity   

  "can" use the PSK identity?  What if it chooses to not use the PSK identity?

  I suspect it would be better to say that the EAP server MUST provide an identity and PSK for session resumption.  When doing session resumption, the EAP peer MUST use that identity and PSK.

  There's no benefit to the peer using a *different* identity.  The current phrasing "can use..." sounds philosophical instead of prescriptive.  It would be better to mandate the correct behaviour.

  Nit:

   A subsequent authentication using resumption, where both sides
   authenticate successfully is shown in Figure 3.

  It would be good to show a subsequent authentication using session resumption, where the server rejects the resumption, and requests that the EAP peer re-authenticate from scratch.

  It would also be good to note that if the session resumption is rejected, the EAP peer MUST discard the ticket, along with any associated identity and PSK. 

> - A key hierarchy section has been added specifying that when TLS 1.3 is used then Key_Material, IV, and Session-Id SHALL be derived from the exporter_master_secret using the TLS exporter interface.

  That's good.

  Alan DeKok.