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
