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
