Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Informational documents like this are in large part useful as documentation of existing practices, irrespective of the merit of the described technology. I consequently review such drafts primarily for clarity, completeness, and conformance to IETF document standards, while providing guidance that might be helpful for future revisions of the technology. >From the perspective of clarity and completeness, this document is Ready With Nits: it is well-written and mostly quite clear, even to someone without a great deal of knowledge of 3GPP systems. In addition to digging into RFCs 4187 and 5448, I had to follow a few search engine links to (maybe not public?) 3GPP documents for some details, but this was not a terribly high burden. With regard to IETF document standards, the thing that sticks out is the use of normative language in an informational document. (FWIW, RFC 5448 also has this, and is also informational.) Minor comments and questions: Section 1 has a note starting with "This specification refers only to the 5G specifications..." I am not quite sure what this note is intended to imply. Is "this specification" the draft itself, and therefore that it should be used only for 5G deployments, and that 5448 should continue to be followed for older access technologies? Section 3.1 states that "The value of the AT_KDF_INPUT attribute from the server MUST be non-empty." I presume this means that the Network Name must be non-empty, i.e., that "Actual Network Name Length" must be non-zero. Following the previous paragraph, the note in Section 3.1 states that However, from an EAP-AKA' perspective both occupy the same field, and need to be distinguishable from each other. I am assuming this is to prevent collisions between two different network names that would enable some of the attacks that the AT_KDF_INPUT mechanism was intended to thwart. Also in section 3.1, the document talks about network name mismatches. What is the threat model here? Since the whole exchange is protected by the AT_MAC, it's not clear that there is any security benefit: the primary benefit appears to be to detect misconfigurations. Is that correct? Related to that point, my exploration of the AKA document space suggests that the scheme is based on keys shared between the user device (the USIM) and the "home environment", which I take to mean some system operated by the user's home carrier. I didn't dig deep enough to understand which systems have access to this shared secret: could you describe at a high level how the shared secret relates to CK, IK, and K_aut? Section 7.1 cautions implementors not to use null-scheme encryption to generate the SUCI, as privacy will then be lost. The obvious question is: why is it even mentioned in the draft (in section 5.3.2.1) and in 3GPP technical specifications? Is it for diagnostic purposes in lab environments and, if so, is it called out that way in the specs? Near the end of section 7.2 is a paragraph about the potential for traffic analysis, concluding: However, phone calls and SMS messages are just some of the many potential triggers for authentication. For instance, various mobility events and the amount of mobile data sent or received can also trigger authentication. As a result, while some amount of information may be derived about the activity level on a particular phone in some cases, the linkage to specific activities is not direct. I would not be so sanguine about the value of such noise to privacy: amplifying signal is one of the more straightforward parts of traffic analysis. This might best be filed under "if your adversary is the CIA or Mossad, you lose." I'd just lose this text entirely and merely state the risk. There are numerous minor grammatical errors throughout the doc that could benefit from an editorial pass prior to submitting to the RFC editor for publication. Future guidance: In section 3.3, the fast reauth derivation of MK is specified as: MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S) I do not think there is any actual problem here, given that K_re should be unique, meaning that unique parseability of the second argument to PRF' is not required to avoid collisions in the output MK; but unique parseability is generally a good idea. Section 4 states: there is no need to prevent bidding "down" attacks in the other direction, i.e., attackers forcing the endpoints to use EAP-AKA'. and in general throughout this section the draft refers to EAP-AKA' being "at least as secure" as EAP-AKA. I don't think this is the right way to frame downgrade attacks. Downgrade attacks (what you call "bidding down" here) are denoted as such by the value of a successful exploit to the attacker, not by a relation between some supposed fixed notions of algorithm strength that might change unexpectedly in the future. Downgrade prevention should designed to prevent any kind of influence on the negotiated protocol by an attacker without access to any relevant authentication credentials: essentially, it should make no assumption about the strength of either the new or old scheme, but simply provide assurance that the intended handshake was not tampered with. This is what TLS 1.3 does, for instance, through the inclusion of the full handshake transcript in the key derivation process. Re: section 7: What are the barriers to cryptographic agility, i.e., ciphersuite negotiation, in general? Stipulating the limitations of EAP, can this agility be implemented at a higher layer and used to select (e.g.) EAP-AKA'' sometime in the future? While being able to upgrade highly performant ciphers in deployed hardware is a challenging task and/or expensive prospect, it seems such agility is even more important for ecosystems that move slowly relative to software updates that can be deployed in days or weeks. I don't have a magic solution for this: I only wanted to bring it up as something that may be worth mentioning as an accepted risk.