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

From: John Mattsson <[email-masked]>
Date: Mon, 9 Mar 2020 13:03:28 +0000

Hi Alan,

Thanks for you many good suggestions. I tried to address all your comments and include all your suggestions in a recent commit to github.

- I did not include an identity section as I did not see how it would fit with the structure of RFC 5216 that the draft reuses. Instead I expanded the identity sections in the resumption and privacy sections and added a new paragraph on identity in Section 2.1. This aligns well with RFC 5216.
- The text on encrypted usernames (like 3GPP SUCI) where updated to illustrate that they are intended to be NAIs, not opaque blobs.
- I added an explanation on how to derive a anonymous NAI from a NAI in the certificate subject name. I did not want to talk about common name as the certificate may contain a subjectAltName which is not common name (I think).

The new suggested paragraphs on identities are shown below. The resumption and privacy section only talks about details specific for resumption and privacy.

Cheers,
John

----------------------------------

2.1.  Overview of the EAP-TLS Conversation

   ...

   It is RECOMMENDED to use a NAIs in the Identity Response [RFC7542] as
   such identities are routable.  While opaque blobs are allowed by
   [RFC3748] such identities are NOT RECOMMENDED as they are not
   routable and should only be considered in local deployments where the
   EAP Peer, EAP authenticator, and EAP Server all belong to the same
   network.  An anonymous NAIs MAY be derived from the subject name in
   the TLS client certificate by removing the username from a NAI.  The
   subject name in client certificates typically contains an identity
   with a routable domain such as an email address.

2.1.6.  Resumption

   ...

   It is RECOMMENDED to use a 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.  The TLS PSK identity is typically derived be the TLS
   implementation and may be an opaque blob without a routable realm.
   The TLS PSK identity is therefore in general unsuitable for deriving
   a NAI to use in the Identity Response.

2.1.7.  Privacy

   ...

   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.  Following [RFC7542],
   it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but
   other constructions such as a fixed username (e.g. anonymous@realm)
   or an encrypted username (e.g.  YmVuZGVy@realm) are allowed.  Note
   that the NAI MUST be a UTF-8 string as defined by the grammar in
   Section 2.2 of [RFC7542].

----------------------------------

---

From: Alan DeKok <[email-masked]>
Date: Mon, 9 Mar 2020 10:28:20 -0400

> - I did not include an identity section as I did not see how it would fit with the structure of RFC 5216 that the draft reuses. Instead I expanded the identity sections in the resumption and privac…

  It's possible to update the document format.  When the RADEXT WG did RFC 7542 (NAI), the entire layout was re-done.

  My reasons for wanting a separate section on identities is that it's important, and many people get it wrong.  Calling it out in a separate section shows people that identities are important *independent* of resumption, protocol negotiation, certificates, etc

> - The text on encrypted usernames (like 3GPP SUCI) where updated to illustrate that they are intended to be NAIs, not opaque blobs.

  Thanks.

> - I added an explanation on how to derive a anonymous NAI from a NAI in the certificate subject name. I did not want to talk about common name as the certificate may contain a subjectAltName which…

  Sure.

>   the TLS client certificate by removing the username from a NAI.

  *which* NAI?  Perhaps:

When certificates use NAIs for the subject name, an anonymous NAI SHOULD be derived from the subject name
by removing the username portion.  

>  The

  The email address may not be routable.  Perhaps:

The subject name in client certificates typically contains an identity such as an email address, which is already in the NAI format.

>   authentication.

  What happens when this recommendation isn't followed?  Without explanation, such recommendations convey little information to the reader.

  i.e. if this recommendation is not followed, then in practice, resumption is likely to be impossible.

  And perhaps re-iterate "It is RECOMMENDED to use the same anonymous NAI in the resumption, as was used in the original full authentication"

>  The TLS PSK identity is typically derived be the TLS

  OK. 

>   Section 2.2 of [RFC7542].

  That looks good, thanks.

  Alan DeKok.

---

From: Russ Housley <[email-masked]>
Date: Mon, 9 Mar 2020 11:32:43 -0400

> On Mar 9, 2020, at 10:28 AM, Alan DeKok <[email-masked]> wrote:
> 
>> The

The email address is often in the SubjectAltName extension.  I know it is often part of the Subject, but it could be in either spot.

Russ