Authors, Just a friendly reminder that this document awaits author action.
Please see the AUTH48 status page at http://www.rfc-editor.org/auth48/rfc9678. Thank you. RFC Editor/mf > On Nov 8, 2024, at 1:41 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > Jari, > > Thanks for your reply. We look forward to hearing back about the questions > once you have your review of them completed. > > RFC Editor/mf > > >> On Nov 5, 2024, at 9:17 AM, Jari Arkko <jari.ar...@piuha.net> wrote: >> >> >> I have reviewed the changes in the diff file. They all looked good to me. We >> still have to answer your questions. We will come to that. >> >> Jari >> >>> Megan Ferguson <mfergu...@amsl.com> kirjoitti 4.11.2024 kello 21.44: >>> >>> Greetings, >>> >>> Just a friendly weekly reminder that this document awaits your attention. >>> Please see the document-specific questions and AUTH48 announcement in this >>> thread and let us know if we can be of assistance as you begin the AUTH48 >>> review process. >>> >>> Please note that the AUTH48 status page of this document is viewable at: >>> >>> http://www.rfc-editor.org/auth48/rfc9678 >>> >>> AUTH48 FAQs are available at https://www.rfc-editor.org/faq/#auth48. >>> >>> We look forward to hearing from you at your earliest convenience. >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>>> On Oct 11, 2024, at 7:12 PM, rfc-edi...@rfc-editor.org wrote: >>>> >>>> Authors, >>>> >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> >>>> 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? >>>> >>>> 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) >>>> >>>> --> >>>> >>>> >>>> 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]. >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> 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... >>>> >>>> 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 >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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.--> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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]. >>>> >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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]. >>>> --> >>>> >>>> >>>> 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: >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>>> --> >>>> >>>> >>>> 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). >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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 >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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... >>>> >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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? >>>> >>>> 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 >>>> >>>> c) We see the use of both "NUL" and "NULL". Please review and let us >>>> know if any updates are necessary. >>>> >>>> --> >>>> >>>> >>>> 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)... >>>> >>>> --> >>>> >>>> >>>> 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) >>>> >>>> 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. >>>> --> >>>> >>>> >>>> 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. --> >>>> >>>> >>>> 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> >>>> >>>> --> >>>> >>>> >>>> 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? --> >>>> >>>> >>>> 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, >>>> >>>> --> >>>> >>>> >>>> Thank you. >>>> >>>> RFC Editor/kf/mf >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2024/10/11 >>>> >>>> RFC Author(s): >>>> -------------- >>>> >>>> Instructions for Completing AUTH48 >>>> >>>> Your document has now entered AUTH48. Once it has been reviewed and >>>> approved by you and all coauthors, it will be published as an RFC. >>>> If an author is no longer available, there are several remedies >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>> >>>> You and you coauthors are responsible for engaging other parties >>>> (e.g., Contributors or Working Group) as necessary before providing >>>> your approval. >>>> >>>> Planning your review >>>> --------------------- >>>> >>>> Please review the following aspects of your document: >>>> >>>> * RFC Editor questions >>>> >>>> Please review and resolve any questions raised by the RFC Editor >>>> that have been included in the XML file as comments marked as >>>> follows: >>>> >>>> <!-- [rfced] ... --> >>>> >>>> These questions will also be sent in a subsequent email. >>>> >>>> * Changes submitted by coauthors >>>> >>>> Please ensure that you review any changes submitted by your >>>> coauthors. We assume that if you do not speak up that you >>>> agree to changes submitted by your coauthors. >>>> >>>> * Content >>>> >>>> Please review the full content of the document, as this cannot >>>> change once the RFC is published. Please pay particular attention to: >>>> - IANA considerations updates (if applicable) >>>> - contact information >>>> - references >>>> >>>> * Copyright notices and legends >>>> >>>> Please review the copyright notice and legends as defined in >>>> RFC 5378 and the Trust Legal Provisions >>>> (TLP – https://trustee.ietf.org/license-info). >>>> >>>> * Semantic markup >>>> >>>> Please review the markup in the XML file to ensure that elements of >>>> content are correctly tagged. For example, ensure that <sourcecode> >>>> and <artwork> are set correctly. See details at >>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>> >>>> * Formatted output >>>> >>>> Please review the PDF, HTML, and TXT files to ensure that the >>>> formatted output, as generated from the markup in the XML file, is >>>> reasonable. Please note that the TXT will have formatting >>>> limitations compared to the PDF and HTML. >>>> >>>> >>>> Submitting changes >>>> ------------------ >>>> >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> >>>> * your coauthors >>>> >>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>> >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> >>>> You may submit your changes in one of two ways: >>>> >>>> An update to the provided XML file >>>> — OR — >>>> An explicit list of changes in this format >>>> >>>> Section # (or indicate Global) >>>> >>>> OLD: >>>> old text >>>> >>>> NEW: >>>> new text >>>> >>>> You do not need to reply with both an updated XML file and an explicit >>>> list of changes, as either form is sufficient. >>>> >>>> We will ask a stream manager to review and approve any changes that seem >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>> and technical changes. Information about stream managers can be found in >>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>> >>>> >>>> Approving for publication >>>> -------------------------- >>>> >>>> To approve your RFC for publication, please reply to this email stating >>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>> as all the parties CCed on this message need to see your approval. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9678.xml >>>> https://www.rfc-editor.org/authors/rfc9678.html >>>> https://www.rfc-editor.org/authors/rfc9678.pdf >>>> https://www.rfc-editor.org/authors/rfc9678.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9678-diff.html >>>> https://www.rfc-editor.org/authors/rfc9678-rfcdiff.html (side by side) >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9678-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9678 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9678 (draft-ietf-emu-aka-pfs-12) >>>> >>>> Title : Forward Secrecy for the Extensible Authentication >>>> Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) >>>> Author(s) : J. Arkko, K. Norrman, J. Preuß Mattsson >>>> WG Chair(s) : Joseph A. Salowey, Peter E. Yee >>>> >>>> Area Director(s) : Deb Cooley, Paul Wouters >>>> >>>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
