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

From: Mohit Sethi M <[email-masked]>
Date: Tue, 7 Jan 2020 09:06:36 +0000

Hi Alan,

On 12/28/19 3:29 PM, Alan DeKok wrote:
> On Dec 27, 2019, at 1:54 PM,[email-masked]  wrote:
>> A diff from the previous version is available at:
>> 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.

Is there a case when the PSK identity is not derived by the underlying 
TLS implementation? And perhaps you meant to say that it cannot be 
controlled by the EAP peer (rather than the EAP authenticator)?

--Mohit

>    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.
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 7 Jan 2020 09:10:08 +0000

Hi Alan,

On 12/28/19 3:29 PM, Alan DeKok wrote:
> On Dec 27, 2019, at 1:54 PM, [email-masked] wrote:

The current text already says this in 2.1.7: "EAP-TLS peer and server 
implementations supporting TLS 1.3 or higher MUST support anonymous NAIs 
(Network Access Identifiers) (Section 2.4 in [RFC7542]) and a client 
supporting TLS 1.3 MUST NOT send its username in cleartext in the 
Identity Response. It is RECOMMENDED to use anonymous NAIs, but other 
privacy-friendly identities (e.g. encrypted usernames) MAY be used."

While identities MAY be derived from the certificate, they can also be 
configured by the user. As a co-author, I don't think we should 
over-prescribe only one way of doing it.

--Mohit

---

From: Alan DeKok <[email-masked]>
Date: Tue, 7 Jan 2020 08:04:15 -0500

> over-prescribe only one way of doing it.

  I believe that the recommendations should be stronger.  They should also include text explaining why the anonymous NAI is strongly recommended.

  The above text makes it sound like using opaque blobs for identities is not substantially different from using anonymous NAIs.  The reality is that anonymous NAIs are substantially better than opaque blobs.  e.g. Anonymous NAIs are routable, opaque blobs are not.

   Further, "encrypted usernames" MUST be encoded in UTF-8 as printable characters, otherwise they will not be compatible with RADIUS or Diameter.  If this document is going to suggest that encrypting identities is OK, then it must explain how to create inter-operable implementations.

  The reader should be informed as to the pros and cons of each use-case.  When the document says "you can do A or B", the reader has no idea *why* one would be chose over the other.  The reader has no idea *how* to make that choice.  Which means that implementors end up choosing the wrong thing,

  After going over the possible use-cases, I believe the anonymous NAIs should always be used.  The only situation where they're not necessary is where the authentication is known to be site-local.  i.e. the EAP supplicant and authenticator are both in the same network.

  In all other situations, there is no down-side to using anonymous NAIs, and there are major benefits to using them.

  Alan DeKok.