Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
draft-ietf-emu-aka-pfs-12

Thank you for the work on this document.

Many thanks to Sean Turner for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Aua-Uh5CRr9oDEIanfD6qw8WqVM/.

I only have two very minor comments.

Section 6.1: AT_PUB_ECDHE. The way Length is defined in RFC4187 (specifying the length of the attribute in multiple of 4 bytes), and given the length of the ECDHE public key in the attribute value (currently 32 or 33 bytes), you probably should mention something about padding. I expect something analogous to what RFC4187 defines for AT_IDENTITY "Because the length of the attribute must be a multiple of 4 bytes, the sender pads the identity with zero bytes when necessary."

Section 8: IANA Considerations. The section doesn't spell out the fields of the "EAP-AKA' AT_KDF_FS Key Derivation Function Values" registry (Value, Description, Reference), although those are pretty obvious from the table itself. What I think is really missing is the expert guidelines - as RFC8126 specifies, the policy "Specification required" still requires review and approval by a designated expert. "As with Expert Review, clear guidance to the designated expert should be provided when defining the registry". What criteria is the expert supposed to base their decision on when deciding if a new value should be registered?

Thanks for this work.  Thanks also to Sean Turner for the ARTART review.

And thanks for resolving the DISCUSS question around the document's status.  The rest of my original comment is left here for reference.

===

Section 7:

The use of "RECOMMENDED" in Section 7 is peculiar.  As prescriptive interoperability or security advice, to whom does it apply?

Section 8:

BCP 26 strongly urges that a Specification Required registry has advice for the Designated Experts, but this document contains none.  Is there nothing to say here?

Francesca's point also needs attention.

===

Additional comments from incoming ART AD, Orie Steele:

6.5.2

> The peer identifier SHALL comply
   with the privacy-friendly requirements of [RFC9190].

ought to be a MUST?

Section 7

   > As discussed earlier (see Section 1 and Section 4.3, forward secrecy
   is an important countermeasure against well-resourced adversaries
   that who may get access to the long-term keys, see Section 1.  Many
   of the attacks against these keys can be best dealt [mitigated] with improved
   processes, e.g., [restricting] limiting the access to the key material within the
   [a] factory or personnel, etc.  But not all attacks can be entirely ruled
   out for well-resourced adversaries, irrespective of what the
   technical algorithms and protection measures are.  And the likelihood
   of practically feasible attacks has increased.  To assume that a
   breach is inevitable or has likely already occurred [NSA-ZT], and to
   minimize impact when breaches occur [NIST-ZT] are essential zero
   trust principles.  One type of breach is key compromise or key
   exfiltration.

I'd recommend rewording much of this section.

7.1

Perhaps there is a better word than "forget", consider "destroy", possibly with a call out defense against forensic analysis.

Thank you to Carl Wallace for the SECDIR review.

** Section 1.  Editorial
   However, the danger of resourceful attackers attempting to gain
   information about long-term keys is still a concern because many
   people use the service and these keys are high-value targets.

What service?  Could this text be clearer?

** Section 1.  Editorial.
   While strong protection of manufacturing and other processes is
   essential in mitigating the risks, there is one question that we as
   protocol designers can ask.  Is there something that we can do to
   limit the consequences of attacks, should they occur?

I’m not sure what this paragraph adds.  Consider if it is really needed.

** Section 1.  Editorial.
   This document specifies an extension that helps defend against one
   aspect of pervasive surveillance.  This is important, given the large
   number of users such practices may affect.  It is also a stated goal
   of the IETF to ensure that we understand the surveillance concerns
   related to IETF protocols and take appropriate countermeasures
   [RFC7258].

This text largely repeats what was said in the paragraph before last (which also cited RFC7258).  Consider if it is really needed.

** Section 1.  
   While optional, the use of this extension is strongly
   recommended.

Is this something better left to 3GPP in their profiling of this work?

** Section 1.  Editorial

   Forward secrecy [DOW1992] is on the list of
   features for the next release of 3GPP (5G Phase 2)

-- “Forward Secrecy” has been used multiple times by this point in the text.  Why is the referenced introduced here instead on first use?

-- Can an informative reference be provided for “5G Phase 2”?

** Section 3.

   The use of this extension is at the discretion of the authenticating
   parties.

Wasn’t this more strongly worded in Section 1 (i.e., “While optional, the use of this extension is strongly recommended.”).  Does it needed to be repeated?

** Section 3.  Editorial.

   It should be noted that FS and defenses against passive
   attacks do not solve all problems, but they can provide a partial
   defense that increases the cost and risk associated with pervasive
   surveillance.

Hasn’t this already been said in Section 1 (i.e., “This prevents an attacker who has ...”)

** Section 6.4
   The term "support" here means that the group MUST be implemented and
   MUST be possible to use during a protocol run.

What is a “protocol run”?  Could it be turned off with configuration?

** Section 7.

It is RECOMMENDED that EAP-AKA methods without
   forward secrecy be phased out in the long term.

It is not clear what this means to implementers.  What is “long term”?

** Section 7.  Typo. s/comprimised/compromised/

** Section 7.  Editorial.  In the spirit of more precise and inclusive language, consider if the term “Man in the Middle” can be replaced with another term.

Thank you for this document, and also to Bo Wu for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-emu-aka-pfs-10-opsdir-lc-wu-2023-03-20/

I'll note that the document was updated 10 July 2023, after the OpsDir review (10 March 2023), but the (IMO) very reasonable suggestions were not taken:
"With only IETF technical background, it seems more readable if UICC, HSS can expand on the first-time use."

I hope / trust the the authors will consider and address these.

As usual, I wonder why an informational document uses BCP 14 normative language.

Hi,

Thanks for this document, just one relatively minor suggestion.  I suggest dropping the first paragraph of the abstract and just keep the second.  The first paragraph seems to be about justifying why this document exists which I think is much better placed in the introduction, or a background subsection of the introduction.  This shortens the abstract to just describing what the document is.

Regards,
Rob