Hi all, Please note that publication of this document is being delayed while we try to understand what is causing figure 2 in the PDF to run off the page.
See https://www.rfc-editor.org/authors/rfc9678.pdf We can scale it, but we’re looking into it a bit more because it becomes pretty small. See https://www.rfc-editor.org/v3test/test9678.pdf Thanks, RFC Editor/sg > On Feb 16, 2025, at 6:24 AM, Jari Arkko <jari.ar...@gmail.com> wrote: > > Hi, > > Sorry for the delay, but today I finally had a chance to read the document > from top to bottom, and I have no issues. I approve publication in the > current state! > > Jari > >> Madison Church <mchu...@staff.rfc-editor.org> kirjoitti 10.2.2025 kello >> 19.24: >> >> Hi Jari, >> >> This is a friendly weekly reminder that this document awaits your approval. >> Please see the thread below for links to the current version and let us know >> if we can be of assistance as you complete your AUTH48 review. Once we >> receive your approval, we will move this document forward in the publication >> process. >> >> Thank you! >> >> RFC Editor/mc >> >>> On Feb 3, 2025, at 4:14 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> >>> wrote: >>> >>> Hi Jari, >>> >>> Just a friendly reminder that this document awaits your approval. Please >>> see the mail below for links to the current version and let us know if we >>> can be of assistance as you complete your AUTH48 review. >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> >>>> On Jan 22, 2025, at 12:15 PM, Megan Ferguson >>>> <mfergu...@staff.rfc-editor.org> wrote: >>>> >>>> Hi John, >>>> >>>> Thanks for sending this along. >>>> >>>> We have adopted this version in our links below. Note that these changes >>>> are not viewable in diffs of the text files from the previous version to >>>> this one as they are “behind the scenes”, so we have created diffs between >>>> the xml files to capture them below. Please review the xml version and >>>> ensure it looks as expected and let us know if any further changes are >>>> necessary. >>>> >>>> We believe once we hear approval from Jari that this document will be >>>> ready to move forward in the publication process. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9678.txt >>>> https://www.rfc-editor.org/authors/rfc9678.pdf >>>> https://www.rfc-editor.org/authors/rfc9678.html >>>> https://www.rfc-editor.org/authors/rfc9678.xml >>>> >>>> The diff files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9678-diff.html (cumulative) >>>> https://www.rfc-editor.org/authors/rfc9678-rfcdiff.html (side by side) >>>> >>>> https://www.rfc-editor.org/authors/rfc9678-auth48diff.html (AUTH48 changes >>>> only) >>>> https://www.rfc-editor.org/authors/rfc9678-auth48rfcdiff.html (side by >>>> side) >>>> >>>> https://www.rfc-editor.org/authors/rfc9678-lastdiff.html (changes last >>>> version to this) >>>> https://www.rfc-editor.org/authors/rfc9678-lastrfcdiff.html (side by side) >>>> >>>> https://www.rfc-editor.org/authors/rfc9678-xmldiff.html (xml files last to >>>> this) >>>> https://www.rfc-editor.org/authors/rfc9678-xmlrfcdiff.html (side by side) >>>> >>>> The AUTH48 status page for this document is available here: >>>> https://www.rfc-editor.org/auth48/rfc9678 >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>> >>>>> On Jan 18, 2025, at 3:49 AM, John Mattsson <john.matts...@ericsson.com> >>>>> wrote: >>>>> >>>>> Thanks Megan, >>>>> >>>>> Attached is an updated xml file with SVG artwork updated to match the >>>>> updated ASCII artwork. The only changes are in <artwork type="svg" >>>>> >>>>> Cheers, >>>>> John >>>>> >>>>> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> >>>>> Date: Thursday, 9 January 2025 at 17:36 >>>>> To: Karl Norrman <karl.norr...@ericsson.com>, John Mattsson >>>>> <john.matts...@ericsson.com>, jari.ar...@gmail.com <jari.ar...@gmail.com> >>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>>>> emu-...@ietf.org <emu-...@ietf.org>, emu-cha...@ietf.org >>>>> <emu-cha...@ietf.org>, pe...@akayla.com <pe...@akayla.com>, >>>>> paul.wout...@aiven.io <paul.wout...@aiven.io>, >>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>, >>>>> jari.ar...@piuha.net <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 Karl and John, >>>>> >>>>> Thank you for your replies. We have updated your status to “Approved” at >>>>> the AUTH48 status page >>>>> (seehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9678&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855340837%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8Pddg80n1avbH8r3QrG78l%2FHWcK%2FjlyDLxKEnhvn0pQ%3D&reserved=0). >>>>> 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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855360597%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=153H6dX0BEFdQRT5OnFzOo8SjM%2BYaE0ufWYk%2FSD11%2Fk%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855378168%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eO6x7w8Uyors%2BMrceuNIc8aHEWBG8T%2F%2Fj0UoItpKGDM%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855391803%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MpwcGgWtFLh8IliygN4c9tZwMeYcljUgCusf9a9EsTs%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855403745%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KDvGVyovNngd%2Bs1%2B%2FZO%2Bmer%2BHS2aGULciLC4mh%2FNfMg%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855417170%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VVO4lDD9NEAYNpE3A6efwq1X8VmmmhIdd%2FzL9ON2yc4%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855435138%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Bn5ak94%2FKy131rmYeBcBhACLyurZchvdPrwHn7RNjD0%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855458959%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yWv3Y4fkoX31NL%2FN8v1tClAKV2MEN%2F0Te2mh3TbjWcc%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855480774%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pldzp8DH6rOKRh2%2FtP2UFz0wcs3cCDglXMmEIlgzySc%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855502177%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jLDAspx6TjYHXeX%2F%2B77nWSFlj%2Fl3IcQgB%2FZ4F4rK9Lw%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855515106%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qhFD8v%2BkbuCgDHlzRmMZXNw6ftoR4h7YcV2dFojSGsM%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855529955%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cTNKMtqNTgh%2FgkkCS1NJAQB%2BEP%2FyKC2WkCNXMUA5%2BZM%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855545947%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2pxWiEAkfxVzf%2F2xNuJzHXJN9SE36oHBEt88Y4R6RTU%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855558697%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JLEVO1HNvBCENvfRoNHHuGtH0OiYVXwF5YtioQmVnQo%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855572025%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iEyNmr1EPgqw0HYqKgNcTQH9R39hZ3yFLLqXQSSyCh8%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855583571%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=krvdV%2B%2FAFZ0hllFnPg6vc38BKGJ3lETDVq9FOyh53p8%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%7C6b4b14f529804fc423a108dd30cbadbc%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638720373855595063%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ybll%2FHp7R1ExjcuIwBMog6HVH1UCMW2oTfcpbFUUAI8%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. >>>>>> >>>>> >>>>> <rfc9678_JPM.xml> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
