rfc9668v2.txt   rfc9668.txt 
skipping to change at line 162 skipping to change at line 162
The EDHOC protocol specified in [RFC9528] allows two peers to agree The EDHOC protocol specified in [RFC9528] allows two peers to agree
on a cryptographic secret in a mutually-authenticated way and on a cryptographic secret in a mutually-authenticated way and
achieves forward secrecy by using Diffie-Hellman ephemeral keys. The achieves forward secrecy by using Diffie-Hellman ephemeral keys. The
two peers are denoted as the "Initiator" and "Responder", as the one two peers are denoted as the "Initiator" and "Responder", as the one
sending or receiving the initial EDHOC message_1, respectively. sending or receiving the initial EDHOC message_1, respectively.
After successful processing of EDHOC message_3, both peers agree on a After successful processing of EDHOC message_3, both peers agree on a
cryptographic secret that can be used to derive further security cryptographic secret that can be used to derive further security
material and establish an OSCORE Security Context [RFC8613]. The material and establish an OSCORE Security Context [RFC8613]. The
Responder can also send an optional EDHOC message_4 to achieve key Responder can also send an optional EDHOC message_4 in order for the
confirmation, e.g., in deployments where no protected application Initiator to achieve key confirmation, e.g., in deployments where no
message is sent from the Responder to the Initiator. protected application message is sent from the Responder to the
Initiator.
Appendix A.2 of [RFC9528] specifies how to transfer EDHOC over CoAP. Appendix A.2 of [RFC9528] specifies how to transfer EDHOC over CoAP.
That is, the EDHOC data (i.e., the EDHOC message possibly with a That is, the EDHOC data (i.e., the EDHOC message possibly with a
prepended connection identifier) is transported in the payload of prepended connection identifier) is transported in the payload of
CoAP requests and responses. The default forward message flow of CoAP requests and responses. The default forward message flow of
EDHOC consists in the CoAP client acting as Initiator and the CoAP EDHOC consists in the CoAP client acting as Initiator and the CoAP
server acting as Responder (see Appendix A.2.1 of [RFC9528]). server acting as Responder (see Appendix A.2.1 of [RFC9528]).
Alternatively, the two roles can be reversed as per the reverse Alternatively, the two roles can be reversed as per the reverse
message flow of EDHOC (see Appendix A.2.2 of [RFC9528]). In the rest message flow of EDHOC (see Appendix A.2.2 of [RFC9528]). In the rest
of this document, EDHOC messages are considered to be transferred of this document, EDHOC messages are considered to be transferred
skipping to change at line 186 skipping to change at line 187
Figure 1 shows a successful execution of EDHOC, with a CoAP client Figure 1 shows a successful execution of EDHOC, with a CoAP client
and a CoAP server running EDHOC as Initiator and Responder, and a CoAP server running EDHOC as Initiator and Responder,
respectively. In particular, it extends Figure 10 from respectively. In particular, it extends Figure 10 from
Appendix A.2.1 of [RFC9528] by highlighting when the two peers Appendix A.2.1 of [RFC9528] by highlighting when the two peers
perform EDHOC verification and establish the OSCORE Security Context, perform EDHOC verification and establish the OSCORE Security Context,
and by adding an exchange of OSCORE-protected CoAP messages after and by adding an exchange of OSCORE-protected CoAP messages after
completing the EDHOC execution. completing the EDHOC execution.
That is, the client sends a POST request to a reserved EDHOC resource That is, the client sends a POST request to a reserved EDHOC resource
at the server by default at the Uri-Path "/.well-known/edhoc". The at the server, by default at the Uri-Path "/.well-known/edhoc". The
request payload consists of the CBOR simple value true (0xf5) request payload consists of the CBOR simple value true (0xf5)
concatenated with EDHOC message_1, which also includes the EDHOC concatenated with EDHOC message_1, which also includes the EDHOC
connection identifier C_I of the client encoded as per Section 3.3 of connection identifier C_I of the client encoded as per Section 3.3 of
[RFC9528]. The request has Content-Format application/cid- [RFC9528]. The request has Content-Format application/cid-
edhoc+cbor-seq. edhoc+cbor-seq.
This triggers the EDHOC execution at the server, which replies with a This triggers the EDHOC execution at the server, which replies with a
2.04 (Changed) response. The response payload consists of EDHOC 2.04 (Changed) response. The response payload consists of EDHOC
message_2, which also includes the EDHOC connection identifier C_R of message_2, which also includes the EDHOC connection identifier C_R of
the server encoded as per Section 3.3 of [RFC9528]. The response has the server encoded as per Section 3.3 of [RFC9528]. The response has
skipping to change at line 362 skipping to change at line 363
- C_R is the OSCORE Sender ID of the client; hence, it is - C_R is the OSCORE Sender ID of the client; hence, it is
transported in the 'kid' field of the OSCORE option (see transported in the 'kid' field of the OSCORE option (see
Section 6.1 of [RFC8613]). Unlike the sequential workflow Section 6.1 of [RFC8613]). Unlike the sequential workflow
shown in Figure 1, C_R is not transported in the payload of the shown in Figure 1, C_R is not transported in the payload of the
EDHOC + OSCORE request. EDHOC + OSCORE request.
- EDHOC message_3 is transported in the payload of the EDHOC + - EDHOC message_3 is transported in the payload of the EDHOC +
OSCORE request and prepended to the payload of the OSCORE OSCORE request and prepended to the payload of the OSCORE
Request. This is because EDHOC message_3 may be too large to Request. This is because EDHOC message_3 may be too large to
be included in a CoAP Option, e.g., when conveying a large be included in a CoAP option, e.g., when conveying a large
public key certificate chain such as ID_CRED_I (see public key certificate chain in the ID_CRED_I field (see
Section 3.5.3 of [RFC9528]), or when conveying large External Section 3.5.3 of [RFC9528]), or when conveying large External
Authorization Data such as EAD_3 (see Section 3.8 of Authorization Data in the EAD_3 field (see Section 3.8 of
[RFC9528]). [RFC9528]).
The rest of this section specifies how to transport the data in the The rest of this section specifies how to transport the data in the
EDHOC + OSCORE request and their processing order. In particular, EDHOC + OSCORE request and their processing order. In particular,
the use of this approach is explicitly signalled by including an the use of this approach is explicitly signalled by including an
EDHOC option (Section 3.1) in the EDHOC + OSCORE request. The EDHOC option (Section 3.1) in the EDHOC + OSCORE request. The
processing of the EDHOC + OSCORE request is specified in Section 3.2 processing of the EDHOC + OSCORE request is specified in Section 3.2
for the client side and in Section 3.3 for the server side. for the client side and in Section 3.3 for the server side.
3.1. EDHOC Option 3.1. EDHOC Option
This section defines the EDHOC option. This option is used in a CoAP This section defines the EDHOC option. This option is used in a CoAP
request to signal that the request payload conveys both an EDHOC request to signal that the request payload conveys both an EDHOC
message_3 and OSCORE-protected data: combined together. message_3 and OSCORE-protected data combined together.
The EDHOC option has the properties summarized in Table 1, which The EDHOC option has the properties summarized in Table 1, which
extends Table 4 of [RFC7252]. The option is Critical, Safe-to- extends Table 4 of [RFC7252]. The option is Critical, Safe-to-
Forward, and part of the Cache-Key. The option MUST occur at most Forward, and part of the Cache-Key. The option MUST occur at most
once and MUST be empty. If any value is sent, the recipient MUST once and MUST be empty. If any value is sent, the recipient MUST
ignore it. (Future documents may update the definition of the option ignore it. (Future documents may update the definition of the option
by expanding its semantics and specifying admitted values.) The by expanding its semantics and specifying admitted values.) The
option is intended only for CoAP requests and is of Class U for option is intended only for CoAP requests and is of Class U for
OSCORE [RFC8613]. OSCORE [RFC8613].
skipping to change at line 465 skipping to change at line 466
* OSCORE_PAYLOAD is the OSCORE ciphertext of the OSCORE- * OSCORE_PAYLOAD is the OSCORE ciphertext of the OSCORE-
protected CoAP request resulting from Step 2. protected CoAP request resulting from Step 2.
Step 4. Compose the EDHOC + OSCORE request, as the OSCORE-protected Step 4. Compose the EDHOC + OSCORE request, as the OSCORE-protected
CoAP request resulting from Step 2, where the payload is CoAP request resulting from Step 2, where the payload is
replaced with COMB_PAYLOAD built at Step 3. replaced with COMB_PAYLOAD built at Step 3.
Note that the new payload includes EDHOC message_3, but it Note that the new payload includes EDHOC message_3, but it
does not include the EDHOC connection identifier C_R. As does not include the EDHOC connection identifier C_R. As
the client is the EDHOC Initiator, C_R is the OSCORE Sender the client is the EDHOC Initiator, C_R is the OSCORE Sender
ID of the client, which is already specified as the 'kid' ID of the client, which is already specified as the value of
field in the OSCORE option of the request from Step 2; the 'kid' field in the OSCORE option of the request from
hence, C_R is specified as the 'kid' field of the EDHOC + Step 2; hence, C_R is specified as the value of the 'kid'
OSCORE request. field of the EDHOC + OSCORE request.
Step 5. Include the new EDHOC option defined in Section 3.1 into the Step 5. Include the new EDHOC option defined in Section 3.1 into the
EDHOC + OSCORE request. EDHOC + OSCORE request.
The application/cid-edhoc+cbor-seq media type does not apply The application/cid-edhoc+cbor-seq media type does not apply
to this message, whose media type is unnamed. to this message, whose media type is unnamed.
Step 6. Send the EDHOC + OSCORE request to the server. Step 6. Send the EDHOC + OSCORE request to the server.
With the same server, the client SHOULD NOT have multiple With the same server, the client SHOULD NOT have multiple
skipping to change at line 506 skipping to change at line 507
In such a case, the OSCORE processing in Step 2 of Section 3.2.1 is In such a case, the OSCORE processing in Step 2 of Section 3.2.1 is
performed on each inner block of the first CoAP application request. performed on each inner block of the first CoAP application request.
The following also applies. The following also applies.
* The client takes the following additional step between Steps 2 and * The client takes the following additional step between Steps 2 and
3 of Section 3.2.1. 3 of Section 3.2.1.
Step 2.1. If the OSCORE-protected request from Step 2 conveys a Step 2.1. If the OSCORE-protected request from Step 2 conveys a
non-first inner block of the first CoAP application non-first inner block of the first CoAP application
request (i.e., the Block1 Option processed at Step 2 had request (i.e., the Block1 option processed at Step 2 had
NUM different than 0), then the client skips the NUM different than 0), then the client skips the
following steps and sends the OSCORE-protected request following steps and sends the OSCORE-protected request
to the server. In particular, the client MUST NOT to the server. In particular, the client MUST NOT
include the EDHOC option in the OSCORE-protected include the EDHOC option in the OSCORE-protected
request. request.
* The client takes the following additional step between Steps 3 and * The client takes the following additional step between Steps 3 and
4 of Section 3.2.1. 4 of Section 3.2.1.
Step 3.1. If the size of COMB_PAYLOAD exceeds Step 3.1. If the size of COMB_PAYLOAD exceeds
skipping to change at line 666 skipping to change at line 667
This results in the following components shown in Figure 4: This results in the following components shown in Figure 4:
OSCORE option value: 0x090001 (3 bytes) OSCORE option value: 0x090001 (3 bytes)
EDHOC option value: - (0 bytes) EDHOC option value: - (0 bytes)
EDHOC message_3: 0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19 bytes) EDHOC message_3: 0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19 bytes)
OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes) OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)
0x44025d1f ; CoAP 4-byte header 0x44025d1f ; CoAP 4-byte Header
00003974 ; Token 00003974 ; Token
93 090001 ; OSCORE Option 93 090001 ; OSCORE Option
c0 ; EDHOC Option c0 ; EDHOC Option
ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf
612f1092f1776f1c1668b3825e 612f1092f1776f1c1668b3825e
(46 bytes) (46 bytes)
Figure 4: Example of a Protected CoAP Request Combining EDHOC and Figure 4: Example of a Protected CoAP Request Combining EDHOC and
OSCORE Data OSCORE Data
skipping to change at line 728 skipping to change at line 729
identifier, identifier,
* equal to the EDHOC connection identifier C_I specified in the * equal to the EDHOC connection identifier C_I specified in the
EDHOC message_1 of the present EDHOC session, or EDHOC message_1 of the present EDHOC session, or
* the Recipient ID in a current OSCORE Security Context where the ID * the Recipient ID in a current OSCORE Security Context where the ID
Context is not present. Context is not present.
The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE
Security Context. Note that, for a reason analogous to the one given Security Context. Note that, for a reason analogous to the one given
above with C_I, this allows the Initiator to always omit the 'kid in Section 4.1.1 with C_I, this allows the Initiator to always omit
context' in the OSCORE option of its messages sent to the Responder the 'kid context' in the OSCORE option of its messages sent to the
when protecting those with an OSCORE Security Context where C_R is Responder when protecting those with an OSCORE Security Context where
the Initiator's OSCORE Sender ID (see Section 6.1 of [RFC8613]). C_R is the Initiator's OSCORE Sender ID (see Section 6.1 of
[RFC8613]).
4.1.3. Initiator Processing of Message 2 4.1.3. Initiator Processing of Message 2
If the EDHOC connection identifier C_I is equal to the EDHOC If the EDHOC connection identifier C_I is equal to the EDHOC
connection identifier C_R specified in EDHOC message_2, then the connection identifier C_R specified in EDHOC message_2, then the
Initiator MUST abort the session and reply with an EDHOC error Initiator MUST abort the session and reply with an EDHOC error
message with error code 1 formatted as defined in Section 6.2 of message with error code 1 formatted as defined in Section 6.2 of
[RFC9528]. [RFC9528].
5. Extension and Consistency of Application Profiles 5. Extension and Consistency of Application Profiles
skipping to change at line 755 skipping to change at line 757
consistency rules. consistency rules.
If the server supports the EDHOC + OSCORE request within an EDHOC If the server supports the EDHOC + OSCORE request within an EDHOC
execution started at a certain EDHOC resource, then the application execution started at a certain EDHOC resource, then the application
profile associated with that resource SHOULD explicitly specify profile associated with that resource SHOULD explicitly specify
support for the EDHOC + OSCORE request. support for the EDHOC + OSCORE request.
In the case where the application profile indicates that the server In the case where the application profile indicates that the server
supports the optional EDHOC message_4 (see Section 5.5 of [RFC9528]), supports the optional EDHOC message_4 (see Section 5.5 of [RFC9528]),
it is still possible to use the optimized workflow based on the EDHOC it is still possible to use the optimized workflow based on the EDHOC
+ OSCORE request. However, this means the server is not going to + OSCORE request. However, this means that the server is not going
send EDHOC message_4 since it is not applicable to the optimized to send EDHOC message_4 since it is not applicable to the optimized
workflow (see Section 3.3.1). workflow (see Section 3.3.1).
Also, in the case where the application profile indicates that the Also, in the case where the application profile indicates that the
server shall send EDHOC message_4, the application profile MUST NOT server shall send EDHOC message_4, the application profile MUST NOT
specify support for the EDHOC + OSCORE request. There is no point specify support for the EDHOC + OSCORE request. There is no point
for the client to use the optimized workflow that is bound to fail for the client to use the optimized workflow that is bound to fail
(see Section 3.3.1). (see Section 3.3.1).
6. Web Linking 6. Web Linking
skipping to change at line 793 skipping to change at line 795
That is, while discovering an EDHOC resource, a client can That is, while discovering an EDHOC resource, a client can
contextually obtain relevant pieces of information from the contextually obtain relevant pieces of information from the
application profile associated with that resource. The resource application profile associated with that resource. The resource
discovery can occur by means of a direct interaction with the server discovery can occur by means of a direct interaction with the server
or by means of the CoRE Resource Directory [RFC9176] where the server or by means of the CoRE Resource Directory [RFC9176] where the server
may have registered the links to its resources. may have registered the links to its resources.
In order to enable the above, this section defines a number of In order to enable the above, this section defines a number of
parameters, each of which can be optionally specified as a target parameters, each of which can be optionally specified as a target
attribute with the same name in the link to the respective EDHOC attribute with the same name in the link to the respective EDHOC
resource or as filter criteria in a discovery request from the resource or as filter criterion in a discovery request from the
client. When specifying these parameters in a link to an EDHOC client. When specifying these parameters in a link to an EDHOC
resource, the target attribute rt="core.edhoc" MUST be included and resource, the target attribute rt="core.edhoc" MUST be included and
the same consistency rules defined in Section 5 for the corresponding the same consistency rules defined in Section 5 for the corresponding
information elements of an application profile MUST be followed. information elements of an application profile MUST be followed.
The following parameters are defined. The following parameters are defined.
'ed-i': If present, specifies that the server supports the EDHOC 'ed-i': If present, specifies that the server supports the EDHOC
Initiator role, hence the reverse message flow of EDHOC. A value Initiator role, hence the reverse message flow of EDHOC. A value
MUST NOT be given to this parameter and any present value MUST be MUST NOT be given to this parameter and any present value MUST be
skipping to change at line 843 skipping to change at line 845
server for identifying authentication credentials. This parameter server for identifying authentication credentials. This parameter
MUST specify a single value, which is taken from the 'Label' MUST specify a single value, which is taken from the 'Label'
column of the "COSE Header Parameters" registry column of the "COSE Header Parameters" registry
[COSE.Header.Parameters]. This parameter MAY occur multiple [COSE.Header.Parameters]. This parameter MAY occur multiple
times, with each occurrence specifying a type of identifier for times, with each occurrence specifying a type of identifier for
authentication credentials. authentication credentials.
Note that the values in the 'Label' column of the "COSE Header Note that the values in the 'Label' column of the "COSE Header
Parameters" registry are strongly typed. On the contrary, CoRE Parameters" registry are strongly typed. On the contrary, CoRE
Link Format is weakly typed; thus, it does not distinguish Link Format is weakly typed; thus, it does not distinguish
between, for instance, the string value -10 and the integer value between, for instance, the string value "-10" and the integer
-10. Therefore, if responses in CoRE Link Format are returned, value -10. Therefore, if responses in CoRE Link Format are
string values that look like an integer are not supported. Thus, returned, string values that look like an integer are not
such values MUST NOT be used in the 'ed-idcred-t' parameter. supported. Thus, such values MUST NOT be used in the 'ed-idcred-
t' parameter.
'ed-ead': Specifies the support of the server for an External 'ed-ead': Specifies the support of the server for an External
Authorization Data (EAD) item (see Section 3.8 of [RFC9528]). Authorization Data (EAD) item (see Section 3.8 of [RFC9528]).
This parameter MUST specify a single value, which is taken from This parameter MUST specify a single value, which is taken from
the 'Label' column of the "EDHOC External Authorization Data" the 'Label' column of the "EDHOC External Authorization Data"
registry defined in Section 10.5 of [RFC9528]. This parameter MAY registry defined in Section 10.5 of [RFC9528]. This parameter MAY
occur multiple times, with each occurrence specifying the occur multiple times, with each occurrence specifying the
'ead_label' of an EAD item that the server supports. ead_label of an EAD item that the server supports.
'ed-comb-req': If present, specifies that the server supports the 'ed-comb-req': If present, specifies that the server supports the
EDHOC + OSCORE request defined in Section 3. A value MUST NOT be EDHOC + OSCORE request defined in Section 3. A value MUST NOT be
given to this parameter and any present value MUST be ignored by given to this parameter and any present value MUST be ignored by
the recipient. the recipient.
Future documents may update the definition of the parameters 'ed-i', Future documents may update the definition of the parameters 'ed-i',
'ed-r', and 'ed-comb-req' by expanding their semantics and specifying 'ed-r', and 'ed-comb-req' by expanding their semantics and specifying
what they can take as value. what they can take as value.
skipping to change at line 876 skipping to change at line 879
resource at a server and obtains information elements from the resource at a server and obtains information elements from the
respective application profile. The CoRE Link Format notation from respective application profile. The CoRE Link Format notation from
Section 5 of [RFC6690] is used. Section 5 of [RFC6690] is used.
REQ: GET /.well-known/core REQ: GET /.well-known/core
RES: 2.05 Content RES: 2.05 Content
</sensors/temp>;osc, </sensors/temp>;osc,
</sensors/light>;if=sensor, </sensors/light>;if=sensor,
</.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2; </.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4; ed-method=0;ed-cred-t=0;ed-cred-t=1;ed-idcred-t=4;
ed-i;ed-r;ed-comb-req ed-i;ed-r;ed-comb-req
Figure 5: The Web Link Figure 5: The Web Link
7. Security Considerations 7. Security Considerations
The same security considerations from OSCORE [RFC8613] and EDHOC The same security considerations from OSCORE [RFC8613] and EDHOC
[RFC9528] hold for this document. In addition, the following [RFC9528] hold for this document. In addition, the following
considerations also apply. considerations apply.
Section 3.2.1 specifies that a client SHOULD NOT have multiple Section 3.2.1 specifies that a client SHOULD NOT have multiple
outstanding EDHOC + OSCORE requests pertaining to the same EDHOC outstanding EDHOC + OSCORE requests pertaining to the same EDHOC
session. Even if a client did not fulfill this requirement, it would session. Even if a client did not fulfill this requirement, it would
not have any impact in terms of security. That is, the server would not have any impact in terms of security. That is, the server would
still not process different instances of the same EDHOC message_3 still not process different instances of the same EDHOC message_3
more than once in the same EDHOC session (see Section 5.1 of more than once in the same EDHOC session (see Section 5.1 of
[RFC9528]) and would still enforce replay protection of the OSCORE- [RFC9528]) and would still enforce replay protection of the OSCORE-
protected request (see Sections 7.4 and 8.2 of [RFC8613]). protected request (see Sections 7.4 and 8.2 of [RFC8613]).
skipping to change at line 933 skipping to change at line 936
That is, the rebuilt OSCORE-protected application request from Step 7 That is, the rebuilt OSCORE-protected application request from Step 7
in Section 3.3.1 MUST undergo the same access-control checks that in Section 3.3.1 MUST undergo the same access-control checks that
would be performed on a traditional OSCORE-protected application would be performed on a traditional OSCORE-protected application
request sent individually as shown in Figure 1. request sent individually as shown in Figure 1.
To this end, validated information to perform access-control checks To this end, validated information to perform access-control checks
(e.g., an access token issued by a trusted party) has to be available (e.g., an access token issued by a trusted party) has to be available
at the server before starting to process the rebuilt OSCORE-protected at the server before starting to process the rebuilt OSCORE-protected
application request. Such information may have been provided to the application request. Such information may have been provided to the
server separately before starting the EDHOC execution altogether, or server separately before starting the EDHOC execution altogether, or
instead, as External Authorization Data during the EDHOC execution instead as External Authorization Data during the EDHOC execution
(see Section 3.8 of [RFC9528]). (see Section 3.8 of [RFC9528]).
Thus, a successful completion of the EDHOC protocol and the following Thus, a successful completion of the EDHOC protocol and the following
derivation of the OSCORE Security Context at the server do not play a derivation of the OSCORE Security Context at the server do not play a
role in determining whether the rebuilt OSCORE-protected request is role in determining whether the rebuilt OSCORE-protected request is
authorized to access the target protected resource at the server. authorized to access the target protected resource at the server.
8. IANA Considerations 8. IANA Considerations
This document has the following actions for IANA. This document has the following actions for IANA.
skipping to change at line 967 skipping to change at line 970
Table 2: Registration in Table 2: Registration in
the "CoAP Option Numbers" the "CoAP Option Numbers"
Registry Registry
8.2. Target Attributes Registry 8.2. Target Attributes Registry
IANA has registered the following entries in the "Target Attributes" IANA has registered the following entries in the "Target Attributes"
registry [CORE.Target.Attributes] within the "Constrained RESTful registry [CORE.Target.Attributes] within the "Constrained RESTful
Environments (CoRE) Parameters" registry group as per [RFC9423]. For Environments (CoRE) Parameters" registry group as per [RFC9423]. For
all entries, the Change Controller is "IETF" and the reference is all entries, the Change Controller is "IETF" and the reference is
"RFC 9668". "[RFC 9668]".
+================+=============================================+ +================+=============================================+
| Attribute Name | Brief Description | | Attribute Name | Brief Description |
+================+=============================================+ +================+=============================================+
| ed-i | Hint: support for the EDHOC Initiator role | | ed-i | Hint: support for the EDHOC Initiator role |
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
| ed-r | Hint: support for the EDHOC Responder role | | ed-r | Hint: support for the EDHOC Responder role |
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
| ed-method | A supported authentication method for EDHOC | | ed-method | A supported authentication method for EDHOC |
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
skipping to change at line 1001 skipping to change at line 1004
+----------------+---------------------------------------------+ +----------------+---------------------------------------------+
Table 3: Registrations in the "Target Attributes" Registry Table 3: Registrations in the "Target Attributes" Registry
8.3. EDHOC Authentication Credential Types Registry 8.3. EDHOC Authentication Credential Types Registry
IANA has created the "EDHOC Authentication Credential Types" registry IANA has created the "EDHOC Authentication Credential Types" registry
within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry
group defined in [RFC9528]. group defined in [RFC9528].
The registration policy is either "Standards Action with Expert The registration policy is either "Private Use", "Standards Action
Review" or "Specification Required" per [RFC8126]. "Expert Review" with Expert Review", or "Specification Required" per [RFC8126].
guidelines are provided in Section 8.4. "Expert Review" guidelines are provided in Section 8.4.
All assignments according to "Standards Action with Expert Review" All assignments according to "Standards Action with Expert Review"
are made on a "Standards Action" basis per Section 4.9 of [RFC8126] are made on a "Standards Action" basis per Section 4.9 of [RFC8126]
with "Expert Review" additionally required per Section 4.5 of with "Expert Review" additionally required per Section 4.5 of
[RFC8126]. The procedure for early IANA allocation of "standards [RFC8126]. The procedure for early IANA allocation of "standards
track code points" defined in [RFC7120] also applies. When such a track code points" defined in [RFC7120] also applies. When such a
procedure is used, review and approval by the designated expert are procedure is used, IANA will ask the designated expert(s) to approve
also required in order for the working group chairs to determine that the early allocation before registration. In addition, working group
the conditions for early allocation are met (see Step 2 in chairs are encouraged to consult the expert(s) early during the
Section 3.1 of [RFC7120]). process outlined in Section 3.1 of [RFC7120].
The columns of this registry are: The columns of this registry are:
Value: This field contains the value used to identify the type of Value: This field contains the value used to identify the type of
authentication credential. These values MUST be unique. The authentication credential. These values MUST be unique. The
value can be an unsigned integer or a negative integer. Different value can be an unsigned integer or a negative integer. Different
ranges of values use different registration policies: ranges of values use different registration policies:
* Integer values from -24 to 23 are designated as "Standards * Integer values from -24 to 23 are designated as "Standards
Action With Expert Review". Action With Expert Review".
skipping to change at line 1191 skipping to change at line 1194
Acknowledgments Acknowledgments
The authors sincerely thank Christian Amsüss, Emmanuel Baccelli, The authors sincerely thank Christian Amsüss, Emmanuel Baccelli,
Carsten Bormann, Roman Danyliw, Esko Dijk, Joel Halpern, Wes Carsten Bormann, Roman Danyliw, Esko Dijk, Joel Halpern, Wes
Hardaker, Klaus Hartke, John Preuß Mattsson, David Navarro, Shuping Hardaker, Klaus Hartke, John Preuß Mattsson, David Navarro, Shuping
Peng, Jim Schaad, Jürgen Schönwälder, John Scudder, Orie Steele, Peng, Jim Schaad, Jürgen Schönwälder, John Scudder, Orie Steele,
Gunter Van de Velde, Mališa Vučinić, and Paul Wouters for their Gunter Van de Velde, Mališa Vučinić, and Paul Wouters for their
feedback and comments. feedback and comments.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by the Sweden's
the Celtic-Next project CRITISEC and by the H2020 project SIFIS-Home Innovation Agency VINNOVA and the Celtic-Next project CRITISEC, and
(Grant agreement 952652). by the H2020 project SIFIS-Home (Grant agreement 952652).
Authors' Addresses Authors' Addresses
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
SE-164 40 Kista SE-164 40 Kista
Sweden Sweden
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
Marco Tiloca Marco Tiloca
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
SE-16440 Stockholm Kista SE-164 40 Kista
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
Rikard Höglund Rikard Höglund
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
SE-16440 Stockholm Kista SE-16440 Stockholm Kista
Sweden Sweden
Email: rikard.hoglund@ri.se Email: rikard.hoglund@ri.se
 End of changes. 21 change blocks. 
41 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.48.