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://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-wg-coap-eap-15 --> 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) --> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> 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. --> 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). --> 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. --> 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types> does not contain an applicable type, please let us know. Also, it is acceptable to leave the "type" attribute 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. --> 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. --> 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? --> 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. --> 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. ... --> 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. --> 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. --> 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). --> 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. --> 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. --> 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). --> 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). --> 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). --> 21) <!-- [rfced] Section 5: Per Figure 6, Table 4, and <https://www.iana.org/assignments/coap-eap/>, 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. --> 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). --> 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. --> 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. --> 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 --> 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. --> 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). --> 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". --> 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. --> 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://authors.ietf.org/en/rfcxml-vocabulary#aside). 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. --> 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]. --> 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. 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. --> 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. --> 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. --> 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://www.iana.org/assignments/coap-eap/coap-eap.xhtml>. (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". --> 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://www.iana.org/assignments/coap-eap/>. 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. --> 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://www.etsi.org/deliver/etsi_ts/133500_133599/ 133501/18.09.00_60/ts_133501v180900p.pdf --> 38) <!-- [rfced] [ZigbeeIP]: We could not find this document number. We also found that <https://www.zigbee.org/> steers to <https://csa-iot.org/>. When we searched <https://csa-iot.org/> 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. --> 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://www.threadgroup.org/Portals/0/ Documents/ Thread_1.4_Features_White_Paper_September_2024.pdf>. --> 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. --> 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. 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. --> 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 --> 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) --> 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. --> 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. --> 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). --> 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. --> 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. --> 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. --> 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. --> 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. 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. --> 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. --> 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. --> 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). --> 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. --> 56) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, 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 --> 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) Client registration (in running text) / client registration (per RFC 9200) 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' CBOR Object / CBOR object DTLS PSK / DTLS_PSK EAP Failure / EAP failure (will send an EAP Failure, sends an EAP failure) EAP-Request/Identity / EAP Req/Id / EAP-Req/Id 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.) EAP-Response/Identity / EAP Resp/Id / EAP Response/Id EAP-X-Req (text) / EAP-X Req (Figure 3) EAP-X-Resp (text) / EAP-X Resp (Figures 3 and 9) Network Key / 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") OSCORE Security Context / OSCORE security context Session-Lifetime / Session-lifetime / Session Lifetime / session lifetime (in running text) (Figure 3 and Table 4 use "Session-Lifetime".) c) Should quoting and spacing be made consistent? For example: Quoting: '2.01 Created' / "2.01 Created" Spacing: Payload(EAP-X Resp) / Payload (EAP-X Resp) d) Should spacing after step numbers in figures be made consistent? For example: ... 0)| No-Response | ... (Figure 3) ... 0) | No-Response | ... (Figure 5) --> Thank you. RFC Editor/lb/rv 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://www.rfc-editor.org/faq/). 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://trustee.ietf.org/license-info). * 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://authors.ietf.org/rfcxml-vocabulary>. * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * 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://www.rfc-editor.org/authors/rfc9820.xml https://www.rfc-editor.org/authors/rfc9820.html https://www.rfc-editor.org/authors/rfc9820.pdf https://www.rfc-editor.org/authors/rfc9820.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9820-diff.html https://www.rfc-editor.org/authors/rfc9820-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9820-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9820 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 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
