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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
