Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Alan DeKok <[e-mail]>]

  After checking the draft again, Section 2.1.4 does have comments about anonymizing the NAI.  But those comments are limited to NAIs derived from certificates.

  I think that the text needs to be expanded to make the recommendations more genetic, and clearer.  I hope that my previous message clarified some of the issues here.

  I would like to see some discussion of these topics in the draft.  I don't think it's clear enough that the EAP Identity should always be "@realm", and there is no discussion on EAP Identity and resumption.

  I would suggest a new section called "Identities".  This section could go after 2.1.1, and incorporate some existing text from the Privacy section.  Suggested text follows.

Identities

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 solutions where the username is
encrypted MAY be used.

This recommendation applies to all uses of EAP-TLS, no matter the underlying TLS authentication mechanism.  This recommendation also applies when resumption is used.

The anonymous NAI can often be derived automatically.  When certificates are used, the certificate common name is often in the form of an email address.  The anonymous NAI can be derived from that address by using only the "@realm" portion.  This derivation has privacy implications, as discussed in the Privacy section, below.

In some cases, the anonymous NAI cannot be derived from the underlying TLS authentication mechanism.  For example, when PSKs are used, the PSK identity may be an opaque binary string.  Binary data is not compatible with the EAP Response / Identity field, as Section 5.1 of 3748 requires that the Identity field be composed solely of UTF-8 encoded ISO 10646 characters.  Instead, the Identity may be statically pre-provisioned.  Or for resumption, the Identity used for resumption SHOULD be the same as the Identity used for the original authentication.