Dear RFC Editor, Great news. Thank you very much for the update.
Best regards, Dan. Enviado desde mi iPhone > El 31 jul 2025, a las 21:46, Lynne Bartholomew > <lbartholo...@staff.rfc-editor.org> 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 and Rafa, > > Just checking in to let you know that we are working through your replies > below and are most of the way through them. We plan to send you an email on > 4 August, with links to the latest files for your review. > > Thank you for your 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> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
