Subject: [Emu] Alissa Cooper's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 19:20:03 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-emu-rfc5448bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Why isn't this document on the standards track? I understand that it updates
and obsoletes informational documents and I'm assuming there are historical
3GPP-related reasons why those documents were informational, but couldn't that
be fixed in this update? This certainly seems like it is specifying normative
behavior.

== Section 5.3.2 ==

"Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is
   configured to use."

It may be that I'm missing context, but 5.3.1.1 says "A SUPI is either an IMSI
or a Network Access Identifier," which makes me wonder what it means to employ
a SUPI that is neither an IMSI nor an NAI.

== Section  7.1 ==

"The use of the null scheme is NOT RECOMMENDED where identity privacy
   is important."

I think it might be better to say "The use of the null scheme is NOT
RECOMMENDED where the SUCI can be linked to a human user."

"The pseudonym usernames and fast re-authentication identities MUST
      also not be used for other purposes (e.g. in other protocols)."

The normative language is not right. I think what you want is:

The pseudonym usernames and fast re-authentication identities MUST NOT be used
for other purposes (e.g. in other protocols).

s/will available/will be available/

It would be good to provide citation(s) for "tunneled EAP methods" since their
security  properties are not discussed here.