Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
draft-ietf-emu-rfc5448bis-10

doc{draft-ietf-emu-rfc5448bis-07}

ballot{No Objection}

[nits]

S1

* "in 5G context" -> "in a 5G context", "in 5G contexts", "in the 5G context"

S3.1

* "for both non-3GPP access networks for 5G access networks" ->
  "for both non-3GPP access networks and 5G access networks"?

S5.3.2.1

* I assume 23.003 specifies which ECC to use and the encoding of both the
  ephemeral key and the encrypted version of the MSISN?

* Does this NAI risk tripping any length concerns?

S6

* Does the Session-Id for fast re-authentication also need to take into
  consideration the counter?  Please forgive my naivety.

The apostrophe in "EAP-AKA'" makes me think there’s a typo present every time I see it.

I primarily reviewed the diff between this document and RFC 5448.  Nothing stood out to me as needing particular discussion.  The thorough treatment on security, privacy, and vulnerability is appreciated.

Abstract:
* "memo" should really be "document".  (This was beaten into me by a previous AD, but I kind of agree with it.)

Section 5.1:
Nit:
* List item (1)(b) is missing a closing parenthesis.

Section 7.2:
Nit:
* "There has also been attacks …" -- s/has/have/

Section 7.3:
Nit:
* "Perfect Forwards Secrecy …" -- s/Forwards/Forward/

Oooof. I really dislike the apostrophe in EAP-AKA', but that's a grump at RFC 5448, not this document...

Thank you for this document.

Please respond to Russ' IOTDIR review: https://mailarchive.ietf.org/arch/msg/iot-directorate/vpbPLLBpdDnbL0A-bBLSEDyRA_M

Why isn't this document on the standards track? I understand that it updates and obsoletes informational documents and I'm assuming there are historical 3GPP-related reasons why those documents were informational, but couldn't that be fixed in this update? This certainly seems like it is specifying normative behavior.

== Section 5.3.2 ==

"Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is
   configured to use."

It may be that I'm missing context, but 5.3.1.1 says "A SUPI is either an IMSI or a Network Access Identifier," which makes me wonder what it means to employ a SUPI that is neither an IMSI nor an NAI.

== Section  7.1 ==

"The use of the null scheme is NOT RECOMMENDED where identity privacy
   is important."

I think it might be better to say "The use of the null scheme is NOT RECOMMENDED where the SUCI can be linked to a human user."

"The pseudonym usernames and fast re-authentication identities MUST
      also not be used for other purposes (e.g. in other protocols)."

The normative language is not right. I think what you want is:

The pseudonym usernames and fast re-authentication identities MUST NOT be used for other purposes (e.g. in other protocols).

s/will available/will be available/

It would be good to provide citation(s) for "tunneled EAP methods" since their security  properties are not discussed here.

I mostly only read the diff and skimmed the rest.

Section 1

   The rest of this specification is structured as follows.  Section 3
   defines the EAP-AKA' method.  Section 4 adds support to EAP-AKA to
   prevent bidding down attacks from EAP-AKA'.  Section 5 specifies
   requirements regarding the use of peer identities, including how EAP-
   AKA' identifiers are used in 5G context.  Section 6 specifies what

I'm not sure if it's "EAP-AKA' identifiers being used in 5G context" or
"5G identifiers being used in an EAP-AKA' context" -- which way does the
causality go?

Section 4

   Note that we assume (Section 7) that EAP-AKA' is always stronger than
   EAP-AKA.  As a result, there is no need to prevent bidding "down"
   attacks in the other direction, i.e., attackers forcing the endpoints
   to use EAP-AKA'.

I'd prefer to say something like "we do not provide" rather than "there
is no need".

Section 5.2

I agree with the IoTdir reviewer's concerns about over-stating the need
for a secure PRNG in pseudonym generation.

Section 5.3.1

   In all other cases, the following applies:

      The identity used in the key derivation formula MUST be exactly
      the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent,
      regardless of the kind of identity that it may have been.  If no
      AT_IDENTITY was sent, the identity MUST be the exactly the one
      sent in the generic EAP Identity exchange, if one was made.
      Again, the identity MUST be used exactly as sent.

      If no identity was communicated inside EAP, then the identity is
      the one communicated outside EAP in link layer messaging.

      In this case, the used identity MUST be the identity most recently
      communicated by the peer to the network, again regardless of what
      type of identity it may have been.

