Hi Sean,
Thanks for your detailed review and thanks for making a GitHub PR!
I have now merged you PR with the small changes we agreed on. We will soon submit a -11 version. We still have a few more changes that needs to be done.
Cheers,
John
From:
Sean Turner via Datatracker <noreply@xxxxxxxx>
Date: Tuesday, 14 March 2023 at 19:11
To: art@xxxxxxxx <art@xxxxxxxx>
Cc: draft-ietf-emu-aka-pfs.all@xxxxxxxx <draft-ietf-emu-aka-pfs.all@xxxxxxxx>, emu@xxxxxxxx <emu@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Artart last call review of draft-ietf-emu-aka-pfs-10
Reviewer: Sean Turner
Review result: Ready with Nits
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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-8029d57923e1fbef&q=1&e=bbac2ffb-e601-49e4-8ba3-cced5024fcf0&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Feap-aka-pfs%2Fpull%2F45
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 ;)
|
