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./