Subject: [Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 16:47:53 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-rfc5448bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

     [email-masked]

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:

       [email-masked].
       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 :)