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://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 ;) -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
