Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-08.txt

From: [email-masked]
Date: Fri, 27 Dec 2019 10:54:18 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

        Title           : Using EAP-TLS with TLS 1.3
        Authors         : John Preuß Mattsson
                          Mohit Sethi
	Filename        : draft-ietf-emu-eap-tls13-08.txt
	Pages           : 29
	Date            : 2019-12-27

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 further improves security and privacy by mandating use
   of privacy and revocation checking.  This document updates RFC 5216.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-08
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alan DeKok <[email-masked]>
Date: Sat, 28 Dec 2019 08:29:40 -0500

> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08

  Which adds some text about identities:

           It is RECOMMENDED to use anonymous NAIs with the same realm in the	
 	   resumption and the original full authentication.  This requirement	
 	   allows EAP packets to be routable to the same destination as the	
 	   original full authentication.

  That's good, thanks.  I still would prefer some additional text as I had suggested.  The text explains related issues in more detail:

The alternative is to derive the EAP Identity from the identity used
inside of TLS. This derivation is common practice when using
certificates, and works because the "common name" field in the
certificate is typically compatible with EAP, and it contains a
routable identifier such as an email address. This practice cannot be
used for resumption, as the PSK identity may be a binary blob, and it
might not contain a routable realm as suggested by RFC 7542.

In some cases, the PSK identity is derived by the underlying TLS
implementation, and cannot be controlled by the EAP
authenticator. These limitations make the PSK identity unsuitable for
use as the EAP Identity.

  I find it's easier for people to follow recommendations when they have a full picture of the pros and cons of the choices being recommended.

  For the original authentication:

           Anonymous NAIs MAY be derived from	
 	   the client certificate used in TLS.  Client certificates typically	
 	   contains an identity with a routable domain such as an email address.

  How is this derivation done?   Many things "may" be done, but that doesn't help guide *why* or *how* things are done.

  If there's no clear guidance possible, then that should be said, too.

  I also believe that the document should also RECOMMEND that the EAP-Response/Identity be in the form of an anonymous NAI.

  I would prefer to have a separate section about identities. I find the current text a bit unclear. It helps to explain why an anonymized NAI is useful, even when there is no email address in a certificate.

  Alan DeKok.