Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-emu-rfc5448bis-06

[Jari Arkko <[e-mail]>]

Thanks for your review, Kyle!

Inline:

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

The 3GPP specifications are entirely public, but cumbersomely named and stored :-) Who would name specs with numbers?? :-) 

Google does help. When you google for nn.mmm you will get a specification page, and there you can click versions and on the version numbers you can click the actual document.

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

There’s some history to why this document is not on the standards track (see the AD review thread for more history).

> 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?

This has been clarified. See also our respond to the Gen-ART review from Dan. The document refers actually to both 4G and 5G specifications that contain, among other things, specifications for the relevant algorithms that EAP-AKA’ uses.

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

Yes. Clarified.

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

Yes, primarily 4G usage needs to be separated from 5G usage, and this has been specified in the 3GPP specifications as the note also suggests. But the text has been clarified in -07.

> 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?

The purpose is to detect if the locally indicated network name that the peer sees matches with the network name received in AT_KDF_INPUT. If they don’t match, an attacker, which may have got hold of the authentication vector, may be advertising a wrong network name and thereby luring the victim peer to connect to it. Basically, channel binding.

> 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?

This is described in 3.3. Basically the AKA algorithm uses the “shared key” stored in USIM and home environment to produce CK and IK. CK and IK are used to derive CK’ and IK’, which are then used to derive k_aut (and other keys indicated in 3.3).
 
But in short, the shared secret is only in the secure USIM and in the operator’s authentication server. It is not shared to any other nodes, for instance. There are some attacks on SIM card manufacturers for instance that may cause a leaks though of course, the remedy is similar to what we’d do for other protocols (such as PFS).

> 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?

Null-scheme encryption is an option in 3GPP specifications to give the decision power to the home environment 3GPP operator to use encryption or not. Such decision may be based on regulatory requirements.

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

Yes, perhaps. Text stricken out/shortened in -07.

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

We agree with point but don’t think this requires any change in the document.

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

You are correct of course that one could think of downgrade attacks in the other direction as well. That was not in RFC 5448 however, so it is difficult to put it into practice years after. In addition, we are concerned with deviating from 3GPP specifications. We do agree though that the other direction protection would be useful. Perhaps that’s something that could be addressed by a separate feature RFC, and clearly labeled as an extension. This would at least reduce the risk that someone objects to the entire new RFC based on the new functionality.
 
In any case, we added text about the lack of other direction protection in the security considerations text in -07.
 
> 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.

We agree that this is an interesting topic. I’m not sure there’s much we could say, as the ability to provide additional agility depends highly on what specific change is contemplated. Some changes might require a new method, others could be done as part of EAP-AKA’. We can only point to some examples, such as the PFS draft that seem to be able to make extensions.

Nevertheless, a small note was added to the -07 on this.

Thanks again for your review.

Jari