Just to check: there's a strong message sequencing, so that there cannot
be ambiguity between peers about the "most recently communicated"
identity?

Section 5.3.1.1

     234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org

Should this be using an example domain name instead of 3gppnetwork.org?
(I think "no", but have to check.)

Section 5.3.2.1

     For the null-scheme:

       type0.rid678.schid0.userid0999999999@nai.5gc.mnc015.
       mcc234.3gppnetwork.org

     For the Profile <A> protection scheme:

       type0.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>.
       cip<encryption of 0999999999>.mac<MAC tag value>@nai.5gc.
       mnc015.mcc234.3gppnetwork.org

[ditto]

Section 6

   The EAP-AKA' Session-Id is the concatenation of the EAP Type Code
   (0x32, one byte) with the contents of the RAND field from the AT_RAND
   attribute, followed by the contents of the AUTN field in the AT_AUTN
   attribute:

         Session-Id = 0x32 || RAND || AUTN

   When using fast re-authentication, the EAP-AKA' Session-Id is the
   concatenation of the EAP Type Code (0x32) with the contents of the
   [...]

nit: the second paragraph contradicts the first, since the first one
does not disclaim that it's only for "regular authentication"
(non-fast-reauthentication).

Section 7

      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.

Could we mention that we are not agile with respect to the use of
SHA256/HMAC-SHA256?

Section 7.2

   Basin et al [Basin2018] have performed formal analysis and concluded
   that the AKA protocol would have benefited from additional security
   requirements, such as key confirmation.

This feels a bit like a teaser -- what would be gained/prevented by
using key confirmation?  Is there a path towards performing key
confirmation in the future?

Section 7.3

   As described Section 7.2, after the publication of RFC 5448, new

nit: "As described in"

   In particular, it is crucial that manufacturers limit access to the
   secret information and the cards only to necessary systems and
   personnel.  It is also crucial that secure mechanisms be used to
   communicate the secrets between the manufacturer and the operator
   that adopts those cards for their customers.

No recommendation for encryption at rest?

   Beyond these operational considerations, there are also technical
   means to improve resistance to these attacks.  One approach is to
   provide Perfect Forwards Secrecy (PFS).  This would prevent any
   passive attacks merely based on the long-term secrets and observation
   of traffic.  Such a mechanism can be defined as a backwards-
   compatible extension of EAP-AKA', and is pursued separately from this
   specification [I-D.ietf-emu-aka-pfs].  Alternatively, EAP-AKA'
   authentication can be run inside a PFS-capable tunneled
   authentication method.  In any case, the use of some PFS-capable
   mechanism is recommended.

My preference would be to drop the "Perfect" and also discuss forward
secrecy with respect to specific event(s).  See also the discussion at
https://mailarchive.ietf.org/arch/msg/saag/81XWrBZiLNoPg7kfnAdaxIB8da8/

Section 7.4

   The server receives the EAP transaction from a given access network,
   and verifies that the claim from the access network corresponds to
   the name that this access network should be using.  It becomes
   impossible for an access network to claim over AAA that it is another
   access network.  In addition, if the peer checks that the information
   it has received locally over the network-access link layer matches
   with the information the server has given it via EAP-AKA', it becomes
   impossible for the access network to tell one story to the AAA
   network and another one to the peer.  These checks prevent some

Why is this an "if" the peer checks -- shouldn't it be mandatory?

Appendix 9.2

It looks like the only place we reference [FIPS.180-1] and [FIPS.180-2]
is in the note saying that we updated the references to them :)

One minor comment: I wasn't convinced that this paragraph was needed in the abstract, and thought that it might be better if this was contained in the introduction instead:

   EAP-AKA' differs from EAP-AKA by providing a key derivation function
   that binds the keys derived within the method to the name of the
   access network.  The key derivation function has been defined in the
   3rd Generation Partnership Project (3GPP).  EAP-AKA' allows its use
   in EAP in an interoperable manner.  EAP-AKA' also updates the
   algorithm used in hash functions, as it employs SHA-256 / HMAC-
   SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA.