Authors, I meant to also ask if it’s possible to update the SVG for figure 2. Currently the PDF and HTML have a circle over the text in one of the upper boxes and the second vertical line in the last box extends into the text box.
Please see Figure 2 in these files: https://www.rfc-editor.org/authors/rfc9678.html#figure-2 https://www.rfc-editor.org/authors/rfc9678.pdf Thanks, RFC Editor/sg > On Feb 26, 2025, at 1:05 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > wrote: > > 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
