Telechat Review of draft-ietf-emu-rfc5448bis-07
review-ietf-emu-rfc5448bis-07-iotdir-telechat-housley-2020-03-24-00

I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-emu-rfc5448bis-07
Reviewer: Russ Housley
Review Date: 2020-03-24
IETF LC End Date: 2020-01-29
IESG Telechat date: 2020-04-09


A review from the IoT Directorate was requested on 2020-03-23, which is
after the IETF Last Call ended.  I assume that the Internet ADs want
this review to help inform them during IESG Evaluation.

Note: I did not review the Appendices.


Summary: Ready with Issues


Major Concerns:

Section 5.2 says:

   The pseudonym usernames and fast re-authentication identities MUST be
   generated in a cryptographically secure way so that that it is
   computationally infeasible for an attacker to differentiate two
   identities belonging to the same user from two identities belonging
   to different users.  This can be achieved, for instance, by using
   random or pseudo-random identifiers such as random byte strings or
   ciphertexts.  See also [RFC4086] for guidance on random number
   generation.

It is not clear to me that a random number generator is needed to hide
the identities.  For example, a hash of a configured secret value and a
counter are probably good enough.  There are clearly other ways to do it
too, and some of them need a random number generator.  Because of the
way this is worded, it is not clear not me that my proposed solution
would meet the MUST statement.  I do not think we want to make this
harder than necessary.

Section 7 says:

      In general, it is expected that the current negotiation
      capabilities in EAP-AKA' are sufficient for some types of
      extensions and cryptographic agility, including adding Perfect
      Forward Secrecy ([I-D.ietf-emu-aka-pfs]) and perhaps others.  But
      as with how EAP-AKA' itself came about, some larger changes may
      require a new EAP method type.

I do not think it it appropriate to claim cryptographic agility when
SHA-256 and HMAC-SHA-256 are hardwired.  It would be better to say that
a new EAP method will be defined to change the algorithms (as was done
to make EAP-AKA' in the first place).


Minor Concerns:

Section 1 includes the summary of changes from RFC 5448.  However, it
does not mention the addition of Sections 3.5 and 4.1.  Please add them.

Section 3.1 says:

   Only the server sends the AT_KDF_INPUT attribute.  The value is sent
   as specified in [TS-3GPP.24.302] for both non-3GPP access networks
   for 5G access networks.  

There are some missing words here.  I am not really sure what is
intended, so I cannot offer a fix.

Section 5.3.1 says:

      Again, the identity MUST be used exactly as sent.

Please delete!  Saying it twice does not make it a stronger MUST.

Section 7.2: s/encrypt all payload traffic after encryption/
              /encrypt all payload traffic after authentication/


Nits:

Section 1: s/ non-goal of this draft/ non-goal of this memo/

There is a misalignment in the bottom box in Figure 1.  This is
surprising because the figure is otherwise identical to the one in
RFC 5448.

In Section 3.5: The introduction to the numbered columns is simply
"In addition:".  For clarity, I think it would be better to say
something like:

   The numbered columns indicate the quantity of the attribute
   within the message as follows:

Section 5.1: s/(see Section 5.3.2 and Section 5.3.2.1./
              /(see Section 5.3.2 and Section 5.3.2.1)./

Section 5.3: s/as defined in this RFC/as defined in Section 5.1/

I suggest the following structure for Section 5.3.1:

   5.3.1.   Key Derivation
   5.3.1.1  Format of the SUPI
   5.3.1.2  Format of the other identities

Section 6: s/Peer-Id is null string/Peer-Id is the null string/

Section 7.2: s/recommendations from Section 5.2 need to be
               followed to avoid this.
Section 7.2: s/following the recommendations in Section 5.2
               mitigate this concern./