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>
