Dear Dan, Thank you very much for your responses to our additional questions.
This item is still pending: >> Also, please confirm that the single instance of "a/eap/1" is correct (i.e., >> "would be "a/eap/1" should not be "would be /a/eap/1"). Should the single instance of "a/eap/1" be "/a/eap/1"? In other words, is it correct that this one instance does not include a slash before the "a"? We ask because of the entries we see in Figure 3. Currently: So, per Figure 3, the URI for the first resource would be "a/eap/1". = = = = = The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9820.txt https://www.rfc-editor.org/authors/rfc9820.pdf https://www.rfc-editor.org/authors/rfc9820.html https://www.rfc-editor.org/authors/rfc9820.xml https://www.rfc-editor.org/authors/rfc9820-diff.html https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9820-auth48diff.html https://www.rfc-editor.org/authors/rfc9820-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9820-lastdiff.html https://www.rfc-editor.org/authors/rfc9820-lastrfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html https://www.rfc-editor.org/authors/rfc9820-xmldiff2.html Thanks again! RFC Editor/lb > On Aug 8, 2025, at 3:39 AM, Dan Garcia Carrillo <garcia...@uniovi.es> wrote: > > Dear RFC Editor, > Please see responses inline. > El 4/8/25 a las 21:02, Lynne Bartholomew escribió: >> [You don't often get email from lbartholo...@staff.rfc-editor.org. Learn why >> this is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Dear Dan, >> >> Thank you very much for the updated XML file and answers to our questions! >> >> We have some follow-up items for you. Please let us know how this document >> should be further updated. >> >> = = = = = >> >> * Please note that per post-6000 published RFCs (except for RFC 8995), we >> changed '4.04 Not found' to '4.04 Not Found'. Please let us know any >> objections. >> > [AUTHORS] No objections to the update. > >> = = = = = >> >> * Regarding our question 13) and your reply: As it appears that "Finally, >> sends" means "Finally, the CoAP-EAP application sends", per your note that >> the CoAP-EAP application takes control, we updated the "Step 2" text >> accordingly. If this is incorrect, please clarify the "Finally, sends" >> sentence. >> > [AUTHORS] No objections to the text update. Yes, it is the CoAP-EAP > application. > > >> >>>> 13) <!-- [rfced] Section 3.2: Do "assigns" and "sends" refer to the >>>> EAP peer or the EAP peer state machine? If the suggested text is not >>>> correct, please provide clarifying text. >>>> >>>> Original (previous text is included for context): >>>> * Step 2. The EAP peer processes the POST message sending the EAP >>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>> an EAP response (EAP Resp/Id). Then, assigns a new resource to >>>> the ongoing authentication process (e.g., '/a/eap/2'), and deletes >>>> the previous one ('/a/eap/1'). Finally, sends a '2.01 Created' >>>> response with the new resource identifier in the Location-Path >>>> (and/or Location-Query) options for the next step. >>>> >>>> Suggested (guessing the EAP peer state machine): >>>> * Step 2. The EAP peer processes the POST message, sending the EAP >>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>> an EAP response (EAP Resp/Id). Then, the EAP peer state machine >>>> assigns a new resource to the ongoing authentication process >>>> (e.g., '/a/eap/2') and deletes the previous one ('/a/eap/1'). >>>> Finally, the EAP peer state machine sends a '2.01 Created' >>>> response with the new resource identifier in the Location-Path >>>> (and/or Location-Query) options for the next step. --> >>>> >>>> >>> [Authors] We believe the best way to specify this is to differentiate >>> between "EAP peer state machine" and the CoAP-EAP application of the EAP >>> peer. >>> The EAP peer state machine only deals with EAP messages. Processes EAP >>> requests and returns an EAP response. >>> With that, the CoAP-EAP application within the EAP peer takes control and >>> manages everything CoAP related. Assigns a new resource to the ongoing >>> authentication process (e.g., '/a/eap/2') and deletes the previous one >>> ('/a/eap/1') >>> So, a suggested new text. >>> Step 2. The EAP peer processes the POST message sending the EAP >>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>> an EAP response (EAP Resp/Id). Then, the CoAP-EAP application >>> assigns a new resource to the ongoing authentication process >>> (e.g., '/a/eap/2'), and deletes the previous one ('/a/eap/1'). >>> Finally, sends a '2.01 Created'response with the new resource >>> identifier in the Location-Path (and/or Location-Query) options >>> for the next step. >>> >>> >> >> = = = = = >> >> * Regarding our question 25) and your reply: Because of the preceding >> sentence ("The other supported and negotiated cipher suites are as >> follows:"), it was not clear to us how best to update this text. Please >> review our update, and let us know if anything is incorrect: >> > > [AUTHORS] No objections to the text update. > > >> >>>> 25) <!-- [rfced] Sections 6.1 and Appendix A: Do these algorithms need >>>> to be numbered? If yes, will this numbering scheme be clear to >>>> readers? >>>> >>>> Original: >>>> * 0) AES-CCM-16-64-128, SHA-256 (default) >>>> >>>> * 1) A128GCM, SHA-256 >>>> >>>> * 2) A256GCM, SHA-384 >>>> >>>> * 3) ChaCha20/Poly1305, SHA-256 >>>> >>>> * 4) ChaCha20/Poly1305, SHAKE256 >>>> ... >>>> * 5) TLS_SHA256 >>>> >>>> * 6) TLS_SHA384 >>>> >>>> * 7) TLS_SHA512 >>>> >>>> Perhaps: >>>> * AES-CCM-16-64-128, SHA-256 (default) >>>> >>>> * A128GCM, SHA-256 >>>> >>>> * A256GCM, SHA-384 >>>> >>>> * ChaCha20/Poly1305, SHA-256 >>>> >>>> * ChaCha20/Poly1305, SHAKE256 >>>> ... >>>> * TLS_SHA256 >>>> >>>> * TLS_SHA384 >>>> >>>> * TLS_SHA512 >>>> >>>> --> >>>> >>>> >>> [Authors] The numbers on Sections 6.1 match the values in “9.1. CoAP-EAP >>> Cipher Suites”. >>> The numbers in Appendix A are the expected continuation of these, but are >>> not in the specification, and not in the IANA section. This text should >>> also solve issue 42 as well. >>> Suggested update text: >>> The following hash algorithms are considered in case the specification >>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>> >> = = = = = >> >> * Regarding our question 38) and your reply: Please review our updates >> related to the removal of the Zigbee reference, and let us know if anything >> is incorrect. >> >> > > [AUTHORS] No objections to the text update. > > >>>> 38) <!-- [rfced] [ZigbeeIP]: We could not find this document number. >>>> We also found that >>>> <https://urldefense.com/v3/__https://www.zigbee.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4xoZxesQ$ >>>> > steers to >>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>> >. When we searched >>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>> > for >>>> the number 095023r34, the result was "Nothing found, please try >>>> adjusting your search." >>>> >>>> Should a different paper be listed here and cited in Appendices B and >>>> C.5.1? >>>> >>>> Original: >>>> [ZigbeeIP] Zigbee Alliance, "ZigBee IP Specification (Zigbee Document >>>> 095023r34)", 2014. --> >>>> >>>> >>>> >>> [Authors] Certainly, this seems to be an old reference. We have other >>> examples, the best course of action would be to remove this reference and >>> the associated text. >>> Forced removal can be done by sending new specific key material to the >>> devices that still belong to the network, excluding the removed device, >>> following a model similar to CoJP for 6TiSCH [RFC9031] or Zigbee IP >>> [ZigbeeIP]. >>> – >>> Another example would be when a shared Network Key is required by the >>> devices that join a network. An example of this Network Key can be found in >>> Zigbee IP [ZigbeeIP] or the THREAD protocol [THREAD]. >>> >> >> = = = = = >> >> * Regarding our question 42) and your reply: Because TLS_SHA256, TLS_SHA384, >> and TLS_SHA512 are already in the list, is it necessary to also mention them >> in the preceding text? >> >> >>>> 42) <!-- [rfced] Appendix A: Should "considered" be "supported" in this >>>> sentence, along the lines of "The other supported and negotiated >>>> cipher suites are the following" as seen in Section 6.1? >>>> >>>> Original: >>>> The hash algorithms considered are the following: >>>> >>>> * 5) TLS_SHA256 >>>> >>>> * 6) TLS_SHA384 >>>> >>>> * 7) TLS_SHA512 >>>> >>>> Possibly: >>>> The following hash algorithms are supported: >>>> >>>> * 5) TLS_SHA256 >>>> >>>> * 6) TLS_SHA384 >>>> >>>> * 7) TLS_SHA512 --> >>>> >>>> >>> [Authors] Following the previous issue (point 25) >>> Proposed text. >>> The following hash algorithms are considered in case the specification >>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>> >> >> Possibly: >> The following hash >> algorithms are considered in cases where the specification includes DTLS >> support in the future: >> > [AUTHORS] Having the ciphersuites already in the list, it is ok not to > mention them in the preceding text. > > >> = = = = = >> >> * Regarding our question 57) and the following items: >> >> >>>> b) The following terms appear to be used inconsistently in this >>>> document. Please let us know which form is preferred. >>>> >>>> "a/eap/1" (the URI for the first resource would be "a/eap/1") / >>>> '/a/eap/1' >>>> >>>> >>> [AUTHORS] "a/eap/1" >>> >> >> Apologies for missing this earlier: We see the following: >> >> >>> So, per Figure 3, the URI for the first resource would be "a/eap/1". >>> >> We also see the following: >> >> >>> '/a/eap/1' >>> "/a/eap/1" >>> >> Are single quotes or double quotes preferred? >> Also, please confirm that the single instance of "a/eap/1" is correct (i.e., >> "would be "a/eap/1" should not be "would be /a/eap/1"). >> > [AUTHORS] Please, consider changing to double quotes. > > > >> = = = >> >> >>>> EAP-Request/Identity / EAP Req/Id / EAP-Req/Id >>>> >>>> >>> [AUTHORS] EAP-Request/Identity >>> >> >>>> EAP-Response/Identity / EAP Resp/Id / EAP Response/Id >>>> >>>> >>> [AUTHORS] EAP-Response/Identity >>> >> >> Apologies for not realizing earlier that using the longer forms >> "EAP-Request/Identity" and "EAP-Response/Identity" in Figures 3, 5, and 8 >> could cause spacing issues in the SVG. >> >> To avoid such spacing issues and define these terms properly where first >> used, we suggest the following: >> >> - In Section 3.2, define the abbreviated forms by changing "(EAP >> Request/Identity)" to >> "(EAP-Request/Identity, or EAP-Req/Id)" and changing "an EAP response (EAP >> Resp/Id)" to >> "an EAP response (EAP-Response/Identity, or EAP-Resp/Id)". >> - In Section 6.1, change "both the EAP-Request/Identity and >> EAP-Response/Identity" to >> "both the EAP-Req/Id and EAP-Resp/Id". >> - In Section 8.6, change "EAP Request/Id" to "EAP-Req/Id", and change "EAP >> Response/Id" to "EAP-Resp/Id". >> >> > [AUTHORS] No objections to the text update. > > >> = = = >> >> Regarding this item: >> >> >>>> EAP response / EAP Response (used generally in text, e.g., >>>> "an EAP response", "an EAP Response") >>>> (We also see "EAP Response header" in Section 7.1.) >>>> >>>> >>> [AUTHORS] EAP Response >>> >> Please confirm that "EAP Response" when used generally in text is as >> desired. We ask because we see "EAP request" used consistently throughout >> the text when used generally. >> >> > > [AUTHORS] Both should be Capitalized. EAP Response and EAP Request. > > >> = = = = = >> >> Regarding this item: >> >> >>>> Session-Lifetime / Session-lifetime / Session Lifetime / >>>> session lifetime (in running text) >>>> (Figure 3 and Table 4 use "Session-Lifetime".) >>>> >>>> >>> [AUTHORS] Session-Lifetime >>> >> >> After updating "session lifetime" to "Session-Lifetime", this sentence is >> now a bit confusing, as RFC 5247 >> does not mention "Session-Lifetime". Should this sentence be rephrased, or >> will it be clear to readers? >> >> Original: >> * Step 7. When the EAP authentication ends successfully, the EAP >> authenticator obtains the Master Session Key (MSK) exported by the >> EAP method, an EAP Success message, and some authorization >> information (e.g., session lifetime) [RFC5247]. >> >> Currently: >> * Step 7. When the EAP authentication ends successfully, the EAP >> authenticator obtains the MSK exported by the EAP method, an EAP >> Success message, and some authorization information (e.g., >> Session-Lifetime) [RFC5247]. >> >> Possibly: >> * Step 7. When the EAP authentication ends successfully, the EAP >> authenticator obtains the MSK exported by the EAP method, an EAP >> Success message, and some authorization information [RFC5247] (e.g., >> Session-Lifetime). >> >> > > [AUTHORS] It is correct that Session-Lifetime is not specified in RFC5247, > but it is something we propose to use as an authorization information > instance so the “Possibly” text is correct for us. > > Thank you. > Best regards. > >> = = = = = >> >> The latest files are posted here. Please refresh your browser: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.txt__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbJZA27Ts$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.pdf__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbMyfW1jC$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbLKsqN1X$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.xml__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbP80vQJQ$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-diff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbH0Jmnq8$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbEun-yU8$ >> (side by side) >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-auth48diff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbJC23Knu$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-auth48rfcdiff.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbN_-hSIL$ >> (side by side) >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbLA__aeT$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff2.html__;!!D9dNQwwGXtA!SmaxO7K_ObFZjodcUznRgUKaC4vxIdw6YKWcpvETu7efhpbuKT-ui8hXft2FSGl54UWkXEwnINU9-p9VCbIPCNIVbNa1m-S9$ >> >> Thanks again for your help and patience! >> >> RFC Editor/lb >> >> >> >>> On Jul 29, 2025, at 10:09 AM, Dan Garcia Carrillo <garcia...@uniovi.es> >>> wrote: >>> >>> Dear RFC Editor, >>> Please see answers inline. For the requested clarifications in Figures, we >>> attach a .xml version with the figures updated. >>> Please, let us know if anything else is required. >>> >>> El 18/7/25 a las 19:53, rfc-edi...@rfc-editor.org escribió: >>> >>>> Authors and AD*, >>>> >>>> *AD, please see question #1 below. >>>> >>>> Authors, while reviewing this document during AUTH48, please resolve (as >>>> necessary) the following questions, which are also in the XML file. >>>> >>>> >>>> 1) <!-- [rfced] *AD, text was added to the Acknowledgements section after >>>> the >>>> document was approved for publication. Please review the changes and >>>> let us know if you approve. >>>> >>>> Diff between v14 and v15: >>>> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-wg-coap-eap-15__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH77QRYqZw$ >>>> --> >>>> >>>> >>>> 2) <!-- [rfced] Please note that the title of the document has been >>>> updated as >>>> follows. We expanded abbreviations per Section 3.6 of RFC 7322 ("RFC >>>> Style Guide"), recast "-based" to avoid using a hyphen with an expansion, >>>> and added "for Use with". Please review. >>>> >>>> Original: >>>> EAP-Based Authentication Service for CoAP >>>> >>>> Current: >>>> Authentication Service Based on the Extensible Authentication Protocol >>>> (EAP) for Use with the Constrained >>>> Application Protocol (CoAP) >>>> --> >>>> >>>> >>> [Authors] This change is ok. >>> >>>> >>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the >>>> title) for use on >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7N7e55Gg$ >>>> >. --> >>>> >>>> >>> [Authors] We believe that these could be keywords representing the work: >>> >>> CoAP, EAP, EAP lower layer, Internet of Things, IoT, Constrained Node, >>> Smart Object >>> >>> >>>> 4) <!-- [rfced] Abstract: We had trouble following the meaning of >>>> "transported" in this sentence. If the suggested text is not >>>> correct, please provide clarifying text. >>>> >>>> Original: >>>> This document specifies an authentication service that uses the >>>> Extensible Authentication Protocol (EAP) transported employing >>>> Constrained Application Protocol (CoAP) messages. >>>> >>>> Suggested: >>>> This document specifies an authentication service that uses the >>>> Extensible Authentication Protocol (EAP) as a transport method that >>>> employs Constrained Application Protocol (CoAP) messages. --> >>>> >>>> >>> [Authors] The suggested text can be misleading as the protocol being >>> carried is EAP and the one that carries EAP is CoAP. >>> Next, our suggested text would be: >>> This document specifies an authentication service that uses the >>> Constrained Application Protocol (CoAP) as a transport method to >>> carry the Extensible Authentication Protocol (EAP). >>> >>> >>> >>>> 5) <!-- [rfced] We found quite a few undefined abbreviations in this >>>> document. For ease of the reader, we expanded as many of them as we >>>> could find. Most were straightforward (e.g., SAML per RFC 7833, >>>> PANA per RFC 5191), but please confirm that our expansions for MIC >>>> (currently "Message Integrity Check") and LoRa (currently "Long >>>> Range") are correct. >>>> >>>> Original: >>>> EAP relies on lower layer error >>>> detection (e.g., CRC, checksum, MIC, etc.). >>>> ... >>>> Given that EAP is also used for network access authentication, this >>>> service can be adapted to other technologies. For instance, to >>>> provide network access control to very constrained technologies >>>> (e.g., LoRa network). >>>> >>>> Currently (fixed the incomplete sentence in the "LoRa" text): >>>> EAP relies on lower-layer error >>>> detection (e.g., CRC, checksum, Message Integrity Check (MIC), >>>> etc.). >>>> ... >>>> Given that EAP is also used for network access authentication, this >>>> service can be adapted to other technologies - for instance, to >>>> provide network access control to very constrained technologies >>>> (e.g., Long Range (LoRa) networks). --> >>>> >>>> >>> [Authors] Yes, these suggestions are correct. >>> >>> >>>> 6) <!-- [rfced] Section 2: These sentences did not parse. We updated >>>> the text. If this is incorrect, please provide clarifying text. >>>> >>>> Original: >>>> The rationale behind this decision >>>> is that EAP requests direction is always from the EAP server to the >>>> EAP peer. Accordingly, EAP responses direction is always from the >>>> EAP peer to the EAP server. >>>> >>>> Currently: >>>> The rationale behind this decision is that EAP requests will always >>>> travel from the EAP server to the EAP peer. Accordingly, EAP >>>> responses will always travel from the EAP peer to the EAP server. --> >>>> >>>> >>>> >>> [Authors] Yes, these suggestions are correct. >>> >>> >>> >>>> 7) <!-- [rfced] Please review each artwork element. Should any artwork >>>> element be tagged as sourcecode? If the current list of preferred >>>> values for "type" on >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5spEm40g$ >>>> > >>>> does not contain an applicable type, please let us know. Also, it is >>>> acceptable to leave the "type" attribute unset. --> >>>> >>>> >>> [Authors] We assume that this is in reference to "Figure 6: CBOR Data >>> Structure for CoAP-EAP". >>> It is not our intention to specify sourcecode, it could be left as type >>> unset. >>> >>> >>>> 8) <!-- [rfced] Figure 1: We see "(SCOPE OF THIS DOCUMENT)" in the >>>> ASCII art but "SCOPE OF THIS DOCUMENT" in the SVG. If you prefer the >>>> parentheses, please correct the SVG in the edited copy of the XML. >>>> If you prefer that the parentheses be removed, let us know, and we >>>> will update the ASCII art accordingly. --> >>>> >>>> >>>> >>> [Authors] There are no need for parentheses, the message is clear without >>> them. >>> >>> >>>> 9) <!-- [rfced] Figure 2: We changed "Request/Responses/Signaling" to >>>> "Request / Responses / Signaling", to match the spacing style of the >>>> other entries in the figure. However, the "Request / Responses / >>>> Signaling" line now looks a bit crowded in the SVG renderings in the >>>> HTML and PDF output files. We cannot determine where in the SVG a >>>> coordinate should be modified to correct the spacing. Please correct >>>> the SVG in the edited copy of the XML. --> >>>> >>>> >>> [Authors] The line should say >>> Requests / Responses / Signaling >>> >>> We have provided a new <artwork> code in the attached document >>> rfc9820_modified.xml that is not so crowded and tries to convey the >>> improvements. >>> This is also updated in svg in the attached file rfc9820_modified.xml >>> >>> >>>> 10) <!-- [rfced] Sections 3.1 and subsequent: We see phrases such as >>>> "an intermediary proxy", "intermediary (i.e., proxy)", and >>>> "intermediaries such as proxies" in this document. Will the >>>> distinction regarding whether or not intermediaries are sometimes or >>>> always proxies be clear to readers? --> >>>> >>>> >>> [Authors] We are following CoAP terminology, being according to rfc7252 >>> Intermediary >>> A CoAP endpoint that acts both as a server and as a client towards an >>> origin server (possibly via further intermediaries). A common form of an >>> intermediary is a proxy; several classes of such proxies are discussed in >>> this specification. >>> Maybe the following modifications would make this clearer to the reader. >>> 3.1. Discovery >>> Before the CoAP-EAP exchange takes place, the EAP peer needs to discover >>> the EAP authenticator or the entity that will enable the CoAP-EAP exchange >>> (e.g.i.e., an intermediary proxy). >>> —- >>> 8.3. Allowing CoAP-EAP Traffic to Perform Authentication >>> Since CoAP is an application protocol, CoAP-EAP assumes certain IP >>> connectivity in the link between the EAP peer and the EAP authenticator to >>> run. This link MUST authorize exclusively unprotected IP traffic to be sent >>> between the EAP peer and the EAP authenticator during the authentication >>> with CoAP-EAP. Once the authentication is successful, the key material >>> generated by the EAP authentication (MSK) and any other traffic can be >>> authorized if it is protected. It is worth noting that if the EAP >>> authenticator is not in the same link as the EAP peer and an intermediate >>> entity (i.e.e.g., a CoAP proxy) helps with this process, this concept also >>> applies to the communication between the EAP peer and the intermediary. >>> —- >>> When the EAP peer intends to be admitted into the network, it would search >>> for an entity that offers the CoAP-EAP service, be it directly via the EAP >>> authenticator or through an intermediary (i.e.e.g., proxy). See Section 3.1. >>> — >>> If the EAP peer cannot connect to the EAP authenticator directly, the EAP >>> peer can follow the same process as that described in Section 3.6 to >>> perform the authentication (i.e., can connect via an intermediary entity >>> (e.g., proxy) that is already part of the network (already shares key >>> material and communicates through a secure channel with the authenticator) >>> and can aid in running CoAP-EAP). >>> — >>> When CoAP-EAP is completed and the OSCORE security association is >>> established with the EAP authenticator, the EAP peer receives the local >>> configuration parameters for the network (e.g., a network key) and can >>> configure a global IPv6 address. Moreover, there is no need for a CoAP >>> proxy an intermediary entity after a successful authentication. >>> >>> >>>> 11) <!-- [rfced] Section 3.1: This sentence does not parse. If neither >>>> suggestion below is correct, please clarify the meaning of "hence". >>>> >>>> Original: >>>> For >>>> example, on a 6LoWPAN network, the Border Router will typically act >>>> as the EAP authenticator hence, after receiving the Router >>>> Advertisement (RA) messages from the Border Router, the EAP peer may >>>> engage on the CoAP-EAP exchange. >>>> >>>> Suggestion #1: >>>> For >>>> example, in a 6LoWPAN network, the Border Router will henceforth >>>> typically act as the EAP authenticator. After receiving the Router >>>> Advertisement (RA) messages from the Border Router, the EAP peer may >>>> engage in the CoAP-EAP exchange. >>>> >>>> Suggestion #2: >>>> For >>>> example, in a 6LoWPAN network, the Border Router will typically act >>>> as the EAP authenticator. Hence, after receiving the Router >>>> Advertisement (RA) messages from the Border Router, the EAP peer may >>>> engage in the CoAP-EAP exchange. --> >>>> >>>> >>> [Authors] Suggestion #2 >>> >>> >>>> 12) <!-- [rfced] Section 3.2: Please confirm that the "Implementation >>>> notes" paragraph and bullet list should remain independent of Step 0 >>>> (i.e., should not be indented so that it is part of Step 0). We see >>>> "resource of a step of the authentication" in the text, which seems >>>> to indicate that this information applies to all steps and not just >>>> Step 0, but we would still like you to confirm that the current >>>> indentation levels are correct. >>>> >>>> Original: >>>> * Step 0. The EAP peer MUST start the CoAP-EAP process by sending a >>>> "POST /.well-known/coap-eap" request (trigger message). This >>>> message carries the 'No-Response' [RFC7967] CoAP option to avoid >>>> waiting for a response that is not needed. This is the only >>>> message where the EAP authenticator acts as a CoAP server and the >>>> EAP peer as a CoAP client. The message also includes a URI in the >>>> payload of the message to indicate the resource where the EAP >>>> authenticator MUST send the next message. The name of the >>>> resource is selected by the CoAP server. >>>> >>>> Implementation notes: When generating the URI for a resource of a >>>> step of the authentication, the resource could have the following >>>> format as an example "path/eap/counter", where: >>>> >>>> * "path" is some local path on the device to make the path unique. >>>> This could be omitted if desired. >>>> >>>> * "eap" is the name that indicates the URI is for the EAP peer. >>>> This has no meaning for the protocol but helps with debugging. >>>> >>>> * "counter' which is an incrementing unique number for every new EAP >>>> request. >>>> >>>> So, in Figure 3 for example, the URI for the first resource would be >>>> “a/eap/1" >>>> >>>> * Step 1. ... --> >>>> >>>> >>> [Authors] Yes, the "Implementation notes" paragraph and bullet list should >>> remain independent of Step 0 >>> >>> >>>> 13) <!-- [rfced] Section 3.2: Do "assigns" and "sends" refer to the >>>> EAP peer or the EAP peer state machine? If the suggested text is not >>>> correct, please provide clarifying text. >>>> >>>> Original (previous text is included for context): >>>> * Step 2. The EAP peer processes the POST message sending the EAP >>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>> an EAP response (EAP Resp/Id). Then, assigns a new resource to >>>> the ongoing authentication process (e.g., '/a/eap/2'), and deletes >>>> the previous one ('/a/eap/1'). Finally, sends a '2.01 Created' >>>> response with the new resource identifier in the Location-Path >>>> (and/or Location-Query) options for the next step. >>>> >>>> Suggested (guessing the EAP peer state machine): >>>> * Step 2. The EAP peer processes the POST message, sending the EAP >>>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>>> an EAP response (EAP Resp/Id). Then, the EAP peer state machine >>>> assigns a new resource to the ongoing authentication process >>>> (e.g., '/a/eap/2') and deletes the previous one ('/a/eap/1'). >>>> Finally, the EAP peer state machine sends a '2.01 Created' >>>> response with the new resource identifier in the Location-Path >>>> (and/or Location-Query) options for the next step. --> >>>> >>>> >>> [Authors] We believe the best way to specify this is to differentiate >>> between "EAP peer state machine" and the CoAP-EAP application of the EAP >>> peer. >>> The EAP peer state machine only deals with EAP messages. Processes EAP >>> requests and returns an EAP response. >>> With that, the CoAP-EAP application within the EAP peer takes control and >>> manages everything CoAP related. Assigns a new resource to the ongoing >>> authentication process (e.g., '/a/eap/2') and deletes the previous one >>> ('/a/eap/1') >>> So, a suggested new text. >>> Step 2. The EAP peer processes the POST message sending the EAP >>> request (EAP-Req/Id) to the EAP peer state machine, which returns >>> an EAP response (EAP Resp/Id). Then, the CoAP-EAP application >>> assigns a new resource to the ongoing authentication process >>> (e.g., '/a/eap/2'), and deletes the previous one ('/a/eap/1'). >>> Finally, sends a '2.01 Created'response with the new resource >>> identifier in the Location-Path (and/or Location-Query) options >>> for the next step. >>> >>> >>> >>>> 14) <!-- [rfced] Section 3.2: Please clarify the meaning of "response to >>>> carry the EAP response" in this sentence. >>>> >>>> Original: >>>> The EAP peer will use a response to carry the EAP response in the >>>> payload. --> >>>> >>>> >>> [Authors] The text should say: >>> The EAP peer will use a CoAP response to carry the EAP response in the >>> payload. >>> >>> >>>> 15) <!-- [rfced] Section 3.5: The second sentence was incomplete and >>>> difficult to follow. Per Sections 3.5.1 through 3.5.3, we updated >>>> this section as noted below. If this is incorrect, please clarify. >>>> >>>> Original: >>>> This section elaborates on how different errors are handled. From >>>> EAP authentication failure, a non-responsive endpoint lost messages, >>>> or an initial POST message arriving out of place. >>>> >>>> Currently: >>>> This section elaborates on how different errors are handled: EAP >>>> authentication failure (Section 3.5.1), a non-responsive endpoint >>>> (Section 3.5.2), and duplicated messages (Section 3.5.3). --> >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>> >>>> 16) <!-- [rfced] Section 3.5.2: We could not follow the meaning of this >>>> run-on sentence. If the suggested text is not correct, please >>>> provide clarifying text. >>>> >>>> Original: >>>> By default, CoAP-EAP adopts the >>>> value of EXCHANGE_LIFETIME as a timer in the EAP peer and >>>> Authenticator to remove the CoAP-EAP state if the authentication >>>> process has not progressed in that time, in consequence, it has not >>>> been completed. >>>> >>>> Suggested: >>>> By default, CoAP-EAP adopts the >>>> value of EXCHANGE_LIFETIME as a timer in the EAP peer and >>>> authenticator to remove the CoAP-EAP state if the authentication >>>> process has not progressed to completion during that time. --> >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>>> 17) <!-- [rfced] Section 3.5.3: Does "Step 0" here refer to Step 0 in >>>> Figure 3 or Step 0 in Figure 5? For ease of the reader, we suggest >>>> adding a citation for the appropriate figure. >>>> >>>> Original: >>>> The reception of the trigger message in Step 0 containing the URI >>>> /coap-eap needs some additional considerations, as the resource is >>>> always available in the EAP authenticator. --> >>>> >>>> >>> [Authors] This first instance of Step 0 is referring to the complete Flow >>> in Figure 3. >>> The last instance refers to Figure 5. >>> For clarity the text would be: >>> The reception of the trigger message (Step 0 in Figure 3) containing the >>> URI /coap-eap needs some additional considerations, as the resource is >>> always available in the EAP authenticator. >>> If a trigger message arrives at the EAP authenticator during an ongoing >>> authentication with the same EAP peer, the EAP authenticator MUST silently >>> discard this trigger message. >>> If an old "POST /.well-known/coap-eap" (Step 0 in Figure 5) arrives at the >>> EAP authenticator and there is no authentication ongoing, the EAP >>> authenticator may understand that a new authentication process is >>> requested. Consequently, the EAP authenticator will start a new EAP >>> authentication. However, if the EAP peer did not start any authentication >>> and therefore, it did not select any resource for the EAP authentication. >>> Thus, the EAP peer sends a '4.04 Not Found' in the response. >>> >>> >>>> 18) <!-- [rfced] Section 3.5.3: The "However, if ..." sentence is >>>> incomplete; it appears that some words are missing. Please clarify >>>> this text. >>>> >>>> Original (the previous and next sentences are included for context): >>>> Consequently, the EAP authenticator will start a new EAP >>>> authentication. However, if the EAP peer did not start any >>>> authentication and therefore, it did not select any resource for the >>>> EAP authentication. Thus, the EAP peer sends a '4.04 Not found' in >>>> the response (Figure 5). --> >>>> >>>> >>> [Authors] Maybe this is simpler, >>> “However, if the EAP peer did not start any authentication, it will send a >>> '4.04 Not found' in the response (Figure 5).” >>> >>>> 19) <!-- [rfced] Section 3.6: The following sentences do not parse. >>>> >>>> If the suggested text for the first sentence is not correct, please >>>> provide clarifying text. >>>> >>>> We cannot follow the meaning of the second sentence. Please clarify >>>> "the proxy will act as forward, and as reverse for the rest". >>>> >>>> Original (the first sentence is included for context): >>>> After that, in the >>>> remaining exchanges the roles are reversed, being the EAP peer, the >>>> CoAP server, and the EAP authenticator, the CoAP client. When using >>>> a proxy in the exchange, for message 0, the proxy will act as >>>> forward, and as reverse for the rest. >>>> >>>> Suggested (first sentence): >>>> In the remaining exchanges, the roles are reversed (i.e., the EAP >>>> peer acts as the CoAP server, and the EAP authenticator acts as the >>>> CoAP client). --> >>>> >>>> >>> [Authors] The text would be the following, hopefully it is clearer: >>> In the remaining exchanges, the roles are reversed (i.e., the EAP >>> peer acts as the CoAP server, and the EAP authenticator acts as the >>> CoAP client). When using a proxy in the exchange, for message 0 it will act >>> as a forward proxy, and as a reverse proxy for the rest. >>> >>>> 20) <!-- [rfced] Section 5: We found this sentence confusing, because >>>> the plural "Examples" is used but the text that follows shows an >>>> "either-or" relationship ("cipher suites that need to be negotiated >>>> or ..."). If the suggested text is not correct, please provide >>>> clarifying text. >>>> >>>> Original (the previous sentence is included for context): >>>> In the CoAP-EAP exchange, there is information that needs to be >>>> exchanged between the two entities. Examples of this information are >>>> the cipher suites that need to be negotiated or authorization >>>> information (Session-lifetime). >>>> >>>> Suggested: >>>> In the CoAP-EAP exchange, information needs to be exchanged between >>>> the two entities - for example, the cipher suites that need to be >>>> negotiated, or authorization information (Session-lifetime). --> >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>> >>>> 21) <!-- [rfced] Section 5: Per Figure 6, Table 4, and >>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/coap-eap/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4SyTyIVA$ >>>> >, we moved the RID-I item >>>> so that it is the third item (Label 3, per Figure 6, Table 4, and >>>> IANA) instead of the second; RID-C is now the second item. >>>> Please let us know any objections. >>>> >>>> Original: >>>> 2. RID-I: Is the Recipient ID of the EAP peer. The EAP >>>> authenticator uses this value as a Sender ID for its OSCORE >>>> Sender Context. The EAP peer uses this value as Recipient ID for >>>> its Recipient Context. >>>> >>>> 3. RID-C: Is the Recipient ID of the EAP authenticator. The EAP >>>> peer uses this value as a Sender ID for its OSCORE Sender >>>> Context. The EAP authenticator uses this value as Recipient ID >>>> for its Recipient Context. >>>> >>>> Currently: >>>> 2. RID-C: The Recipient ID of the EAP authenticator. The EAP peer >>>> uses this value as the Sender ID for its OSCORE Sender Context. >>>> The EAP authenticator uses this value as the Recipient ID for its >>>> Recipient Context. >>>> >>>> 3. RID-I: The Recipient ID of the EAP peer. The EAP authenticator >>>> uses this value as the Sender ID for its OSCORE Sender Context. >>>> The EAP peer uses this value as the Recipient ID for its >>>> Recipient Context. --> >>>> >>>> >>> [Authors] No objection. >>> >>> >>> >>>> 22) <!-- [rfced] Section 6.1: Does "Steps 1 and 2" here refer to >>>> Steps 1 and 2 in Figure 3 or Steps 1 and 2 in Figure 8? >>>> For ease of the reader, we suggest adding a citation for the >>>> appropriate figure. >>>> >>>> Original: >>>> OSCORE runs after the EAP authentication, using the cipher suite >>>> selected in the cipher suite negotiation (Steps 1 and 2). --> >>>> >>>> >>> [Authors] We refer to Figure 3 in the first instance. To Figure 8 in the >>> other instances in that section. Corrected text below: >>> OSCORE runs after the EAP authentication, using the cipher suite selected >>> in the cipher suite negotiation (Steps 1 and 2 in Figure 3). To negotiate >>> the cipher suite, CoAP-EAP follows a simple approach: The EAP authenticator >>> sends a list, in decreasing order of preference, with the identifiers of >>> the supported cipher suites (Step 1 in Figure 8). In the response to that >>> message (Step 2 in Figure 8), the EAP peer sends its choice. >>> >>> >>> >>>> 23) <!-- [rfced] Section 6.1: We had trouble following this sentence. >>>> If the suggested text is not correct, please clarify "where it can be >>>> appreciated the disposition". >>>> >>>> Original: >>>> An example of the exchange with the >>>> cipher suite negotiation is shown in Figure 8, where it can be >>>> appreciated the disposition of both EAP-Request/Identity and EAP- >>>> Response/Identity, followed by the CBOR object defined in Section 5, >>>> containing the cipher suite field for the cipher suite negotiation. >>>> >>>> Suggested: >>>> An example exchange for the >>>> cipher suite negotiation is shown in Figure 8. The >>>> EAP request (EAP-Request/Identity) and EAP response >>>> (EAP-Response/Identity) are sent; both messages include the CBOR >>>> object (Section 5) containing the cipher suite field for the cipher >>>> suite negotiation. --> >>>> >>>> >>> [Authors] The suggested text is ok >>> >>> >>> >>> >>>> 24) <!-- [rfced] Figure 7: We note that the ASCII art has two pipes (with >>>> "+" >>>> above each) between the "Data" and "cipher suites" fields, while the SVG >>>> has vertical lines along with curved lines that intersect each >>>> other. Please review and correct the edited copy of the XML if needed. >>>> --> >>>> >>>> >>> [Authors] We provided a new Figure in the xml attached file that hopefully >>> is much more clearer. >>> >>> >>>> 25) <!-- [rfced] Sections 6.1 and Appendix A: Do these algorithms need >>>> to be numbered? If yes, will this numbering scheme be clear to >>>> readers? >>>> >>>> Original: >>>> * 0) AES-CCM-16-64-128, SHA-256 (default) >>>> >>>> * 1) A128GCM, SHA-256 >>>> >>>> * 2) A256GCM, SHA-384 >>>> >>>> * 3) ChaCha20/Poly1305, SHA-256 >>>> >>>> * 4) ChaCha20/Poly1305, SHAKE256 >>>> ... >>>> * 5) TLS_SHA256 >>>> >>>> * 6) TLS_SHA384 >>>> >>>> * 7) TLS_SHA512 >>>> >>>> Perhaps: >>>> * AES-CCM-16-64-128, SHA-256 (default) >>>> >>>> * A128GCM, SHA-256 >>>> >>>> * A256GCM, SHA-384 >>>> >>>> * ChaCha20/Poly1305, SHA-256 >>>> >>>> * ChaCha20/Poly1305, SHAKE256 >>>> ... >>>> * TLS_SHA256 >>>> >>>> * TLS_SHA384 >>>> >>>> * TLS_SHA512 >>>> >>>> --> >>>> >>>> >>> [Authors] The numbers on Sections 6.1 match the values in “9.1. CoAP-EAP >>> Cipher Suites”. >>> The numbers in Appendix A are the expected continuation of these, but are >>> not in the specification, and not in the IANA section. This text should >>> also solve issue 42 as well. >>> Suggested update text: >>> The following hash algorithms are considered in case the specification >>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>> >>> >>>> 26) <!-- [rfced] Section 6.2: Does "Steps 7 and 8" here refer to >>>> Steps 7 and 8 in Figure 3? If yes, for ease of the reader we suggest >>>> adding a citation for Figure 3. >>>> >>>> Original: >>>> The derivation of the security context for OSCORE allows securing the >>>> communication between the EAP peer and the EAP authenticator once the >>>> MSK has been exported, providing confidentiality, integrity, key >>>> confirmation (Steps 7 and 8), and downgrading attack detection. --> >>>> >>>> >>> [Authors] Yes, we refer to Figure 3. >>> >>> >>>> 27) <!-- [rfced] Section 6.2: We clarified these sentences as noted >>>> below. If these updates are incorrect, please clarify "the cipher >>>> suite 0". >>>> >>>> Original: >>>> If CS-C or CS-I were not sent, (i.e., default algorithms are used) >>>> the value used to generate CS will be the same as if the default >>>> algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR >>>> array with the cipher suite 0). >>>> ... >>>> If CS-C or CS-I were not sent, (i.e., default algorithms are used) >>>> the value used to generate CS will be the same as if the default >>>> algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR >>>> array with the cipher suite 0). >>>> >>>> Currently: >>>> If neither CS-C nor CS-I was sent (i.e., default algorithms are >>>> used), the value used to generate CS will be the same as if the >>>> default algorithms were explicitly sent in CS-C or CS-I (i.e., a >>>> CBOR array with the cipher suite value of 0). >>>> ... >>>> If neither CS-C nor CS-I was sent (i.e., default algorithms are >>>> used), the value used to generate CS will be the same as if the >>>> default algorithms were explicitly sent in CS-C or CS-I (i.e., a >>>> CBOR array with the cipher suite value of 0). --> >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>> >>>> 28) <!-- [rfced] Please review instances of the term "NULL" as used in this >>>> document and let us know if any updates are needed. We believe that >>>> "NULL" should be updated to either "NUL" (that is, referring to the >>>> specific ASCII control code) or "null". --> >>>> >>>> >>> [Authors] We mean the same as the instance you can find in rfc5191 of PANA >>> page 16 >>> - "IETF PANA" is the ASCII code representation of the non-NULL terminated >>> string (excluding the double quotes around it). >>> >>> >>> >>>> 29) <!-- [rfced] Section 7.1: We changed this text as noted below. >>>> Please review carefully (including our expansion of "AVP" for ease of >>>> the reader), and let us know if anything is incorrect. >>>> >>>> Original: >>>> Note: When EAP >>>> is proxied over an AAA framework, the Access-Request packets in >>>> RADIUS MUST contain a Framed-MTU attribute with the value 1024, and >>>> the Framed-MTU AVP to 1024 in DIAMETER This attribute signals the AAA >>>> server that it should limit its responses to 1024 octets. >>>> >>>> Currently: >>>> Note: When EAP is proxied over a AAA framework, the >>>> Access-Request packets in RADIUS MUST contain a Framed-MTU >>>> attribute with a value of 1024 and, in Diameter, the Framed-MTU >>>> Attribute-Value Pair (AVP) with a value of 1024. This information >>>> signals the AAA server that it should limit its responses to 1024 >>>> octets. --> >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>> >>>> 30) <!-- [rfced] Section 7.2: This sentence is difficult to parse. If >>>> the suggested text is not correct, please rephrase "constrained >>>> devices and network scenarios" and "older versions with the goal of >>>> economization". >>>> >>>> Also, please review and let us know whether this "Note:" item that is >>>> set off in a separate paragraph should be in the <aside> element. >>>> <aside> is defined as "a container for content that is semantically >>>> less important or tangential to the content that surrounds it" >>>> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5DOBldVg$ >>>> ). >>>> >>>> Original: >>>> Note: For constrained devices and network scenarios, the use of the >>>> latest versions of EAP methods (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 >>>> [RFC9190]) is recommended in favor of older versions with the goal of >>>> economization, or EAP methods more adapted for IoT (e.g., EAP-NOOB >>>> [RFC9140], EAP-EDHOC [I-D.ietf-emu-eap-edhoc], etc.). >>>> >>>> Suggested: >>>> Note: To improve efficiency in environments with >>>> constrained devices and networks, the latest versions of EAP methods >>>> (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over >>>> older versions. EAP methods more adapted for IoT networks (e.g., >>>> EAP-NOOB [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also >>>> recommended. --> >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>> >>>> 31) <!-- [rfced] Section 8.2: This sentence did not parse. We updated >>>> it as noted below. If this update is incorrect, please clarify >>>> "can be with the transport of SAML". >>>> >>>> Original: >>>> Providing more fine-grained >>>> authorization data can be with the transport of SAML in RADIUS >>>> [RFC7833]. >>>> >>>> Currently: >>>> Providing more fine-grained >>>> authorization data can be done by transporting the data using the >>>> Security Assertion Markup Language (SAML) in RADIUS [RFC7833]. --> >>>> >>>> >>> [Authors] Currently suggested text is ok. >>> >>>> >>>> 32) <!-- [rfced] Section 8.3: >>>> >>>> a) To what does "exclusively" refer in this sentence? If the >>>> suggested text is not correct, please clarify. >>>> >>>> Original (the previous sentence is included for context): >>>> Since CoAP is an application protocol, CoAP-EAP assumes certain IP >>>> connectivity in the link between the EAP peer and the EAP >>>> authenticator to run. This link MUST authorize exclusively >>>> unprotected IP traffic to be sent between the EAP peer and the EAP >>>> authenticator during the authentication with CoAP-EAP. >>>> >>>> Suggested: >>>> This link MUST only authorize >>>> unprotected IP traffic to be sent between the EAP peer and the EAP >>>> authenticator during the authentication with CoAP-EAP. >>>> >>>> >>> [Authors] We mean that this link will only allow unprotected traffic >>> between the EAP peer and the EAP for the purpose of running CoAP-EAP. Any >>> other traffic should not be allowed. >>> >>> The suggested text is ok. >>> >>> >>> >>>> b) This sentence did not parse. We updated it to make a complete >>>> sentence. Please review this update carefully; if it is incorrect, >>>> please clarify. >>>> >>>> Original: >>>> It is worth noting that if the EAP authenticator is not >>>> in the same link as the EAP peer and an intermediate entity helps >>>> with this process (i.e., CoAP proxy) and the same comment applies to >>>> the communication between the EAP peer and the intermediary. >>>> >>>> Currently: >>>> It is worth noting that if the EAP authenticator is not >>>> in the same link as the EAP peer and an intermediate entity (i.e., a >>>> CoAP proxy) helps with this process, this concept also applies to the >>>> communication between the EAP peer and the intermediary. --> >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>>> 33) <!-- [rfced] Section 8.5: Does "the document" refer to RFC 6677 or >>>> this document? Also, how may we update "(To be assigned by IANA)"? >>>> >>>> Original (the previous paragraph is included for context): >>>> According to the [RFC6677], channel binding, related to EAP, is sent >>>> through the EAP method supporting it. >>>> >>>> To satisfy the requirements of the document, the EAP lower layer >>>> identifier (To be assigned by IANA) needs to be sent, in the EAP >>>> Lower-Layer Attribute if RADIUS is used. >>>> >>>> Perhaps: >>>> To satisfy the requirements of this document, the EAP lower-layer >>>> identifier for CoAP-EAP (10) needs to be sent, in the EAP >>>> Lower-Layer Attribute if RADIUS is used. >>>> >>>> Or: >>>> To satisfy the requirements of this document, the EAP lower-layer >>>> identifier assigned by IANA (see Section 9.4) needs to be sent, in the EAP >>>> Lower-Layer Attribute if RADIUS is used. >>>> --> >>>> >>>> >>> [Authors] We believe the first proposal is ok >>> To satisfy the requirements of this document, the EAP lower-layer >>> identifier for CoAP-EAP (10) needs to be sent, in the EAP >>> Lower-Layer Attribute if RADIUS is used. >>> >>> >>> >>> >>>> 34) <!-- [rfced] Section 8.6: Does "Step 0" here refer to Step 0 in >>>> Figure 3 or Step 0 in Figure 5? For ease of the reader, we suggest >>>> adding a citation for the appropriate figure. >>>> >>>> Original: >>>> For instance, an attacker can forge >>>> multiple initial messages to start an authentication (Step 0) with >>>> the EAP authenticator as if they were sent by different EAP peers. --> >>>> >>>> >>> [Authors] we refer to Figure 3. >>> >>> >>> >>>> 35) <!-- [rfced] Sections 9.1 and 9.2: The name "CoAP-EAP protocol" for >>>> the new >>>> registry group reads oddly, as it means "Constrained Application >>>> Protocol-Extensible Authentication Protocol protocol". May we change the >>>> name of the new registry group to "CoAP-EAP"? >>>> >>>> If yes, we will ask IANA to update the registry group name on >>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/coap-eap/coap-eap.xhtml__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6tPX02Xg$ >>>> >. >>>> (We could not find an existing IANA registry with the name "CoAP-EAP", >>>> so this name would be unique (but we would confirm this with IANA).) >>>> >>>> Original: >>>> IANA has created a new registry titled "CoAP-EAP Cipher Suites" under >>>> the new group name "CoAP-EAP protocol". >>>> ... >>>> IANA has created a new registry titled "CoAP-EAP Information element" >>>> under the new group name "CoAP-EAP protocol". --> >>>> >>>> >>> [Authors] The suggested changes are ok for us. >>> >>> >>> >>>> 36) <!-- [rfced] Section 9.2: Because there is no "Value" entity in the >>>> "CoAP-EAP Information Elements" registry, we changed "Value" to >>>> "Label" per >>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/coap-eap/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4SyTyIVA$ >>>> >. If this is >>>> incorrect, please clarify the list of columns in the "CoAP-EAP >>>> Information Elements" registry. >>>> >>>> Original: >>>> The columns of the registry are Name, Label, CBOR Type, Description >>>> and Reference, where Value is an integer, and the other columns are >>>> text strings. >>>> >>>> Currently: >>>> The columns of the registry are Name, Label, CBOR Type, Description, >>>> and Reference, where Label is an integer and the other columns are >>>> text strings. --> >>>> >>>> >>> [Authors] The proposed text is correct. >>> >>> >>> >>>> 37) <!-- [rfced] [TS133.501]: We found a more recent version of this >>>> specification. Because it appears that EAP will continue to be >>>> mentioned in subsequent versions of this paper, may we update this >>>> listing as follows? >>>> >>>> Original: >>>> [TS133.501] >>>> ETSI, "5G; Security architecture and procedures for 5G >>>> System - TS 133 501 V15.2.0 (2018-10)", 2018. >>>> >>>> Suggested: >>>> [TS133.501] >>>> ETSI, "5G; Security architecture and procedures for 5G >>>> System - TS 133 501 V18.9.0", April 2025, >>>> https://urldefense.com/v3/__https://www.etsi.org/deliver/etsi_ts/133500_133599/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH47PGG_Jw$ >>>> 133501/18.09.00_60/ts_133501v180900p.pdf --> >>>> >>>> >>>> >>> [Authors] The suggestion is ok and very welcome. Thank you. >>> >>> >>> >>>> 38) <!-- [rfced] [ZigbeeIP]: We could not find this document number. >>>> We also found that >>>> <https://urldefense.com/v3/__https://www.zigbee.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4xoZxesQ$ >>>> > steers to >>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>> >. When we searched >>>> <https://urldefense.com/v3/__https://csa-iot.org/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5J3ax9bw$ >>>> > for >>>> the number 095023r34, the result was "Nothing found, please try >>>> adjusting your search." >>>> >>>> Should a different paper be listed here and cited in Appendices B and >>>> C.5.1? >>>> >>>> Original: >>>> [ZigbeeIP] Zigbee Alliance, "ZigBee IP Specification (Zigbee Document >>>> 095023r34)", 2014. --> >>>> >>>> >>>> >>> [Authors] Certainly, this seems to be an old reference. We have other >>> examples, the best course of action would be to remove this reference and >>> the associated text. >>> Forced removal can be done by sending new specific key material to the >>> devices that still belong to the network, excluding the removed device, >>> following a model similar to CoJP for 6TiSCH [RFC9031] or Zigbee IP >>> [ZigbeeIP]. >>> – >>> Another example would be when a shared Network Key is required by the >>> devices that join a network. An example of this Network Key can be found in >>> Zigbee IP [ZigbeeIP] or the THREAD protocol [THREAD]. >>> >>> >>> >>> >>>> 39) <!-- [rfced] We found a newer version (1.4.0) of the Thread >>>> specification. As the citation in Appendix B is general in nature, >>>> may we update this listing as suggested below? >>>> >>>> Original: >>>> [THREAD] Thread Group, "Thread specification 1.3", 2023. >>>> >>>> Suggested: >>>> [THREAD] Kumar, S. and E. Dijk, "Thread 1.4 Features White Paper", >>>> September 2024, >>>> <https://urldefense.com/v3/__https://www.threadgroup.org/Portals/0/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7aZUQuhA$ >>>> Documents/ >>>> Thread_1.4_Features_White_Paper_September_2024.pdf>. --> >>>> >>>> >>>> >>> [Authors] The suggestion is ok and welcome. Thank you. >>> >>> >>> >>>> 40) <!-- [rfced] Figure 9: >>>> >>>> a) Please note that we changed "hanshake" to "handshake". However, >>>> in the HTML and PDF output files, the space after the "e" in >>>> "hanshake" was removed in the process. We cannot determine where in >>>> the SVG a coordinate should be modified to correct the spacing. >>>> Please correct the SVG in the edited copy of the XML. >>>> >>>> b) We see "down" arrows between MSK and DTLS_PSK in the ASCII art >>>> for this figure, but they do not appear in the SVG. If you would >>>> like to add the arrows in the SVG, please correct the SVG in the >>>> edited copy of the XML. >>>> >>>> c) We see "(Protected with (D)TLS)" in the ASCII art but >>>> "Protected with (D)TLS" in the SVG. If you prefer the parentheses, >>>> please correct the SVG in the edited copy of the XML. If you prefer >>>> that the parentheses be removed, let us know, and we will update the >>>> ASCII art accordingly. --> >>>> >>>> >>> [Authors] New figure in rfc9820_modified.xml solves these issues. >>> Also, for consistency, in Figure 3 there were no arrows indicating key >>> derivation, we also updated that Figure in the xml file. >>> >>> >>> >>>> 41) <!-- [rfced] Appendix A: >>>> >>>> a) As it appears that "Steps 1 and 2" here refer to Steps 1 and 2 in >>>> Figure 8 (as opposed to Steps 1 and 2 in Figure 3), may we add a >>>> citation for Figure 8 for ease of the reader? >>>> >>>> If the suggested text is not correct, please also clarify "if DTLS >>>> wants to be used". >>>> >>>> Original: >>>> To simplify the design in CoAP-EAP, the KDF hash algorithm >>>> can be included in the list of cipher suites exchanged in Step 1 and >>>> Step 2 if DTLS wants to be used instead of OSCORE. >>>> >>>> Suggested: >>>> To simplify the design in CoAP-EAP, the KDF hash algorithm >>>> can be included in the list of cipher suites exchanged in Steps 1 and >>>> 2 (Figure 8) if one wants to use DTLS instead of OSCORE. >>>> >>>> >>> [Authors] The suggested text is ok. >>> >>> >>> >>>> b) Should "(RID-C) (RID-I)" be "RID-C || RID-I" per Appendix A.1? >>>> >>>> Original: >>>> For the same >>>> reason, the PSK identity is derived from (RID-C) (RID-I) as defined >>>> in Appendix A.1. --> >>>> >>>> >>> [Authors] Yes, this is correct. "(RID-C) (RID-I)" should be "RID-C || RID-I" >>> >>> >>> >>>> 42) <!-- [rfced] Appendix A: Should "considered" be "supported" in this >>>> sentence, along the lines of "The other supported and negotiated >>>> cipher suites are the following" as seen in Section 6.1? >>>> >>>> Original: >>>> The hash algorithms considered are the following: >>>> >>>> * 5) TLS_SHA256 >>>> >>>> * 6) TLS_SHA384 >>>> >>>> * 7) TLS_SHA512 >>>> >>>> Possibly: >>>> The following hash algorithms are supported: >>>> >>>> * 5) TLS_SHA256 >>>> >>>> * 6) TLS_SHA384 >>>> >>>> * 7) TLS_SHA512 --> >>>> >>>> >>> [Authors] Following the previous issue (point 25) >>> Proposed text. >>> The following hash algorithms are considered in case the specification >>> includes DTLS support in the future (TLS_SHA256,TLS_SHA384,TLS_SHA512) >>> >>> >>> >>>> 43) <!-- [rfced] Appendix A.1: Because the other equations in this >>>> document don't end in periods, we removed the period from the end of >>>> this equation. Please let us know any concerns. >>>> >>>> Original: >>>> DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length). >>>> >>>> Currently: >>>> DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length) --> >>>> >>>> >>> [Authors] The current proposed correction is ok. >>> >>> >>> >>>> 44) <!-- [rfced] Appendix B: Because "PSK" stands for "Pre-Shared Key", >>>> should "a shared key PSK" be "a PSK"? >>>> >>>> Original: >>>> Similarly, to the example of Appendix A.1, where a shared key PSK for >>>> DTLS is derived, it is possible to provide key material to different >>>> link-layers after the CoAP-EAP authentication is complete. --> >>>> >>>> >>> [Authors] You are correct. "a shared key PSK" should be "a PSK" >>> >>> >>> >>>> 45) <!-- [rfced] Appendix B: This sentence was difficult to follow. >>>> We updated it as noted below. If this is incorrect, please clarify >>>> the text. >>>> >>>> Original: >>>> How a particular link-layer technology uses the MSK to derive further >>>> key material for protecting the link-layer or use the OSCORE >>>> protection to distribute key material is out of the scope of this >>>> document. >>>> >>>> Currently (changed "uses the MSK ... or use the OSCORE protection" to >>>> "uses the MSK ... or uses OSCORE protection"): >>>> How a particular link-layer technology uses the MSK to derive further >>>> key material for protecting the link layer or uses OSCORE protection >>>> to distribute key material is outside the scope of this document. --> >>>> >>>> >>> [Authors] The currently suggested text is ok. >>> >>> >>> >>>> 46) <!-- [rfced] Appendix C: "EAP peers (A and B), which are EAP peers. >>>> They are the EAP peers." appeared to be some unintentionally repeated >>>> text. We removed the extra text as noted below. If some additional >>>> information for this bullet item was intended (for example, as was >>>> done for the "EAP authenticator (C)" and "AAA server (AAA)" bullet >>>> items), please provide the information. >>>> >>>> Original: >>>> * 2 EAP peers (A and B), which are EAP peers. They are the EAP >>>> peers. >>>> >>>> Currently: >>>> * Two EAP peers (A and B). --> >>>> >>>> >>> [Authors] The currently suggested text is ok. >>> >>> >>> >>>> 47) <!-- [rfced] Appendix C: "the EAP authenticator acts as an EAP >>>> authenticator" read oddly and was difficult to follow. We updated >>>> this sentence as noted below. If this update is incorrect, please >>>> clarify the text. >>>> >>>> Original: >>>> Here, the EAP authenticator acts as an EAP authenticator in pass- >>>> through mode. >>>> >>>> Currently: >>>> Here, the EAP authenticator is operating in pass- >>>> through mode. --> >>>> >>>> >>> [Authors] The currently suggested text is ok. >>> >>> >>> >>>> 48) <!-- [rfced] Appendix C: This sentence did not parse. We updated it >>>> as noted below. If this is incorrect, please clarify "... methods >>>> might need to be used (...) being able to ...". >>>> >>>> Original: >>>> With varied EAP peers and >>>> networks, more lightweight authentication methods might need to be >>>> used (e.g., EAP-NOOB[RFC9140], EAP-AKA'[RFC5448], EAP-PSK[RFC4764], >>>> EAP-EDHOC[I-D.ietf-emu-eap-edhoc], etc.) being able to adapt to >>>> different types of devices according to organization policies or >>>> devices capabilities. >>>> >>>> Currently: >>>> With varied EAP peers and >>>> networks, authentication methods that are more lightweight (e.g., >>>> EAP-NOOB [RFC9140], EAP-AKA' [RFC5448], EAP-PSK [RFC4764], EAP-EDHOC >>>> [EAP-EDHOC], etc.) and are able to adapt to different types of >>>> devices according to organization policies or device capabilities >>>> might need to be used. --> >>>> >>>> >>> [Authors] The currently suggested text is ok. >>> >>> >>> >>> >>>> 49) <!-- [rfced] Appendix C.1: Does "while" in this sentence mean "at >>>> the same time as" or "as long as" (per the "as long as the key >>>> material is still valid" phrase in the "It is worth noting that the >>>> first phase ..." paragraph)? >>>> >>>> Original: >>>> This access can be repeated without contacting the EAP >>>> authenticator, while the credentials given to A are still valid. --> >>>> >>>> >>> [Authors] It means "as long as". >>> >>> >>> >>>> 50) <!-- [rfced] Appendix C.1: We had trouble following the meaning of >>>> "the first phase with CoAP-EAP". If the suggested text is not >>>> correct, please provide clarifying text. >>>> >>>> Original: >>>> It is worth noting that the first phase with CoAP-EAP is required to >>>> join the EAP authenticator C's domain. >>>> >>>> Suggested: >>>> It is worth noting that to join EAP authenticator C's domain, the >>>> first phase (authentication via CoAP-EAP) is required. --> >>>> >>>> >>>> >>> [Authors] The currently suggested text is ok. >>> >>> >>>> 51) <!-- [rfced] Appendix C.2: >>>> >>>> a) Should "AKA" be "AKA'", as used elsewhere in this document? >>>> >>>> Original: >>>> A device (A) of the domain acme.org, which uses a specific kind of >>>> credential (e.g., AKA) and intends to join the um.es domain. >>>> >>>> >>> [Authors] This clarification adds more confusion than without it. Please >>> leave it as follows >>> >>> A device (A) of the domain acme.org, which uses a specific kind of >>> credential (e.g., AKA) and intends to join the um.es domain. >>> >>> >>>> b) This sentence does not parse. It appears that some words are >>>> missing. Please clarify "Through the local AAA server communicate >>>> with the home AAA server ...". >>>> >>>> Original: >>>> Through the local AAA server >>>> communicate with the home AAA server to complete the authentication >>>> and integrate the device as a trustworthy entity into the domain of >>>> EAP authenticator C. --> >>>> >>>> >>> [Authors]The text hopefully is clearer as follows: >>> Then, the local AAA server communicates with the home AAA server to >>> complete the authentication. This way, the device can be considered as a >>> trustworthy entity within the domain of the EAP authenticator C >>> >>> >>> >>>> 52) <!-- [rfced] Appendix C.5.1: We corrected the incomplete >>>> "Where can ..." sentence as follows. If this change is not correct, >>>> please provide clarifying text. >>>> >>>> Original (the previous sentence is included for context): >>>> For >>>> example, in IEEE 802.15.4 networks, a new KMP ID can be defined to >>>> add such support in the case of IEEE 802.15.9 [ieee802159]. Where >>>> can be assumed that the device has at least a link-layer IPv6 >>>> address. >>>> >>>> Currently (now one sentence that includes the expansion for "KMP"): >>>> For >>>> example, in IEEE 802.15.4 networks, a new Key Management Protocol >>>> (KMP) ID can be defined to add such support in the case of IEEE >>>> 802.15.9 [IEEE802159], where it can be assumed that the device has at >>>> least a link-layer IPv6 address. --> >>>> >>>> >>> [Authors] The currently suggested text is ok. >>> >>> >>> >>>> 53) <!-- [rfced] Appendix C.5.1: Per the phrase "entity (proxy) that is >>>> already part of the network (already shares key material and >>>> communicates through a secure channel with the authenticator)" in the >>>> next paragraph of this section and per Figure 10, we updated this >>>> sentence accordingly. If this is incorrect, please clarify what >>>> communicates through a secure channel. >>>> >>>> Original: >>>> In the case a proxy participates in CoAP- >>>> EAP, it will be because it is already a trustworthy entity within the >>>> domain, which communicates through a secure channel with the EAP >>>> authenticator, as illustrated by Figure 10. >>>> >>>> Currently: >>>> In the case that a proxy participates in >>>> CoAP-EAP, it will be because it is already a trustworthy entity >>>> within the domain and communicates through a secure channel with the >>>> EAP authenticator, as illustrated by Figure 10. --> >>>> >>>> >>> [Authors] The currently suggested text is ok. >>> >>> >>> >>>> 54) <!-- [rfced] Appendix C.5.1: This paragraph had several issues: >>>> This section (Appendix C.5.1) cited itself, and in the second >>>> sentence, "As mentioned, either ..." was unclear. Also, the >>>> second sentence was incomplete. Please review all of our updates >>>> carefully, and let us know if anything is incorrect. >>>> >>>> (Side note: We cited Section 3.6 here because although Section 3.1 >>>> mentions both direct links and linking via a proxy, it doesn't >>>> provide any descriptive text.) >>>> >>>> Original: >>>> Thus, the EAP peer follows the same process described in >>>> Appendix C.5.1 to perform the authentication. As mentioned, either >>>> with a direct link to the EAP authenticator, or through an >>>> intermediary entity (proxy) that is already part of the network >>>> (already shares key material and communicates through a secure >>>> channel with the authenticator) and can aid in running CoAP-EAP. >>>> >>>> Currently (the direct connection is mentioned in the previous >>>> paragraph, so we did not mention it again here): >>>> If the EAP peer cannot connect to the EAP authenticator directly, >>>> the EAP peer can follow the same process as that described in >>>> Section 3.6 to perform the authentication (i.e., can connect via >>>> an intermediary entity (proxy) that is already part of the network >>>> (already shares key material and communicates through a secure >>>> channel with the authenticator) and can aid in running CoAP-EAP). --> >>>> >>>> >>> [Authors] The currently suggested text is ok. The only change would be to >>> set proxy as example. >>> … an intermediary entity (e.g., proxy) that is already part of the network >>> >>> >>> >>>> 55) <!-- [rfced] Figure 10: We see "(security association)" in the ASCII >>>> art but "security association" in the SVG. If you prefer the >>>> parentheses, please correct the SVG in the edited copy of the XML. >>>> If you prefer that the parentheses be removed, let us know, and we >>>> will update the ASCII art accordingly. --> >>>> >>>> >>> [Authors] it is ok without parenthesis. >>> >>> >>> >>>> 56) <!-- [rfced] Please review the "Inclusive Language" portion of >>>> the online Style Guide at >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7Wcxz1GQ$ >>>> >, >>>> and let us know if any changes are needed. Updates of this nature >>>> typically result in more precise language, which is helpful for >>>> readers. >>>> >>>> For example, please consider whether the following should be updated: >>>> Master Session Key, Master Secret, Master Salt, Master Key --> >>>> >>>> >>>> >>> [Authors] These are the same terms used in the EAP [RFC] standard and >>> OSCORE standard [RFC] from which this work depends. It is needed to >>> understand the terminology to which we refer. >>> >>> >>>> 57) <!-- [rfced] Please let us know if any changes are needed for the >>>> following: >>>> >>>> a) The following terms were used inconsistently in this document. >>>> We chose to use the latter forms. Please let us know any objections. >>>> >>>> AAA Server / AAA server (per post-6000 published RFCs) >>>> >>>> >>> [AUTHORS] AAA server >>> >>>> Client registration (in running text) / >>>> client registration (per RFC 9200) >>>> >>>> >>> [AUTHORS] client registration >>> >>>> b) The following terms appear to be used inconsistently in this >>>> document. Please let us know which form is preferred. >>>> >>>> "a/eap/1" (the URI for the first resource would be "a/eap/1") / >>>> '/a/eap/1' >>>> >>>> >>> [AUTHORS] "a/eap/1" >>> >>>> CBOR Object / CBOR object >>>> >>> [AUTHORS] CBOR Object >>> >>>> DTLS PSK / DTLS_PSK >>>> >>> [AUTHORS] DTLS_PSK >>> >>>> EAP Failure / EAP failure >>>> (will send an EAP Failure, sends an EAP failure) >>>> >>>> >>> [AUTHORS] EAP Failure >>> >>>> EAP-Request/Identity / EAP Req/Id / EAP-Req/Id >>>> >>>> >>> [AUTHORS] EAP-Request/Identity >>> >>> >>>> EAP response / EAP Response (used generally in text, e.g., >>>> "an EAP response", "an EAP Response") >>>> (We also see "EAP Response header" in Section 7.1.) >>>> >>>> >>> [AUTHORS] EAP Response >>> >>> >>> >>>> EAP-Response/Identity / EAP Resp/Id / EAP Response/Id >>>> >>>> >>> [AUTHORS] EAP-Response/Identity >>> >>> >>> >>>> EAP-X-Req (text) / EAP-X Req (Figure 3) >>>> >>>> >>> [AUTHORS] EAP-X-Req >>> We updated the figures so they are consistent >>> >>>> EAP-X-Resp (text) / EAP-X Resp (Figures 3 and 9) >>>> >>>> >>> [AUTHORS] EAP-X-Resp >>> >>> >>> >>>> Network Key / network key >>>> >>>> >>> [AUTHORS] Network Key >>> >>> >>> >>>> Option(s) / option(s) (e.g., "Location-Path Option", >>>> "Location-Path and/or Location-Query Options", >>>> "Location-Path or Location-Query options", >>>> "Location-Path (and/or Location-Query) Options", >>>> "Location-Path (and/or Location-Query) options") >>>> >>>> >>> [AUTHORS] Option(s) >>> >>>> OSCORE Security Context / OSCORE security context >>>> >>>> >>> [AUTHORS] OSCORE Security Context >>> >>> >>>> Session-Lifetime / Session-lifetime / Session Lifetime / >>>> session lifetime (in running text) >>>> (Figure 3 and Table 4 use "Session-Lifetime".) >>>> >>>> >>> [AUTHORS] Session-Lifetime >>> >>> >>> >>>> c) Should quoting and spacing be made consistent? For example: >>>> >>>> Quoting: '2.01 Created' / "2.01 Created" >>>> >>> [Authors] ‘2.01 Created’ >>> >>>> Spacing: Payload(EAP-X Resp) / Payload (EAP-X Resp) >>>> >>> [Authors] without spacing between be parenthesis >>> >>>> d) Should spacing after step numbers in figures be made >>>> consistent? For example: >>>> >>>> ... >>>> 0)| No-Response | >>>> ... (Figure 3) >>>> >>>> ... >>>> 0) | No-Response | >>>> ... (Figure 5) --> >>>> >>>> >>>> >>> [Authors] Without spacing is ok. >>> >>> >>>> Thank you. >>>> >>>> RFC Editor/lb/rv >>>> >>>> >>> Thank you very much. >>> >>> >>>> >>>> On Jul 18, 2025, at 10:46 AM, rfc-edi...@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/07/18 >>>> >>>> RFC Author(s): >>>> -------------- >>>> >>>> Instructions for Completing AUTH48 >>>> >>>> Your document has now entered AUTH48. Once it has been reviewed and >>>> approved by you and all coauthors, it will be published as an RFC. >>>> If an author is no longer available, there are several remedies >>>> available as listed in the FAQ >>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4mckAP4A$ >>>> ). >>>> >>>> You and you coauthors are responsible for engaging other parties >>>> (e.g., Contributors or Working Group) as necessary before providing >>>> your approval. >>>> >>>> Planning your review >>>> --------------------- >>>> >>>> Please review the following aspects of your document: >>>> >>>> * RFC Editor questions >>>> >>>> Please review and resolve any questions raised by the RFC Editor >>>> that have been included in the XML file as comments marked as >>>> follows: >>>> >>>> <!-- [rfced] ... --> >>>> >>>> These questions will also be sent in a subsequent email. >>>> >>>> * Changes submitted by coauthors >>>> >>>> Please ensure that you review any changes submitted by your >>>> coauthors. We assume that if you do not speak up that you >>>> agree to changes submitted by your coauthors. >>>> >>>> * Content >>>> >>>> Please review the full content of the document, as this cannot >>>> change once the RFC is published. Please pay particular attention to: >>>> - IANA considerations updates (if applicable) >>>> - contact information >>>> - references >>>> >>>> * Copyright notices and legends >>>> >>>> Please review the copyright notice and legends as defined in >>>> RFC 5378 and the Trust Legal Provisions >>>> (TLP – >>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5D1hB7LA$ >>>> ). >>>> >>>> * Semantic markup >>>> >>>> Please review the markup in the XML file to ensure that elements of >>>> content are correctly tagged. For example, ensure that <sourcecode> >>>> and <artwork> are set correctly. See details at >>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4qmIsbLQ$ >>>> >. >>>> >>>> * Formatted output >>>> >>>> Please review the PDF, HTML, and TXT files to ensure that the >>>> formatted output, as generated from the markup in the XML file, is >>>> reasonable. Please note that the TXT will have formatting >>>> limitations compared to the PDF and HTML. >>>> >>>> >>>> Submitting changes >>>> ------------------ >>>> >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> >>>> * your coauthors >>>> >>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>> >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH73FBctPw$ >>>> >>>> * The archive itself: >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH5RDfiTDg$ >>>> >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> >>>> You may submit your changes in one of two ways: >>>> >>>> An update to the provided XML file >>>> — OR — >>>> An explicit list of changes in this format >>>> >>>> Section # (or indicate Global) >>>> >>>> OLD: >>>> old text >>>> >>>> NEW: >>>> new text >>>> >>>> You do not need to reply with both an updated XML file and an explicit >>>> list of changes, as either form is sufficient. >>>> >>>> We will ask a stream manager to review and approve any changes that seem >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>> and technical changes. Information about stream managers can be found in >>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>> >>>> >>>> Approving for publication >>>> -------------------------- >>>> >>>> To approve your RFC for publication, please reply to this email stating >>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>> as all the parties CCed on this message need to see your approval. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.xml__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH61uj9KFA$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH46vzPMGQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.pdf__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH4VnhbREw$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820.txt__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH7CGA_kaw$ >>>> >>>> Diff file of the text: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-diff.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6IAS29qA$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6sl8fsTg$ >>>> (side by side) >>>> >>>> Diff of the XML: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH6VqyXnzw$ >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9820__;!!D9dNQwwGXtA!TbrbqBQ-ZV4q1lZ-2XZijFJaaOonPT3t5f_RiDDltidPVxX0OgC5zFBsKRUScKfq0HsVOUZdbzjVJ122AH41wCjt6w$ >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9820 (draft-ietf-ace-wg-coap-eap-15) >>>> >>>> Title : EAP-based Authentication Service for CoAP >>>> Author(s) : R. Marin-Lopez, D. Garcia-Carrillo >>>> WG Chair(s) : Loganaden Velvindron, Tim Hollebeek >>>> >>>> Area Director(s) : Deb Cooley, Paul Wouters >>>> >>>> >>>> >>>> >>> -- >>> Dan García Carrillo >>> --------------------- >>> Associate Professor >>> Dpto. de Informática, Área de Telemática, Universidad de Oviedo >>> Escuela Politécnica de Ingeniería, C.P. 33204, Campus de Viesques, Gijón >>> Dpcho. 2.7.8 - Edificio Polivalente >>> Tel.: +34 985182654 (Ext. 2654) | email: garcia...@uniovi.es >>> <rfc9820_modified.xml> >>> >> > -- > Dan García Carrillo > --------------------- > Associate Professor > Dpto. de Informática, Área de Telemática, Universidad de Oviedo > Escuela Politécnica de Ingeniería, C.P. 33204, Campus de Viesques, Gijón > Dpcho. 2.7.8 - Edificio Polivalente > Tel.: +34 985182654 (Ext. 2654) | email: garcia...@uniovi.es -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
