Hi Karl and John, Thank you for your replies. We have updated your status to “Approved” at the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9678). We will await approval from Jari as well as any necessary re-rendering of the SVG prior to moving forward in the publication process.
Please note that we will assume your assent to any further changes submitted by your coauthors unless we hear objection at that time. Thank you. RFC Editor/mf > On Jan 9, 2025, at 3:48 AM, Karl Norrman <karl.norr...@ericsson.com> wrote: > > Hi! > > I approve publication. > > BR Karl > > From: John Mattsson <john.matts...@ericsson.com> > Sent: Thursday, January 9, 2025 11:00 AM > To: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Cc: Jari Arkko <jari.ar...@gmail.com>; Karl Norrman > <karl.norr...@ericsson.com>; rfc-edi...@rfc-editor.org; emu-...@ietf.org; > emu-cha...@ietf.org; Peter Yee <pe...@akayla.com>; Paul Wouters > <paul.wout...@aiven.io>; auth48archive@rfc-editor.org; Jari Arkko > <jari.ar...@piuha.net> > Subject: Re: AUTH48: RFC-to-be 9678 <draft-ietf-emu-aka-pfs-12> for your > review > > Mi Megan, > > I approve publication. > > Cheers, > John > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Date: Wednesday, 8 January 2025 at 19:37 > To: John Mattsson <john.matts...@ericsson.com> > Cc: Jari Arkko <jari.ar...@gmail.com>, Karl Norrman > <karl.norr...@ericsson.com>, rfc-edi...@rfc-editor.org > <rfc-edi...@rfc-editor.org>, emu-...@ietf.org <emu-...@ietf.org>, > emu-cha...@ietf.org <emu-cha...@ietf.org>, Peter Yee <pe...@akayla.com>, Paul > Wouters <paul.wout...@aiven.io>, auth48archive@rfc-editor.org > <auth48archive@rfc-editor.org>, Jari Arkko <jari.ar...@piuha.net> > Subject: Re: AUTH48: RFC-to-be 9678 <draft-ietf-emu-aka-pfs-12> for your > review > > [You don't often get email from mfergu...@staff.rfc-editor.org. Learn why > this is important athttps://aka.ms/LearnAboutSenderIdentification ] > > Hi John, > > [Note that this email is coming to you from a new email address on our end.] > > Thanks for reviewing and sending along these changes. We have updated as > requested*. > > *Note that we made one further change to your suggestion for Section 4.1: we > made “goal” singular into “goals” plural. > > Please review the files carefully as we do not make changes after publication. > > The files have been posted here (please refresh): > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194799249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=DTfX%2B2b%2FWhuCV%2B31vBhuD%2BO0JkNQfQ7X6AW00rvgH7I%3D&reserved=0 > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194820216%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Vcebw%2FnzAHbaQ2tLhxd40XY3oXmNEoc7QJO0OESiC%2BY%3D&reserved=0 > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194831820%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=kQ0SVjbUTE%2FU%2Fg0QbLBggWIr5FdgfOVlZ1DZPyQdIJc%3D&reserved=0 > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.xml&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194843048%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=NXRoB81Yz1WhZLF0b93t9q9maunK9t7%2Ft26sxxtjTGE%3D&reserved=0 > > The relevant diff files have been posted here (please refresh): > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678-diff.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194854207%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2Bhec30BDu0B4SWPJpb3IBg%2F56dSxAlMSzi79WrKNUqU%3D&reserved=0 > (comprehensive diff) > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678-auth48diff.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194865160%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=oJgsyJnfNSQerYD8A5w1SFDoDoAz03wS6X4M3xfg9TQ%3D&reserved=0 > (AUTH48 changes only) > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678-lastdiff.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194876066%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Sk%2BmL4Rb%2BryvrsRyttFytqv3h6fENV1rbWPEQRPu6cM%3D&reserved=0 > (last version to this) > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678-lastrfcdiff.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582194889424%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=pFc5MVhtsBcXyzAvzo6OQSWqGmqGkkBS7p4ntxJT7Pc%3D&reserved=0 > (ditto but rfcdiff) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9678&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195131787%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=3I0EdGcWlcX3wXljknSn7go2J8fVOQpd%2FtW0UPsc7mc%3D&reserved=0 > > Thank you. > > RFC Editor/mf > > > On Dec 28, 2024, at 3:42 AM, John Mattsson <john.matts...@ericsson.com> > > wrote: > > > > Hi, > > > > >*General Note*: Please note that any updates made to figures with SVG have > > >been made in the <artwork> only. The > > > authors will need to re-render the SVG to match the desired output. We > > > recommend doing this once AUTH48 > > > changes are complete and all author approvals have been received so that > > > many iterations can be avoided. > > I will re-render the SVG once AUTH48 changes are complete. > > > > I have reviewed the current version of the document and approve > > publication. See minor suggestions below: > > > > Cheers, > > John > > > > --- > > > > OLD: > > This prevents an attacker who has > > gained access to the long-term key from obtaining session keys > > established in the past, assuming these have been properly deleted. > > NEW: > > This prevents an attacker who has > > gained access to the long-term key from obtaining session keys > > established in the past. > > > > John: To align with introduction. Deletion of keys is discussed in several > > sections. > > > > --- > > > > OLD: when a system is running. > > NEW: when the system is running. > > > > John: To align with the bullets above > > > > --- > > > > OLD: > > 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. > > > > NEW: > > 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, and to establish key material > > between the two. > > > > --- > > > > OLD: > > AT_PUB_ECDHE: > > This is set to 152 by IANA. > > > > NEW: > > AT_PUB_ECDHE: > > This is set to 152. > > > > John: The "by IANA" is just confusing > > > > --- > > > > OLD: > > AT_KDF_FS: > > This is set to 153 by IANA. > > > > OLD: > > AT_KDF_FS: > > This is set to 153. > > > > --- > > > > OLD: > > Public key validation requirements are defined in Section 5 of [SP-800-56A]. > > > > NEW: > > Requirements are defined in Section 5 of [SP-800-56A], in particular > > Sections 5.6.2.3.4, 5.6.3.1, and > > and 5.6.3.3. > > > > John: Section 5 is long. I think it is good to help the reader a bit. > > > > --- > > > > OLD: > > 6.5.9. EAP-Response/AKA'-Client-Error > > > > changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST > > > > NEW: > > 6.5.9. EAP-Response/AKA'-Client-Error > > > > There are no changes for the EAP-Response/AKA'-Client-Error, except that > > the AT_KDF_FS or AT_PUB_ECDHE attributes MUST > > > > --- > > > > OLD: > > 6.5.11. EAP-Response/AKA'-Notification > > > > There are no changes for the EAP-Request/AKA'-Notification. > > > > NEW: > > 6.5.11. EAP-Response/AKA'-Notification > > > > There are no changes for the EAP-Response/AKA'-Notification. > > > > --- > > > > OLD: > > [TS.33.501] > > 3GPP, "Security architecture and procedures for 5G > > System", Version 18.1.0, 3GPP TS 33.501, March 2023. > > > > NEW: > > [TS.33.501] > > 3GPP, "Security architecture and procedures for 5G > > System", Version 19.0.0, 3GPP TS 33.501, September 2024. > > > > John: We should refer to the last version > > > > --- > > > > From: Megan Ferguson <mfergu...@amsl.com> > > Date: Friday, 20 December 2024 at 21:57 > > To: Jari Arkko <jari.ar...@gmail.com>, Karl Norrman > > <karl.norr...@ericsson.com> > > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, John Mattsson > > <john.matts...@ericsson.com>,emu-...@ietf.org <emu-...@ietf.org>, > > emu-cha...@ietf.org <emu-cha...@ietf.org>, Peter Yee <pe...@akayla.com>, > > Paul Wouters <paul.wout...@aiven.io>, > > auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>, Jari Arkko > > <jari.ar...@piuha.net> > > Subject: Re: AUTH48: RFC-to-be 9678 <draft-ietf-emu-aka-pfs-12> for your > > review > > > > Jari and Karl, > > > > Thank you for your replies. Please see our (several) questions/comments > > regarding your responses inline in the message below marked with [rfced] > > for places in which further guidance from authors may be necessary or where > > confirmation and careful review of our updates is requested. > > > > *General Note*: Please note that any updates made to figures with SVG have > > been made in the <artwork> only. The authors will need to re-render the > > SVG to match the desired output. We recommend doing this once AUTH48 > > changes are complete and all author approvals have been received so that > > many iterations can be avoided. > > > > All other changes have been incorporated into our version of the files as > > requested. > > > > Please review the files carefully as we do not make changes after > > publication. > > > > The files have been posted here (please refresh): > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195148582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=BHOENhMwaTWpwXo1xqd5Ds5adjYnUtgw65fBR97WGj4%3D&reserved=0 > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195160965%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=BYLlnrosyef7VdRY%2BvVaB39vgooYOMonHfWphBheSQA%3D&reserved=0 > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195172243%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=xlim%2FnMc3qXTMIacPI6JeKzyU%2FrGgwPosr4wbu2HAMs%3D&reserved=0 > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678.xml&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195183472%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=3xcY9BX6%2FhVjMrqVhcOTAGkIvqv4rwLk%2BFyHqB5kBEY%3D&reserved=0 > > > > The relevant diff files have been posted here (please refresh): > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678-diff.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195196923%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=bjORjY%2Bm778rDI%2BLVQUkRsMUw%2FYrajY59BXvROKB0XU%3D&reserved=0(comprehensive > > diff) > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9678-auth48diff.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195208405%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=1ax3v1EO9LFsjfsRI4lW1BDOM%2FC%2FTOEh2L6CF0rfCJ0%3D&reserved=0 > > (AUTH48 changes only) > > > > Please contact us with any further updates/questions/comments you may have. > > > > We will await approvals from each of the parties listed on the AUTH48 > > status page prior to moving forward to publication. > > > > The AUTH48 status page for this document is available here: > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9678&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4bb26f0864c1451c534208dd30132980%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638719582195219555%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=FAeaPfhh1pRcwNrWYqZ4gRRyteUvn37hyN6nXdCty1E%3D&reserved=0 > > > > Thank you. > > > > RFC Editor/mf > > > > > On Dec 13, 2024, at 8:54 AM, Jari Arkko <jari.ar...@gmail.com> wrote: > > > > > > 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? > > > > [Karl]: Yes, I think naming it “Forward Security for the Improved > > Extensible…” would be the correct name and in line with 5448. > > > > > > > >> 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. > > > > [Karl]: I also prefer A. > > > > [rfced] Please see the updated file for the adoption of suggestion A and > > that also includes “Method” (which was accidentally removed in our > > suggestion A we originally sent). > > > > > >> 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. > > > > [rfced] In the IANA Considerations section, we have further updated to make > > this a bulleted list of RFCs to aid in readability. Please review and let > > us know objections. > > > > In the Abstract, we found expanding both very similar document titles so > > close to each other actually tougher to read, so we have updated the text > > differently there. Again, please let us know any objections. > > > > <snip> > > >> > > >> > > >> 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? > > > > [Karl]: I assume this is from just above Figure 2. Maybe we could add a > > reference to [TS 33.501] just for clarity. It is already mentioned a bit > > higher up in the same section for another detail. > > > > [rfced] Please review how we have updated to try and address this issue and > > let us know any objections. > > <snip> > > > > > >> > > >> > > >> > > >> 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). > > > > [rfced] We believe this was assent to both the update and the movement of > > text. Please review how this appears in the file and let us know any > > objections. > > > > <snip> > > > > > > > > >> > > >> 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 …” > > > > [rfced] Please review our update which also removes “data” and let us know > > if this is incorrect. > > > > > > > > >> --> > > >> > > >> > > >> 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? > > > > [rfced] We have made the updates to the body of the text that you can > > review, but have not made changes to the figures as these situations read > > okay to us (since the names were not followed by a label). Please let us > > know if you would like to make any updates like the following to the > > figures or if you too are okay leaving these as they are. > > > > Example: > > > > Current: > > ...generating RAND and AUTN,… > > > > Perhaps: > > ...generating the RAND and AUTN values,... > > > > > > > > > > >> --> > > >> > > >> > > >> 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. > > > > > [rfced] Just a further pointer to the sourcecode type list in case anything > > there seems like it fits. We will leave these as <artwork> unless we hear > > otherwise. > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
