Skip to main content

Last Call Review of draft-ietf-emu-aka-pfs-10
review-ietf-emu-aka-pfs-10-artart-lc-turner-2023-03-14-00

Request Review of draft-ietf-emu-aka-pfs
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-03-13
Requested 2023-02-27
Authors Jari Arkko , Karl Norrman , John Preuß Mattsson
I-D last updated 2023-03-14
Completed reviews Secdir Last Call review of -10 by Carl Wallace (diff)
Opsdir Last Call review of -10 by Bo Wu (diff)
Artart Last Call review of -10 by Sean Turner (diff)
Genart Last Call review of -10 by Linda Dunbar (diff)
Assignment Reviewer Sean Turner
State Completed
Request Last Call review on draft-ietf-emu-aka-pfs by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/Aua-Uh5CRr9oDEIanfD6qw8WqVM
Reviewed revision 10 (document currently at 12)
Result Ready w/nits
Completed 2023-03-14
review-ietf-emu-aka-pfs-10-artart-lc-turner-2023-03-14-00
Hi this is my ARTART review of draft-ietf-emu-aka-pfs-10. Note that I provided
comments on an early version of this I-D when it was still being working in
EMU.  I am going to read this with my ARTART glasses on.

Since all of my comments were editorial nits, I submitted them via the
following PR: https://github.com/emu-wg/eap-aka-pfs/pull/45

I included them here too.

1) abstract & intro: SIM expanded later so move it up.

  1st para: s/SIM/Subscriber Identity Module (SIM)
  2nd para: s/Subscriber Identity Module (SIM)/SIM

2) In the abstract this is a bit awkward:

  However, the danger of resourceful
  attackers for these systems is still a concern.  Always assuming
  breach such as key compromise and minimizing the impact of breach are
  essential zero-trust principles.

Maybe:

  However, resourceful attackers are always a cause for concern.  Always
  assuming a breach, such as key compromise, and minimizing the impact of
  breach are essential zero-trust principles.

3) s1 includes the following:

   They are a high-value target and concern a large number of
   people.

Is it that a large number of people are concerned about the high-value target
or that it affects a large number of people if compromised? I assume the later
based on text later in this section.

4) s1 includes the following:

  … gaining unlawful access to key material

Is it unlawful or unauthorized? I assume unauthorized as it includes unlawful.

5) s1 includes the following:

OLD:

While the better protection
   of manufacturing and other processes is essential in protecting
   against this, 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?

Could this be restated as:

  While better protections for manufacturing
  and other processes are essential to mitigate these attacks, there
  is one question that protocol designers can ask: is there
  something that we can do to limit the consequences of attacks,
  should they occur?

6) s1 contains the following:

  The authors want to provide a public specification of an extension
  that helps defend against one aspect of pervasive surveillance.

Could this be restated as:

  This document specifies an
  extension that helps defend against one aspect of pervasive
  surveillance.

Likewise:

  While adding forward secrecy to the existing mobile network
  infrastructure can be done in multiple different ways, the authors
  believe that the approach chosen here is relatively easily
  deployable.

Could this be restated as:

  While adding forward secrecy to the existing mobile network
  infrastructure can be done in multiple different ways, this document
  specifies a solution that is relatively easily
  deployable.

7) s3.2: s/our goal/the goal

8) s3.2, Table 1 end of 1st box: Could this be rephrased from:

 … used in creating
 … used to create

9) s3.2, Table 1 2nd box:  Could this be rephrased:

   The two names are compared for discrepancies,
   and if necessary, the authentication is aborted

to

 The two names  are compared for discrepancies,
 and if they do not match, the authentication is aborted

10) s3.2, Table 1 last box: Could this be rephrased:

  to be found correct.

as

  compared values match, respectively.

11) Since we trying to do FS, maybe “retain” isn’t the best word :) Also, isn’t
it the session that new keys provide the security for?

s/To retain the security of the keys,/To ensure the security of the session

12) s6.2: s/This specification only specifies /This document only specifies

13) s6.3:

s/[RFC9048] EAP-AKA’/EAP-AKA' [RFC9048]

Added ref for “privacy-friendly identifier” -> see RFC 9048.

14) s6.5.3: Maybe instead of this:

  Finally, the operation in case an error occurs is
   specified in Section 6.3.1. of [RFC4187].

this:

   Finally, if there is an error, see Section 6.3.1. of [RFC4187].

15) s6.5.4: Maybe instead of this (not sure if it’s these attributes - where
these refers to the two attributes defined herein or this attribute - where
this refers to AT_RES? - assumed the latter):

  Only if these attribute
   is verified to be valid, the Server derives keys and verifies AT_MAC.

this:

  The Server derives keys and verifies AT_MAC inly when this attribute
  is verified to be valid.

16) s7: Maybe instead of:

  It is RECOMMENDED to long term completely phase out
   AKA without forward secrecy.

this:

  It is RECOMMENDED
   that AKA without forward secrecy be phased out.

17) s8: Missing a ) in the middle paragraph.

18) s8: Minor edits to 3rd para to tell IANA to make a registry ;) It’s not
like they wouldn’t follow the should, but you never know ;)