- Copyright (c) 2023 IETF Trust and the persons identified as the + Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal @@ -1373,10 +1373,13 @@
C posts the access token to the /authz-info endpoint by using the mechanisms specified in Section 5.10 of [RFC9200]. If the access token is valid, RS responds to the request with a 2.01 (Created) response, after which C initiates the EDHOC protocol with RS. The communication with the /authz-info endpoint is not protected, except for the update of access rights (see Section 4.5).¶
C initiates the EDHOC protocol and includes the access token as External Authorization Data (EAD), see Section 3.8 of [I-D.ietf-lake-edhoc]. In this case, the access token is validated in parallel with the EDHOC session. This option cannot be used for the update of access rights.¶
+C initiates the EDHOC protocol and includes the access token as External Authorization Data (EAD), see Section 3.8 of [I-D.ietf-lake-edhoc]. In this case, the access token is validated in parallel with the EDHOC session. This option cannot be used for the update of access rights.¶
When running the EDHOC protocol, C uses the authentication credential of RS specified by AS together with the access token, while RS uses the authentication credential of C bound to and specified within the access token. If C and RS complete the EDHOC session successfully, they are mutually authenticated and they derive an OSCORE Security Context as per Appendix A.1 of [I-D.ietf-lake-edhoc]. Also, RS associates the two used authentication credentials and the completed EDHOC session with the derived Security Context. The latter is in turn associated with the access token and the access rights of C specified therein.¶
+When running the EDHOC protocol, C uses the authentication credential of RS specified by AS together with the access token, while RS uses the authentication credential of C bound to and specified within the access token. If C and RS complete the EDHOC session successfully, they are mutually authenticated and they derive an OSCORE Security Context as per Appendix A.1 of [I-D.ietf-lake-edhoc]. Also, RS associates the two used authentication credentials and the completed EDHOC session with the derived Security Context. The latter is in turn associated with the access token and the access rights of C specified therein.¶
From then on, C effectively gains authorized and secure access to protected resources on RS with the established OSCORE Security Context, for as long as the access token is valid. The Security Context is discarded when an access token (whether the same or a different one) is used to successfully derive a new Security Context for C.¶
After the whole procedure has completed and while the access token is valid, C can contact AS to request an update of its access rights, by sending a similar request to the /token endpoint. This request also includes an EDHOC session identifier (see Section 3.4), which allows AS to find the data it has previously shared with C. The session identifier is assigned by AS and used to identify a series of access tokens, called a "token series" (see Section 3.2). Upon a successful update of access rights (see Section 4.5), the new issued access token becomes the latest in its token series. When the latest access token of a token series becomes invalid (e.g., when it expires or gets revoked), that token series ends.¶
An overview of the profile flow for the "coap_edhoc_oscore" profile in case of option 1 above is given in Figure 1. The names of messages coincide with those of [RFC9200] when applicable.¶
@@ -1679,10 +1682,10 @@When issuing the first access token of a token series, AS MAY specify the following EDHOC_Information (see Section 3.4) in the claims associated with the access token. If these data are specified in the response to C from the /token endpoint, they MUST be included with the same values in the access token.¶
osc_ms_len: The size of the OSCORE Master Secret. If it is not included, the default value from Appendix A.1 of [I-D.ietf-lake-edhoc] is assumed.¶
+osc_ms_len: The size of the OSCORE Master Secret. If it is not included, the default value from Appendix A.1 of [I-D.ietf-lake-edhoc] is assumed.¶
osc_salt_len: The size of the OSCORE Master Salt. If it is not included, the default value from Appendix A.1 of [I-D.ietf-lake-edhoc] is assumed.¶
+osc_salt_len: The size of the OSCORE Master Salt. If it is not included, the default value from Appendix A.1 of [I-D.ietf-lake-edhoc] is assumed.¶
osc_version: The OSCORE version. If it is not included, the default value of 1 (see Section 5.4 of [RFC8613]) is assumed.¶
@@ -1754,53 +1757,55 @@EDHOC_Information is an object including information that guides two peers towards executing the EDHOC protocol. In particular, the EDHOC_Information is defined to be serialized and transported between nodes, as specified by this document, but it can also be used by other specifications if needed.¶
-The EDHOC_Information can either be encoded as a JSON object or as a CBOR map. The set of common fields that can appear in an EDHOC_Information can be found in the IANA "EDHOC Information" registry (see Section 10.9), defined for extensibility, and the initial set of parameters defined in this document is specified below. All parameters are optional.¶
+The EDHOC_Information can be encoded either as a JSON object or as a CBOR map. The set of common fields that can appear in an EDHOC_Information can be found in the IANA "EDHOC Information" registry (see Section 10.9), defined for extensibility, and the initial set of parameters defined in this document is specified below. All parameters are optional.¶
Figure 6 provides a summary of the EDHOC_Information parameters defined in this section.¶
-+---------------+--------------+------+----------+--------------------+ -| Name | CBOR value | CBOR | Registry | Description | -| | | Type | | | -+---------------+--------------+------+----------+--------------------+ -| session_id | bstr | 0 | | Identifier of | -| | | | | EDHOC session | -+---------------+--------------+------+----------+--------------------+ -| methods | int / | | EDHOC | Set of supported | -| | array of int | 1 | Method | EDHOC methods | -| | | | Type | | -| | | | Registry | | -+---------------+--------------+------+----------+--------------------+ -| cipher_suites | int / | | EDHOC | Set of supported | -| | array of int | 2 | Cipher | EDHOC cipher | -| | | | Suites | suites | -| | | | Registry | | -+---------------+--------------+------+----------+--------------------+ -| message_4 | simple value | | | Support for EDHOC | -| | "true" / | 3 | | message_4 | -| | simple value | | | | -| | "false" | | | | -+---------------+--------------+------+----------+--------------------+ -| comb_req | simple value | | | Support for the | -| | "true" / | 4 | | EDHOC + OSCORE | -| | simple value | | | combined request | -| | "false" | | | | -+---------------+--------------+------+----------+--------------------+ -| uri_path | tstr | 5 | | URI-path of the | -| | | | | EDHOC resource | -+---------------+--------------+------+----------+--------------------+ -| osc_ms_len | uint | | | Length in bytes of | -| | | 6 | | the OSCORE Master | -| | | | | Secret to derive | -+---------------+--------------+------+----------+--------------------+ -| osc_salt_len | uint | | | Length in bytes of | -| | | 7 | | the OSCORE Master | -| | | | | Salt to derive | -+---------------+--------------+------+----------+--------------------+ -| osc_version | uint | 8 | | OSCORE version | -| | | | | number to use | -+---------------+--------------+------+----------+--------------------+ ++---------------+-------+--------------+----------+------------------+ +| Name | CBOR | CBOR Type | Registry | Description | +| | label | | | | ++---------------+-------+--------------+----------+------------------+ +| session_id | 0 | bstr | | Identifier of | +| | | | | EDHOC session | ++---------------+-------+--------------+----------+------------------+ +| methods | 1 | int / | EDHOC | Set of supported | +| | | array of int | Method | EDHOC methods | +| | | | Type | | +| | | | Registry | | ++---------------+-------+--------------+----------+------------------+ +| cipher_suites | 2 | int / | EDHOC | Set of supported | +| | | array of int | Cipher | EDHOC cipher | +| | | | Suites | suites | +| | | | Registry | | ++---------------+-------+--------------+----------+------------------+ +| message_4 | 3 | simple value | | Support for | +| | | "true" / | | EDHOC message_4 | +| | | simple value | | | +| | | "false" | | | ++---------------+-------+--------------+----------+------------------+ +| comb_req | 4 | simple value | | Support for the | +| | | "true" / | | EDHOC + OSCORE | +| | | simple value | | combined request | +| | | "false" | | | ++---------------+-------+--------------+----------+------------------+ +| uri_path | 5 | tstr | | URI-path of the | +| | | | | EDHOC resource | ++---------------+-------+--------------+----------+------------------+ +| osc_ms_len | 6 | uint | | Length in bytes | +| | | | | of the OSCORE | +| | | | | Master Secret to | +| | | | | derive | ++---------------+-------+--------------+----------+------------------+ +| osc_salt_len | 7 | uint | | Length in bytes | +| | | | | of the OSCORE | +| | | | | Master Salt to | +| | | | | derive | ++---------------+-------+--------------+----------+------------------+ +| osc_version | 8 | uint | | OSCORE version | +| | | | | number to use | ++---------------+-------+--------------+----------+------------------+
session_id: This parameter identifies an EDHOC session and is encoded as a byte string. In JSON, the "session_id" value is a Base64 encoded byte string. In CBOR, the "session_id" type is a byte string, and has label 0.¶
methods: This parameter specifies a set of supported EDHOC methods (see Section 3.2 of [I-D.ietf-lake-edhoc]). If the set is composed of a single EDHOC method, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one EDHOC method. In JSON, the "methods" value is an integer or an array of integers. In CBOR, the "methods" is an integer or an array of integers, and has label 1.¶
+methods: This parameter specifies a set of supported EDHOC methods (see Section 3.2 of [I-D.ietf-lake-edhoc]). If the set is composed of a single EDHOC method, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one EDHOC method. In JSON, the "methods" value is an integer or an array of integers. In CBOR, the "methods" is an integer or an array of integers, and has label 1.¶
cipher_suites: This parameter specifies a set of supported EDHOC cipher suites (see Section 3.6 of [I-D.ietf-lake-edhoc]). If the set is composed of a single EDHOC cipher suite, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one EDHOC cipher suite. In JSON, the "cipher_suites" value is an integer or an array of integers. In CBOR, the "cipher_suites" is an integer or an array of integers, and has label 2.¶
+cipher_suites: This parameter specifies a set of supported EDHOC cipher suites (see Section 3.6 of [I-D.ietf-lake-edhoc]). If the set is composed of a single EDHOC cipher suite, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one EDHOC cipher suite. In JSON, the "cipher_suites" value is an integer or an array of integers. In CBOR, the "cipher_suites" is an integer or an array of integers, and has label 2.¶
message_4: This parameter indicates whether the EDHOC message_4 (see Section 5.5 of [I-D.ietf-lake-edhoc]) is supported. In JSON, the "message_4" value is a boolean. In CBOR, "message_4" is the simple value "true" or "false", and has label 4.¶
+message_4: This parameter indicates whether the EDHOC message_4 (see Section 5.5 of [I-D.ietf-lake-edhoc]) is supported. In JSON, the "message_4" value is a boolean. In CBOR, "message_4" is the simple value "true" or "false", and has label 4.¶
comb_req: This parameter indicates whether the combined EDHOC + OSCORE request defined in [I-D.ietf-core-oscore-edhoc]) is supported. In JSON, the "comb_req" value is a boolean. In CBOR, "comb_req" is the simple value "true" or "false", and has label 5.¶
@@ -1827,10 +1832,10 @@uri_path: This parameter specifies the path component of the URI of the EDHOC resource where EDHOC messages have to be sent as requests. In JSON, the "uri_path" value is a string. In CBOR, "uri_path" is a text string, and has label 6.¶
osc_ms_len: This parameter specifies the size in bytes of the OSCORE Master Secret to derive after the EDHOC session, as per Appendix A.1 of [I-D.ietf-lake-edhoc]. In JSON, the "osc_ms_len" value is an integer. In CBOR, the "osc_ms_len" type is unsigned integer, and has label 7.¶
+osc_ms_len: This parameter specifies the size in bytes of the OSCORE Master Secret to derive after the EDHOC session, as per Appendix A.1 of [I-D.ietf-lake-edhoc]. In JSON, the "osc_ms_len" value is an integer. In CBOR, the "osc_ms_len" type is unsigned integer, and has label 7.¶
osc_salt_len: This parameter specifies the size in bytes of the OSCORE Master Salt to derive after the EDHOC session, as per Appendix A.1 of [I-D.ietf-lake-edhoc]. In JSON, the "osc_salt_len" value is an integer. In CBOR, the "osc_salt_len" type is unsigned integer, and has label 8.¶
+osc_salt_len: This parameter specifies the size in bytes of the OSCORE Master Salt to derive after the EDHOC session, as per Appendix A.1 of [I-D.ietf-lake-edhoc]. In JSON, the "osc_salt_len" value is an integer. In CBOR, the "osc_salt_len" type is unsigned integer, and has label 8.¶
osc_version: This parameter specifies the OSCORE Version number that the two EDHOC peers have to use when using OSCORE. For more information about this parameter, see Section 5.4 of [RFC8613]. In JSON, the "osc_version" value is an integer. In CBOR, the "osc_version" type is unsigned integer, and has label 9.¶
@@ -1881,7 +1886,7 @@This section describes the exchanges between C and RS, which comprise the token uploading to RS, and the execution of the EDHOC protocol. Note that AS may have uploaded the access token directly to RS (see Section 3.3).¶
In order to upload the access token to RS, C can send a POST request to the /authz-info endpoint at RS. This is detailed in Section 4.1 and Section 4.2, and shown by the example in Appendix A.1.¶
Alternatively, C can upload the access token while executing the EDHOC protocol, by transporting the access token in an EAD field of an EDHOC message sent to RS. This is further discussed in Section 4.3 and Section 4.4, and shown by the example in Appendix A.2.¶
-In either case, C and RS run the EDHOC protocol by exchanging POST requests and related responses to a dedicated EDHOC resource at RS (see Section 4.4). Once completed the EDHOC session, C and RS have agreed on a common secret key PRK_out (see Section 4.1.3 of [I-D.ietf-lake-edhoc]), from which they establish an OSCORE Security Context (see Section 4.4). After that, C and RS use the established OSCORE Security Context to protect their communications when accessing protected resources at RS, as per the access rights specified in the access token (see Section 4.8).¶
+In either case, C and RS run the EDHOC protocol by exchanging POST requests and related responses to a dedicated EDHOC resource at RS (see Section 4.4). Once completed the EDHOC session, C and RS have agreed on a common secret key PRK_out (see Section 4.1.3 of [I-D.ietf-lake-edhoc]), from which they establish an OSCORE Security Context (see Section 4.4). After that, C and RS use the established OSCORE Security Context to protect their communications when accessing protected resources at RS, as per the access rights specified in the access token (see Section 4.8).¶
C and RS are mutually authenticated once they have successfully completed the EDHOC protocol. RS gets key confirmation of PRK_out by C at the end of the successful EDHOC session. Conversely, C get key confirmation of PRK_out by RS either when receiving and successfully verifying the optional EDHOC message_4 from RS, or when successfully verifying a response from RS protected with the generated OSCORE Security Context.¶
Instead of uploading the access token to the /authz-info endpoint at RS as described in Section 4.1, C MAY include the access token either in EDHOC message_1 or message_3 by making use of the External Authorization Data fields (see Section 3.8 of [I-D.ietf-lake-edhoc]). The former is shown by the example in Appendix A.2. In the latter case, the access token is encrypted between C and RS, which provides an alternative for protecting potential sensitive information in the access token.¶
+Instead of uploading the access token to the /authz-info endpoint at RS as described in Section 4.1, C MAY include the access token either in EDHOC message_1 or message_3 by making use of the External Authorization Data fields (see Section 3.8 of [I-D.ietf-lake-edhoc]). The former is shown by the example in Appendix A.2. In the latter case, the access token is encrypted between C and RS, which provides an alternative for protecting potential sensitive information in the access token.¶
Editor's note: Shall we remove the EAD_1 case? The case POST /token offers already early abort, and the EAD_3 case is equally efficient but offers better protection of the access token.¶
This document defines the EAD item EAD_ACCESS_TOKEN = (ead_label, ead_value), where:¶
ead_value is a CBOR byte string equal to the value of the "access_token" field of the access token response from AS (see Section 3.3).¶
This EAD item, which may be used either in EAD_1 or EAD_3, is critical, i.e., it is used only with the negative value of its ead_label, indicating that the receiving RS must either process the access token or abort the EDHOC session (see Section 3.8 of [I-D.ietf-lake-edhoc]).¶
+This EAD item, which may be used either in EAD_1 or EAD_3, is critical, i.e., it is used only with the negative value of its ead_label, indicating that the receiving RS must either process the access token or abort the EDHOC session (see Section 3.8 of [I-D.ietf-lake-edhoc]).¶
Access tokens are only transported in EAD fields for the first access token of a token series and not for the update of access rights.¶
In order to mutually authenticate and establish a secure association, C and RS run the EDHOC protocol [I-D.ietf-lake-edhoc] with C as EDHOC Initiator and RS as EDHOC Responder.¶
-As per Appendix A.2 of [I-D.ietf-lake-edhoc], C sends EDHOC message_1 and EDHOC message_3 to an EDHOC resource at RS, as CoAP POST requests. RS sends EDHOC message_2 and (optionally) EDHOC message_4 as 2.04 (Changed) CoAP responses. C MUST target the EDHOC resource at RS with the URI path specified in the "uri_path" field of the EDHOC_Information in the access token response received from AS (see Section 3.1), if present.¶
+As per Appendix A.2 of [I-D.ietf-lake-edhoc], C sends EDHOC message_1 and EDHOC message_3 to an EDHOC resource at RS, as CoAP POST requests. RS sends EDHOC message_2 and (optionally) EDHOC message_4 as 2.04 (Changed) CoAP responses. C MUST target the EDHOC resource at RS with the URI path specified in the "uri_path" field of the EDHOC_Information in the access token response received from AS (see Section 3.1), if present.¶
In order to seamlessly run EDHOC, a client does not have to first upload to RS an access token whose scope explicitly indicates authorized access to the EDHOC resource. At the same time, RS has to ensure that attackers cannot perform requests on the EDHOC resource, other than sending EDHOC messages. Specifically, it SHOULD NOT be possible to perform anything else than POST on an EDHOC resource.¶
The processing of EDHOC message_1 is specified in Section 5.2 of [I-D.ietf-lake-edhoc]. Additionally, the following applies:¶
+The processing of EDHOC message_1 is specified in Section 5.2 of [I-D.ietf-lake-edhoc]. Additionally, the following applies:¶
The EDHOC method MUST be one of the EDHOC methods specified in the "methods" field (if present) in the EDHOC_Information of the access token response to C.¶
@@ -1949,7 +1954,7 @@The selected cipher suite MUST be an EDHOC cipher suite specified in the "cipher_suites" field (if present) in the EDHOC_Information of the access token response to C.¶
If the access token is provisioned with EDHOC message_1 as specified in Section 4.3, then C adds the EAD item EAD_ACCESS_TOKEN = (-ead_label, ead_value) to the EAD_1 field. If EAD_1 includes EAD_ACCESS_TOKEN, then RS MUST process the access token carried in ead_value as specified in Section 4.2. If this processing fails, RS MUST reply to C with an EDHOC error message with ERR_CODE 1 (see Section 6 of [I-D.ietf-lake-edhoc]), and it MUST abort the EDHOC session. RS MUST have successfully completed the processing of the access token before continuing the EDHOC session by sending EDHOC message_2.¶
+If the access token is provisioned with EDHOC message_1 as specified in Section 4.3, then C adds the EAD item EAD_ACCESS_TOKEN = (-ead_label, ead_value) to the EAD_1 field. If EAD_1 includes EAD_ACCESS_TOKEN, then RS MUST process the access token carried in ead_value as specified in Section 4.2. If this processing fails, RS MUST reply to C with an EDHOC error message with ERR_CODE 1 (see Section 6 of [I-D.ietf-lake-edhoc]), and it MUST abort the EDHOC session. RS MUST have successfully completed the processing of the access token before continuing the EDHOC session by sending EDHOC message_2.¶
The processing of EDHOC message_2 is specified in Section 5.3 of [I-D.ietf-lake-edhoc] with the following additions:¶
+The processing of EDHOC message_2 is specified in Section 5.3 of [I-D.ietf-lake-edhoc] with the following additions:¶
The authentication credential CRED_R indicated by the message field ID_CRED_R is AUTH_CRED_RS.¶
@@ -1972,13 +1977,13 @@The processing of EDHOC message_3 is specified in Section 5.4 of [I-D.ietf-lake-edhoc] with the following additions:¶
+The processing of EDHOC message_3 is specified in Section 5.4 of [I-D.ietf-lake-edhoc] with the following additions:¶
The authentication credential CRED_I indicated by the message field ID_CRED_I is AUTH_CRED_C.¶
If the access token is provisioned with EDHOC message_3 as specified in Section 4.3, then C adds the EAD item EAD_ACCESS_TOKEN = (-ead_label, ead_value) to the EAD_3 field. If EAD_3 includes EAD_ACCESS_TOKEN, then RS MUST process the access token carried in ead_value as specified in Section 4.2. If such a process fails, RS MUST reply to C with an EDHOC error message with ERR_CODE 1 (see Section 6 of [I-D.ietf-lake-edhoc]), and it MUST abort the EDHOC session. RS MUST have successfully completed the processing of the access token before completing the EDHOC session.¶
+If the access token is provisioned with EDHOC message_3 as specified in Section 4.3, then C adds the EAD item EAD_ACCESS_TOKEN = (-ead_label, ead_value) to the EAD_3 field. If EAD_3 includes EAD_ACCESS_TOKEN, then RS MUST process the access token carried in ead_value as specified in Section 4.2. If such a process fails, RS MUST reply to C with an EDHOC error message with ERR_CODE 1 (see Section 6 of [I-D.ietf-lake-edhoc]), and it MUST abort the EDHOC session. RS MUST have successfully completed the processing of the access token before completing the EDHOC session.¶
Once successfully completed the EDHOC session, C and RS derive an OSCORE Security Context, as defined in Appendix A.1 of [I-D.ietf-lake-edhoc]. In addition, the following applies.¶
+Once successfully completed the EDHOC session, C and RS derive an OSCORE Security Context, as defined in Appendix A.1 of [I-D.ietf-lake-edhoc]. In addition, the following applies.¶
The length in bytes of the OSCORE Master Secret (i.e., the oscore_key_length parameter, see Appendix A.1 of [I-D.ietf-lake-edhoc]) MUST be the value specified in the "osc_ms_size" field (if present) in the EDHOC_Information of the access token response to C, and of the access token provisioned to RS, respectively.¶
+The length in bytes of the OSCORE Master Secret (i.e., the oscore_key_length parameter, see Appendix A.1 of [I-D.ietf-lake-edhoc]) MUST be the value specified in the "osc_ms_size" field (if present) in the EDHOC_Information of the access token response to C, and of the access token provisioned to RS, respectively.¶
The length in bytes of the OSCORE Master Salt (i.e., the oscore_salt_length parameter, see Appendix A.1 of [I-D.ietf-lake-edhoc]) MUST be the value specified in the "osc_salt_size" field (if present) in the EDHOC_Information of the access token response to C, and of the access token provisioned to RS, respectively.¶
+The length in bytes of the OSCORE Master Salt (i.e., the oscore_salt_length parameter, see Appendix A.1 of [I-D.ietf-lake-edhoc]) MUST be the value specified in the "osc_salt_size" field (if present) in the EDHOC_Information of the access token response to C, and of the access token provisioned to RS, respectively.¶
C and RS MUST use the OSCORE version specified in the "osc_version" field (if present) in the EDHOC_Information of the access token response to C, and of the access token provisioned to RS, respectively.¶
@@ -2841,7 +2846,7 @@IANA is asked to add the following entry to the "EDHOC External Authorization Data" registry defined in Section 9.5 of [I-D.ietf-lake-edhoc].¶
+IANA is asked to add the following entry to the "EDHOC External Authorization Data" registry defined in Section 9.5 of [I-D.ietf-lake-edhoc].¶
The ead_label = TBD and the ead_value defines an access token in EAD_1 or EAD_3, with processing specified in Section 4.3.¶
CBOR Value: The value to be used as CBOR abbreviation of the item.¶
+CBOR label: The value to be used as CBOR abbreviation of the item.¶
The value MUST be unique. The value can be a positive integer, a negative integer or a string. Integer values between -256 and 255 and strings of length 1 are to be registered by Standards Track documents (Standards Action). Integer values from -65536 to -257 and from 256 to 65535 and strings of maximum length 2 are to be registered by public specifications (Specification Required). Integer values greater than 65535 and strings of length greater than 2 are subject to the Expert Review policy. Integer values less than -65536 are marked as private use.¶
CBOR Type: The CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.¶
+CBOR type: The CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.¶
Registry: The registry that values of the item may come from, if one exists.¶
@@ -2927,7 +2932,7 @@RFC EDITOR: PLEASE REMOVE THIS SECTION.¶
-Restructured presentation of content.¶
+Fixed column name and prefilling of the "EDHOC Information" registry.¶
Simplified description of the use of EDHOC_Information.¶
-Merged the concepts of EDHOC "session_id" and identifier of token series.¶
-Enabled the transport of the access token also in EDHOC EAD_3.¶
-Defined semantics of the newly defined CWT/JWT Confirmation Methods.¶
-Clarifications and editorial improvements.¶
+Editorial fixes and improvements.¶
Removed use of EDHOC_KeyUpdate.¶
+Restructured presentation of content.¶
The Security Context is updated either by KUDOS or a rerun of EDHOC.¶
+Simplified description of the use of EDHOC_Information.¶
The alternative workflow (AS token posting) is specified in separate draft.¶
+Merged the concepts of EDHOC "session_id" and identifier of token series.¶
Fixed and updated examples.¶
+Enabled the transport of the access token also in EDHOC EAD_3.¶
Editorial improvements.¶
+Defined semantics of the newly defined CWT/JWT Confirmation Methods.¶
+Clarifications and editorial improvements.¶
Fixed semantics of the ead_value for transporting an Access Token in the EAD_1 field.¶
+Removed use of EDHOC_KeyUpdate.¶
Error handling aligned with EDHOC.¶
+The Security Context is updated either by KUDOS or a rerun of EDHOC.¶
Precise characterization of the EDHOC execution considered for EDHOC-KeyUpdate.¶
+The alternative workflow (AS token posting) is specified in separate draft.¶
Fixed message exchange examples.¶
+Fixed and updated examples.¶
Added appendix with profile requirements.¶
+Editorial improvements.¶
+Fixed semantics of the ead_value for transporting an Access Token in the EAD_1 field.¶
+Error handling aligned with EDHOC.¶
+Precise characterization of the EDHOC execution considered for EDHOC-KeyUpdate.¶
+Fixed message exchange examples.¶
+Added appendix with profile requirements.¶
Updated references.¶
+Updated references.¶
Clarifications and editorial improvements.¶
+Clarifications and editorial improvements.¶
| EDHOC and OSCORE profile of ACE | -plain text | -same as main | -