Trying to answer the questions: > 1) <!-- [rfced] We had a few questions about the title of this document, > mostly as relates to the expansion of the initialism EAP-AKA'. > We would love some guidance that we can track for future > documents using this abbreviation as it looks like this has not > been consistent thus far. > > a) We believe the single quote following the abbreviation is used to > indicate the "improved" method described in RFC 5448 (as opposed to > basic EAP-AKA from RFC 4187). If this is so, should "improved" be > added to the title of this document?
I think so, what do other authors think? > b) We see past expansions of both EAP-AKA and EAP-AKA' in RFC titles > include 3rd Generation or 3GPP Mobile Network. Should some mention of > 3rd generation be added to the title of this document? > > RFC 4187: > Extensible Authentication Protocol Method for 3rd Generation > Authentication and Key Agreement (EAP-AKA) > > RFC 5448: > Improved Extensible Authentication Protocol Method for > 3rd Generation Authentication and Key Agreement (EAP-AKA') > > RFC 9048: > Improved Extensible Authentication Protocol Method for 3GPP Mobile > Network Authentication and Key Agreement (EAP-AKA') > > c) If the title is really a 1:1 with the initialism, it may be > beneficial for the reader to move the initialism to the front followed > by a colon (common use in RFCs) (see Perhaps A below). > > With *all* the above in mind (a-c), here are some suggested titles. > If none of these fit the bill, please let us know if/how we can > rephrase. > > Perhaps A: > Forward Secrecy Extension to the Improved Extensible Authentication Protocol > for Authentication and Key Agreement (EAP-AKA' FS) > > Perhaps B: > EAP-AKA' FS: The Forward Secrecy Extension for Improved Extensible > Authentication Protocol for Authentication and Key Agreement > > Perhaps C: > Improved Extensible Authentication Protocol Method for 3GPP Mobile Network > Authentication and Key Agreement Forward Secrecy Extension (EAP-AKA' FS) > > --> I personally prefer A, but I don’t have a strong opinion. Retaining the whole stack of content is making the title too long, imho, hence not preferring C. > 2) <!--[rfced] The Abstract and IANA Considerations each contain places > where an (almost) RFC title is listed for one RFC but a > "nickname" for another/others. How may we make these consistent? > > > Abstract: > This document updates RFC 9048, the improved Extensible Authentication > Protocol Method for 3GPP Mobile Network Authentication and Key > Agreement (EAP-AKA'),...Similarly, this document also updates the > earlier version of the EAP-AKA' specification in RFC 5448. > > > IANA: > This extension of EAP-AKA' shares its attribute space and subtypes > with Extensible Authentication Protocol Method for Global System for > Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) > [RFC4186], EAP-AKA [RFC4187], and EAP-AKA' [RFC9048]. > --> Clearly this needs to be corrected. Let’s use the full name in both. > 3) <!--[rfced] FYI - We have added an additional verb to the sentence > below for clarity. Please review to ensure this update retains > your intended meaning. > > Original: > > It has been a goal to implement this change as an extension of the > widely supported EAP-AKA' method, rather than a completely new > authentication method. > > Current: > > It has been a goal to implement this change as an extension of the > widely supported EAP-AKA' method, rather than implement a completely > new authentication method. > > --> Yes, great, thank you! > 4) <!--[rfced] In the text below, is "the subscribers" plural possessive > ("the subscribers'") or singular possessive ("the subscriber's")? > Additionally, are any other updates needed to "home operator's > network"? > > Original: > > The goal of AKA is to mutually authenticate the USIM and the so- > called home environment, which is the authentication server in the > subscribers home operator's network. > > Perhaps: > > The goal of AKA is to mutually authenticate the USIM and the so- > called home environment, which is the authentication server in the > subscriber's home operator's network. > > --> Singular possessive > 5) <!--[rfced] We have the following changes and questions regarding the > SVG and ASCII artwork in this document. > > a. FYI - The SVG artwork in Figure 2 ran off the page in the PDF > output; we have adjusted the height and width attributes to allow this > artwork to fit the page. Please review and let us know any objections > or additional adjustments. Ok > > b. Please review and/or update artworks with the following suggestions > in mind: > > i. Articles appear inconsistently in front of some terms in the > artwork (see an example below). How would you like to update for > consistency? > > Original (with articles): > > The peer also retrieves the network name sent by the network from the > AT_KDF_INPUT attribute... > > Original (without articles): > > Otherwise, the network name from AT_KDF_INPUT attribute... > Ok > ii. Please review instances where the expansion "key derivation > function" may be abbreviated to KDF. > > Original: > > AT_KDF signals the used key derivation function. > > ID, key deriv. function, network name > > Perhaps: > > AT_KDF signals the used KDF. > > ID, KDF, network name > There are different things here. The EAP communication explanations could use AT_KDF etc but the example above is from server to AD, and that doesn’t use EAP attributes. I’d prefer to write out in text the things, without abbreviations, e.g., key derivation function. Alternatively, establish new abbreviations, e.g., key derivation function (KDF) and the say ”KDF”. > c) We note that the text in the figure does not follow this guidance > from RFC 7322 (RFC Style Guide): > > * When a sentence ended by a period is immediately followed by > another sentence, there must be two blank spaces after the period. > > --> > Right. Please fix. > 6) <!--[rfced] We note that Figure 1 contains the only (two) mentions of > AKA'. Elsewhere we see AKA or EAP-AKA'. Please review and > confirm.--> Please use EAP-AKA’ > 7) <!--[rfced] For ease of the reader, may we adjust the text below as > follows? > > Original: > This document specifies a mechanism that reduces risks to > compromise of key material belonging to previous sessions, before > the long-term keys were compromised. > > Perhaps: > This document specifies a mechanism that reduces the risks of > compromising key material belonging to previous sessions, before > the long-term keys were compromised. Ok > --> > > > 8) <!--[rfced] We note a switch between "keying material" and "key > material" in the following. Should these be made consistent? > > Original: > ...and to establish keying material for secure communication between > the two. This document specifies the calculation of key material, > providing new properties that are not present in key material provided > by EAP-AKA' in its original form. > Yes. I prefer key material. > --> > > > 9) <!--[rfced] Might it be helpful to the reader to point them to the > specific 3GPP specifications to which you refer? > > Original: > The details of those interactions are outside the scope of this > document, however, and the reader is referred to the 3GPP > specifications. I don’t see the problem, isn’t the next sentence containing one such reference? > --> > > > 10) <!--[rfced] May we rephrase "taken into use"? While we see a couple > of past instances in RFCs, we wonder if "will be used" has the same > meaning or if there is another rephrase? > > Original: > ...and is willing and able to use the extension defined in this > document, the function is taken into use without any further > negotiation. > > Perhaps: > ...and is willing and able to use the extension defined in this > document, the function will be used without any further > negotiation. > Yes > --> > > > 11) <!--[rfced] Because "Authentication" is part of the expansion of > "AKA'", may we cut it from the following for redundancy (or > anywhere it follows this abbreviation)? > > Original: > ...a party MUST behave as if the current EAP-AKA' authentication > process starts again from the beginning. > > Perhaps: > ...a party MUST behave as if the current EAP-AKA' process starts again > from the beginning. > Yes > --> > > > 12) <!--[rfced] We have some questions regarding the text below from > Section 6.3: > > i. This paragraph appears several paragraphs after the text it > describes. Would it be helpful to have this paragraph appear closer to > the notation it defines? Or to update from "of the notation used > above" to instead use "of the notation used in Figure X" (and add a > title to the text in the <figure> tags? > > ii. For readability, may we reformat the sentence as follows? > > Original: > > For readability, an explanation of the notation used above is copied > here: [n..m] denotes the substring from bit n to m. PRF' is a new > pseudo-random function specified in [RFC9048]. K_encr is the > encryption key, 128 bits, K_aut is the authentication key, 256 bits, > K_re is the re-authentication key, 256 bits, MSK is the Master > Session Key, 512 bits, and EMSK is the Extended Master Session Key, > 512 bits. MSK and EMSK are outputs from a successful EAP method run > [RFC3748]. > > Perhaps: > > For readability, an explanation of the notation used [in Figure X?] > above is copied here: > > * [n..m] denotes the substring from bit n to m. > > * PRF' is a new pseudorandom function specified in [RFC9048]. > > * K_encr is the encryption key (128 bits). > > * K_aut is the authentication key (256 bits). > > * K_re is the re-authentication key (256 bits). > > * MSK is the Master Session Key (512 bits). > > * EMSK is the Extended Master Session Key (512 bits). > > Note: MSK and EMSK are outputs from a successful EAP method run [RFC3748]. > > Yes, this works. And maybe just ”An explanation .. ” (ie. omit the part about readability). > --> > > > 13) <!--[rfced] Many of the subsections in Section 6.5 (Message > Processing) start with "No changes" (see some examples > below). For clarity, would it aid the reader to provide some > additional context in these sections? > > Original: > > 6.5.1. EAP-Request/AKA'-Identity > > No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes > MUST NOT be added to this message. > > 6.5.11. EAP-Response/AKA'-Notification > > No changes. > > Perhaps: > > 6.5.1. EAP-Request/AKA'-Identity > > There are no changes for the EAP-Request/AKA'-Identity, except that > the... > > 6.5.11. EAP-Response/AKA'-Notification > > There are no changes for the EAP-Response/AKA'-Notification. > > --> Yes, this would be good! Thanks. > 14) <!--[rfced] Is "changes to security considerations as they differ" > clear to the reader? Maybe a rephrase of this paragraph would be > helpful? > > Original: > This section deals only with the changes to security considerations > as they differ from EAP-AKA', or as new information has been gathered > since the publication of [RFC9048]. > > Perhaps: > This section deals only with changes to security considerations > for EAP-AKA' or new information that has been gathered > since the publication of [RFC9048]. > --> Yes, that’s better thanks. > > 15) <!--[rfced] FYI - For readability, we have updated the text below as > follows. Please confirm that 5G-AKA and EAP-AKA' are two separate > mechanisms and that the updates to "both" in the final sentence > retain your meaning. > > Original: > > If a mechanism without ephemeral key exchange such as (5G-AKA, EAP- > AKA') is used the effects of key compromise are devastating. There > are serious consequences of not properly providing forward secrecy > for the key establishment. For both control and user plane, and > both directions: > > Current: > > If a mechanism without ephemeral key exchange (such as 5G-AKA or > EAP- AKA') is used, the effects of key compromise are devastating. > There are serious consequences to not properly providing forward > secrecy for the key establishment, for the control plane and the > user plane, and for both directions: > > --> > Yes this is correct. > > 16) <!--[rfced] We had a few questions/comments about the fifth paragraph > of the Security Considerations section: > > > a) This use of the slash character being clarified would be helpful to > the reader as well as avoid subject/verb agreement issues. > > Original: > This extension is most useful when used in a context where the > MSK/EMSK are used in protocols not providing forward secrecy. > > Perhaps: > This extension is most useful when implemented in a context where the > MSK [and, or, and/or?] EMSK are used in protocols not providing FS. Yes. MSK or EMSK. > > b) Clarifying what "this property" refers to might be helpufl to the > reader. Also, rephrasing the clause that begins with "so better > characteristics..." might avoid a possible need to re-read since > "characteristics" seems not to match with "is" for subject/verb > agreement. > > Original: > For instance, if used with IKEv2 [RFC7296], the session keys produced > by IKEv2 have this property, so better characteristics of the MSK and > EMSK is not that useful. I’d say "For instance, if used with IKEv2 [RFC7296], the session keys produced by IKEv2 will in any case have this property, so the improvements from the use of EAP-AKA’ FS are not that useful." > > c) Please confirm this use of "forward secure" instead of "forward > secrecy" there are two other similar instances in the document (we > also see "forward secret"). We will assume they were intended unless > we hear otherwise. > > Original: > However, typical link layer usage of EAP does not involve running > another, forward secure, key exchange. > --> Yes, correct. > 17) <!--[rfced] How may we update this run-on sentence below? > > Original: > > The extension does not provide protection against active attackers > with access to the long-term key that mount an on-path attack on > future EAP-AKA' runs will be able to eavesdrop on the traffic > protected by the resulting session key(s). > > Perhaps: > > The extension does not provide protection against active attackers that > mount an on-path attack on future EAP-AKA' runs and have access to the > long-term key. They will be able to eavesdrop on the traffic protected by > the > resulting session key(s). > --> > Yes, good! > > 18) <!--[rfced] The sentence below introduces a new paragraph, but is > missing a lead-in clause with a subject. How may we adjust? > > Original: > Except of course, if the adversary holds the long-term key and > is willing to engage in an active attack. > > Perhaps: > These attempts will be detected, except of course, if the adversary holds > the long-term key and is willing to engage in an active attack. Ok > > --> > > > 19) <!--[rfced] Is it odd to begin a section with "In addition"? Please > consider if further information should be added here. > > Original: > 7.3. Denial-of-Service > > In addition, it is worthwhile to discuss Denial-of-Service attacks > and their impact on this protocol. The calculations involved in > public key cryptography require co > > --> > Just delete ”In addition, ” Thanks > > 20) <!--[rfced] Is this an accurate rephrase of this text? > > Original: > * This specification is constructed so that a separation between the > USIM and Peer on client side and the Server and AD on > network side is possible. This ensures that the most sensitive > (or legacy) system components cannot be the target of the attack. > For instance, EAP-AKA' and public key cryptography takes place in > the phone and not the low-power USIM card. > > Perhaps: > * This specification is constructed so that it is possible to have > a separation between the USIM and Peer on the client side and > between the Server and AD on the network side. This ensures that > the most sensitive (or legacy) system components cannot be the > target of the attack. For instance, EAP-AKA' and public key > cryptography both take place in the phone and not the low-power > USIM card. > > --> > Yes, good. > > 21) <!--[rfced] "MAC" appears to be used as a verb in the sentence > below. Are any adjustments needed? > > Original: > > K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/ > AKA'-Challenge message... > > --> Right. Maybe ”… encrypt and to calculate a MAC …” > > 22) <!--[rfced] Might the following rephrase be acceptable? > > Original: > This document does not add such algorithms, but a future update can > do that. > > > Perhaps: > Adding such algorithms is out of scope for this document. I’d prefer the original phrasing. We want a positive statement that this is possible. > --> > > > 23) <!--[rfced] We have the following questions and changes regarding the > terminology used in this document. Please review and let us know > any guidance or objections where necessary. > > > a) How may we expand MAC in this document (as abbreviations should be > expanded on first use per Section 3.6 of RFC 7322, "RFC Style Guide")? > > Please note that both MAC and KDF are first used in Figure 1 and within > attribute names before they are expanded; would it benefit the reader to > expand MAC and KDF before these instances for additional context? MAC - Message Authentication Code KDF - Key Derivation Function > b) FYI - The terms below are capped differently throughout this > document. Unless we hear objections, we plan to make these instances > lowercase throughout. > > Server v. server > Peer v. peer > Network v. network Server and Peer are EAP terms, I’d prefer them to be capitalized. Network can be lower case. > > c) We see the use of both "NUL" and "NULL". Please review and let us > know if any updates are necessary. NUL refers to the NUL ASCII character. NULL refers to the 3GPP 33.501 null identity hiding algorithm. Actually, please change NULL to null, as the official 3GPP name is ”null”. > --> > > > 24) <!--[rfced] The terms RAND, AUTN, XRES, RES, IK, and CK appear with > and without articles throughout this document (see an example > below). How may we update for consistency? > > Original: > > The authentication vector > contains a random part RAND, an authenticator part AUTN used for > authenticating the network to the USIM, an expected result part > XRES, a 128-bit session key for integrity check IK, and a 128-bit > session key for encryption CK. > > If this process is successful (the AUTN is valid and the sequence number > used to generate AUTN is within the correct range)... > > --> I’m not sure. Can you suggest how to do it, just based on using proper English? > > 25) <!--[rfced] Regarding abbreviation use throughout the document: > > a) FYI - We have added expansions for abbreviations upon first use per > Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > > Key Derivation Function (KDF) > User Equipment (UE) > Wi-Fi Protected Access 3 (WPA3) > Internet Key Exchange Protocol Version 2 (IKEv2) > Secure Shell (SSH) Ok > b) We have updated to use the abbreviated form after first in > accordance with the guidance at > https://www.rfc-editor.org/styleguide/part2/#exp_abbrev. This mostly > affects FS and KDF. Please let us know any objections. Ok. > --> > > > 26) <!--[rfced] Please review the <artwork> element in Section 6.3 and let us > know > if it should be updated to <sourcecode> or another element. --> It is more of ”equations” or perhaps source code than a figure, so if <sourcecode> is appropriate for this, then go ahead. > 27) <!--[rfced] The reference [NIST-ZT] has been obsoleted. Would you like to > update this reference to its most recent version? > > Original: > > [NIST-ZT] National Institute of Standards and Technology, > "Implementing a Zero Trust Architecture", December 2022, > <https://www.nccoe.nist.gov/sites/default/files/2022-12/ > zta-nist-sp-1800-35b-preliminary-draft-2.pdf>. > > Perhaps: > > [NIST-ZT] National Institute of Standards and Technology, > "Implementing a Zero Trust Architecture", NIST SP > 1800-35, July 2024, <https://www.nccoe.nist.gov/sites/ > default/files/2024-07/zta-nist-sp-1800-35-preliminary-draft-4.pdf> > Yes, please. > > --> > > > 28) <!--[rfced] As the authors are listed in the References section for > each of the three docs pointed to in the Acknowledgments, should > they also be listed in the Acknowledgments section? --> I think it would polite, that’s why we’ve done it. > 29) <!--[rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this > nature typically result in more precise language, which is > helpful for readers. > > For example, please consider whether "Master" should be updated in the > instances below: > > 643: attribute is set to 1, the Master Key (MK) and accompanying keys are > 686: K_re is the re-authentication key, 256 bits, MSK is the Master > 687: Session Key, 512 bits, and EMSK is the Extended Master Session Key, I would like to use a better terminology, but the EMU working group discussion did not support a wholesale update to the terminology, so it is difficult for this document to refer to established EAP terms such as the Master Session Key without using their currently established names. So, sorry, I wish it were otherwise. Jari
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org