Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "Message Authentication Code (MAC)", "Hash-based Message Authentication Code (HMAC)", and "verify" are taken from [RFC4949].¶

RESTful terminology follows HTTP [RFC9110].¶

Readers are expected to be familiar with the terms and concepts defined in CoAP [RFC7252], OSCORE [RFC8613], and EDHOC [RFC9528].¶

Readers are also expected to be familiar with the terms and concepts of the ACE framework described in [RFC9200] and in [RFC9201].¶

Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749], such as the client (C), the resource server (RS), and the authorization server (AS). It is assumed in this document that a given resource on a specific RS is associated with a unique AS.¶

Note that the term "endpoint" is used here, as in [RFC9200], following its OAuth definition, which is to denote resources such as /token and /introspect at AS and /authz-info at RS. The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol" is not used in this document.¶

The authorization information (authz-info) resource refers to the authorization information endpoint as specified in [RFC9200]. The term "claim" is used in this document with the same semantics as in [RFC9200], i.e., it denotes information carried in the access token or returned from introspection.¶

Concise Binary Object Representation (CBOR) [RFC8949][RFC8742] and Concise Data Definition Language (CDDL) [RFC8610] are used in this document. CDDL predefined type names, especially bstr for CBOR byte strings and tstr for CBOR text strings, are used extensively in this document.¶

Examples throughout this document are expressed in CBOR diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610]. Diagnostic notation comments are often used to provide a textual representation of the numeric parameter names and values.¶

In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in Figure 7 of Appendix C. For example, {e'session_id' : h'01', e'cipher_suites': 3} stands for {0 : h'01', 2 : 3}.¶

Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in Figure 7 of Appendix C. Finally, please delete this note.¶

3.1. C-to-AS: POST to /token endpoint

The client-to-AS request is specified in Section 5.8.1 of [RFC9200].¶

The client MUST send this POST request to the /token endpoint over a secure channel that guarantees authentication, message integrity, and confidentiality (see Section 5). This document describes the use of CoAP, EDHOC and OSCORE to reduce the number of libraries that C has to support.¶

An example of such a request is shown in Figure 2. In this example, C specifies its own authentication credential by reference, as the hash of an X.509 certificate carried in the "x5t" field of the "req_cnf" parameter. In fact, it is expected that C can typically specify its own authentication credential by reference, since AS is expected to obtain the actual authentication credential during a previous client registration process or secure association establishment with C.¶

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: application/ace+cbor
   Payload:
   {
     / audience / 5 : "tempSensor4711",
     / scope /    9 : "read",
     / req_cnf /  4 : {
       e'x5t' : h'822E4879F2A41B510C1F9B'
     }
   }

If C wants to update its access rights without changing an existing OSCORE Security Context, it MUST include EDHOC_Information in its POST request to the /token endpoint. The EDHOC_Information MUST include the "session_id" field. This POST request MUST omit the "req_cnf" parameter. An example of such a request is shown in Figure 3.¶

The identifier "session_id" is assigned by AS as discussed in Section 3.2, and, together with other information such as audience (see Section 5.8.1 of [RFC9200]), can be used by AS to determine the token series to which the new requested access token has to be added. Therefore, the session_id MUST identify the pair (AUTH_CRED_C, AUTH_CRED_RS) associated with a still valid access token previously issued for C and RS by AS.¶

AS MUST verify that the received "session_id" identifies a token series to which a still valid access token issued for C and RS belongs. If that is not the case, the Client-to-AS request MUST be declined with the error code "invalid_request" as defined in Section 5.8.3 of [RFC9200].¶

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: application/ace+cbor
   Payload:
   {
     / audience /      5 : "tempSensor4711",
     / scope /         9 : "write",
     e'edhoc_info_param' : {
        e'session_id' : h'01'
     }
   }

3.2. Token Series

This document refers to "token series" as a series of access tokens sorted in chronological order as they are released, characterized by the following properties:¶

• issued by the same AS¶

• issued to the same C, and associated with the same authentication credential of C¶

• issued for the same RS, identified by the same authentication credential¶

Upon a successful update of access rights, 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., due to its expiration or revocation), the token series it belongs to ends.¶

The general token series concept is defined in [I-D.ietf-ace-workflow-and-params]. In this profile, a token series is characterized by access tokens used between a given pair (C, RS) having the same "session_id" in the EDHOC_Information, see Section 3.4.¶

AS assigns the "session_id" to the EDHOC_Information when issuing the first access token of a new series and that "session_id" remains fixed throughout the series lifetime. When assigning the identifier, AS MUST ensure that it was not used in a previous series whose access tokens share the following properties with the access tokens of the new series:¶

• i) issued for the same RS; and¶

• ii) bound to the same authentication credential AUTH_CRED_C of the requesting client (irrespectively of how the AUTH_CRED_C is identified in the access tokens).¶

In case the access token is issued for a group-audience (see Section 6.9 of [RFC9200]), what is defined above applies, with the difference that the token series is associated with all the RSs in the group-audience, as indicated by their respective AUTH_CRED_RS.¶

3.3. AS-to-C: Response

After verifying the POST request to the /token endpoint and that C is authorized to access, AS responds as defined in Section 5.8.2 of [RFC9200], with potential modifications as detailed below. If the request from C was invalid, or not authorized, AS returns an error response as described in Section 5.8.3 of [RFC9200].¶

AS can signal that the use of EDHOC and OSCORE as per this profile is REQUIRED for a specific access token, by including the "ace_profile" parameter with the value "coap_edhoc_oscore" in the access token response. This means that C MUST use EDHOC with RS and derive an OSCORE Security Context, as specified in Section 4.4. After that, C MUST use the established OSCORE Security Context to protect communications with RS, when accessing protected resources at RS according to the authorization information indicated in the access token. Usually, it is assumed that constrained devices will be pre-configured with the necessary profile, so that this kind of profile signaling can be omitted.¶

According to this document, the AS provides the access token to C, by specifying it in the "access_token" parameter of the access token response. An alternative workflow where the access token is uploaded by AS directly to RS is described in [I-D.ietf-ace-workflow-and-params].¶

When issuing any access token, AS MUST send the following data in the response to C.¶

• The "session_id" field of EDHOC_Information, which is the identifier of the token series which the issued access token belongs to.¶

When issuing the first access token of a token series, AS MUST send the following data in the response to C.¶

• A unique identification of the authentication credential of RS, AUTH_CRED_RS. This is specified in the "rs_cnf" parameter defined in [RFC9201]. AUTH_CRED_RS can be transported by value or referred to by means of an appropriate identifier.¶

  When issuing the first access token ever to a pair (C, RS) using a pair of corresponding authentication credentials (AUTH_CRED_C, AUTH_CRED_RS), it is typically expected that the response to C may include AUTH_CRED_RS by value.¶

  When later issuing further access tokens to the same pair (C, RS) using the same AUTH_CRED_RS, it is expected that the response to C includes AUTH_CRED_RS by reference.¶

When issuing the first access token of a token series, AS MAY send EDHOC_Information related to RS, see Section 3.4, in corresponding fields of the response to C. This information is based on knowledge that AS have about RS, e.g., from a previous onboarding process, with particular reference to what RS supports as EDHOC peer.¶

Figure 4 shows an example of an AS response. The "rs_cnf" parameter specifies the authentication credential of RS, as an X.509 certificate transported by value in the "x5chain" field. The access token and the authentication credential of RS have been truncated for readability.¶

   Header: Created (Code=2.01)
      Content-Format: application/ace+cbor
      Payload:
      {
        / access_token / 1 : h'8343a1010aa2044c53/...
          (remainder of access token (CWT) omitted for brevity)/',
        / ace_profile / 38 : e'coap_edhoc_oscore',
        / expires_in /   2 : 3600,
        / rs_cnf /      41 : {
          e'x5chain' : h'3081ee3081a1a00302/...'
            (remainder of the credential omitted for brevity)/'
        }
        e'edhoc_info_param' : {
          e'session_id'    : h'01',
          e'methods'       : [0, 1, 2, 3],
          e'cipher_suites' : 0
        }
      }

   {
    / aud /   3 : "tempSensorInLivingRoom",
    / iat /   6 : 1563451500,
    / exp /   4 : 1563453000,
    / scope / 9 :  "temperature_g firmware_p",
    / cnf /   8 : {
      e'x5chain' : h'3081ee3081a1a00302/...
        (remainder of the credential omitted for brevity)/'
    }
    e'edhoc_info_claim' : {
      e'session_id'    : h'01',
      e'methods'       : [0, 1, 2, 3],
      e'cipher_suites' : 0
    }
  }

3.4. EDHOC_Information

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.¶

In the "coap_edhoc_oscore" profile of the ACE-OAuth framework, which is specified in this document, the EDHOC_Information object MUST be encoded as CBOR. However, for easy applicability to other contexts, we define also the JSON encoding.¶

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.¶

Table 1 provides a summary of the EDHOC_Information parameters defined in this section.¶

• session_id: This parameter identifies a 'session' which the EDHOC information is associated with, but does not necessarily identify a specific EDHOC session. In this document, "session_id" identifies a token series. 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 [RFC9528]). 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 [RFC9528]). 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 [RFC9528]) 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.¶

• 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 [RFC9528]. 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 [RFC9528]. 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.¶

• cred_types: This parameter specifies a set of supported types of authentication credentials for EDHOC (see Section 3.5.2 of [RFC9528]). If the set is composed of a single type of authentication credential, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one type of authentication credential. In JSON, the "cred_types" value is an integer or an array of integers. In CBOR, "cred_types" is an integer or an array of integers, and has label 9. The integer values are taken from the "EDHOC Authentication Credential Types" registry defined in [I-D.ietf-core-oscore-edhoc].¶

• id_cred_types: This parameter specifies a set of supported types of authentication credential identifiers for EDHOC (see Section 3.5.3 of [RFC9528]). If the set is composed of a single type of authentication credential identifier, this is encoded as an integer or a text string. Otherwise, the set is encoded as an array, where each array element encodes one type of authentication credential identifier, as an integer or a text string. In JSON, the "id_cred_types" value is an integer, or a text string, or an array of integers and text strings. In CBOR, "id_cred_types" is an integer or a text string, or an array of integers and text strings, and has label 10. The integer or text string values are taken from the 'Label' column of the "COSE Header Parameters" registry [COSE.Header.Parameters].¶

• eads: This parameter specifies a set of supported EDHOC External Authorization Data (EAD) items, identified by their ead_label (see Section 3.8 of [RFC9528]). If the set is composed of a single ead_label, this is encoded as an unsigned integer. Otherwise, the set is encoded as an array of unsigned integers, where each array element encodes one ead_label. In JSON, the "eads" value is an unsigned integer or an array of unsigned integers. In CBOR, "eads" is an unsigned integer or an array of unsigned integers, and has label 11. The unsigned integer values are taken from the 'Label' column of the "EDHOC External Authorization Data" registry defined in [RFC9528].¶

• initiator: This parameter specifies whether the EDHOC Initiator role is supported. In JSON, the "initiator" value is a boolean. In CBOR, "initiator" is the simple value "true" (0xf5) or "false" (0xf4), and has label 12.¶

• responder: This parameter specifies whether the EDHOC Responder role is supported. In JSON, the "responder" value is a boolean. In CBOR, "responder" is the simple value "true" (0xf5) or "false" (0xf4), and has label 13.¶

An example of JSON EDHOC_Information is given in Figure 6.¶

   "edhoc_info" : {
       "session_id"    : b64'AQ==',
       "methods"       : 1,
       "cipher_suites" : 0
   }

The CDDL grammar describing the CBOR EDHOC_Information is:¶

EDHOC_Information = {
  ?  0 => bstr,                   ; id
  ?  1 => int / array,            ; methods
  ?  2 => int / array,            ; cipher_suites
  ?  3 => true / false,           ; message_4
  ?  4 => true / false,           ; comb_req
  ?  5 => tstr,                   ; uri_path
  ?  6 => uint,                   ; osc_ms_len
  ?  7 => uint,                   ; osc_salt_len
  ?  8 => uint,                   ; osc_version
  ?  9 => int / array,            ; cred_types
  ? 10 => int / tstr / array,     ; id_cred_types
  ? 11 => uint / array,           ; eads
  ? 12 => true / false,           ; initiator
  ? 13 => true / false,           ; responder
  * int / tstr => any
}

4.1. C-to-RS: POST to /authz-info endpoint

The access token can be uploaded to RS using CoAP [RFC7252] and the Authorization Information endpoint as described in Section 5.10.1 of [RFC9200].¶

That is, C sends a POST request to the /authz-info endpoint at RS, with the request payload containing the access token without any CBOR wrapping. As per Section 5.10.1 of [RFC9200], the Content-Format of the POST request MUST be "application/cwt" to reflect the format of the transported access token.¶

The communication between C and the /authz-info endpoint is not protected, unless there is a previously established OSCORE Security Context, for example in the case of update of access rights (see Section 4.5).¶

4.2. RS-to-C: 2.01 (Created)

Upon receiving an access token from C, RS MUST follow the procedures defined in Section 5.10.1 of [RFC9200]. That is, RS must verify the validity of the access token. RS may make an introspection request (see Section 5.9.1 of [RFC9200]) to validate the access token.¶

If the access token is valid, RS proceeds as follows.¶

RS checks whether it is already storing the authentication credential of C, AUTH_CRED_C, specified in the "cnf" claim of the access token by value or by reference. If not, RS retrieves AUTH_CRED_C, either using the "cnf" claim or some other trusted source.¶

If RS fails to find or validate AUTH_CRED_C, then RS MUST respond with an error response code equivalent to the CoAP code 4.00 (Bad Request). RS may provide additional information in the payload of the error response, in order to clarify what went wrong.¶

If, instead, the access token is valid but associated with claims that RS cannot process (e.g., an unknown scope), or if any of the expected parameters is missing (e.g., any of the mandatory parameters from AS or the identifier "session_id"), or if any parameters received in the EDHOC_Information is unrecognized, then RS MUST respond with an error response code equivalent to the CoAP code 4.00 (Bad Request). In the latter two cases, RS may provide additional information in the payload of the error response, in order to clarify what went wrong.¶

If all validations are successful, RS MUST reply to the POST request with a 2.01 (Created) response. The access token is stored such that it is possible to retrieve it based on "session_id" and AUTH_CRED_C.¶

When an access token becomes invalid (e.g., due to its expiration or revocation), RS MUST delete the access token and the associated OSCORE Security Context, and MUST notify C with an error response with code 4.01 (Unauthorized) for any long running request, as specified in Section 5.8.3 of [RFC9200].¶

4.3. Access Token in External Authorization Data

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 in an EDHOC External Authorization Data field (see Section 3.8 of [RFC9528]), see example in Appendix A.2.¶

This document defines the EAD item EAD_ACCESS_TOKEN = (ead_label, ead_value), where:¶

• ead_label is the integer value TBD registered in Section 10.8, and¶

• 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 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 [RFC9528]). A Client or Resource Server supporting the profile of ACE defined in this document MUST support this EAD item.¶

Access tokens are transported in EAD fields only for the first access token of a token series, and not for the update of access rights, see Section 4.5.¶

Editor's notes: Add example. Value for ead_label not from lowest range, suggested value 26.¶

4.4. EDHOC Session and OSCORE Security Context

In order to mutually authenticate and establish secure communication for authorized access according to the profile described in this document, C and RS run the EDHOC protocol [RFC9528]. When a new EDHOC session is established, previous EDHOC sessions associated with the same access token and the same pair (session_id, AUTH_CRED_C) are deleted, see Section 4.4.3. The OSCORE Security Contexts derived from those EDHOC sessions are also deleted.¶

As per Appendix A.2 of [RFC9528], EDHOC may be transferred over CoAP using either the forward or the reverse message flow, manifesting the mapping between ACE roles Client / Resource Server and the EDHOC roles Initiator / Responder. The choice of mapping depends on the deployment setting, for example on which identity to protect the most, since EDHOC protects the identity of the Initiator against active attackers.¶

This section details the case where the EDHOC forward message flow is used, i.e., where C = I, RS = R. The converse mapping is described in TODO.¶

Consistent with the EDHOC forward message flow, 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.¶

If the access token is transported during the EDHOC execution, then either EAD_1 or EAD_3 MUST contain the EAD item EAD_ACCESS_TOKEN. It is RECOMMENDED that EAD_ACCESS_TOKEN is carried in EAD_3, i.e., in EDHOC message_3. This provides confidentiality protection against active attackers. EAD_ACCESS_TOKEN MAY be carried in EAD_1, e.g., if the CWT access token is encrypted for RS by AS using COSE_Encrypt0.¶

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. Otherwise, C assumes the target resource at RS to be the well-known EDHOC resource at the path /.well-known/edhoc.¶

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 any other operation than POST on an EDHOC resource.¶

4.5. Update of Access Rights

Editor's note: This section should allow for access rights being updated by AS posting to RS.¶

If C has already established access rights and an OSCORE Security Context with RS, then C can update its access rights by posting a new access token to the /authz-info endpoint.¶

The new access token contains the updated access rights for C to access protected resources at RS, and C has to obtain it from AS as a new access token in the same token series of the current one (see Section 3). When posting the new access token to the /authz-info endpoint, C MUST protect the POST request using the current OSCORE Security Context shared with RS. After successful verification (see Section 4.2), RS will replace the old access token with the new one, while preserving the same OSCORE Security Context. In particular, C and RS do not re-run the EDHOC protocol and they do not establish a new OSCORE Security Context.¶

Editor's note: Mention the alternative when the AS uploads the new access token to RS.¶

If RS receives an access token in an OSCORE protected request, it means that C is requesting an update of access rights. In this case, RS MUST check the following conditions:¶

• RS checks whether it stores an access token T_OLD, such that the "session_id" field of EDHOC_Information matches the "session_id" field of EDHOC_Information in the new access token T_NEW.¶

• RS checks whether the OSCORE Security Context CTX used to protect the request matches the OSCORE Security Context associated with the stored access token T_OLD.¶

If both the conditions above hold, RS MUST replace the old access token T_OLD with the new access token T_NEW, and associate T_NEW with the OSCORE Security Context CTX. Then, RS MUST respond with a 2.01 (Created) response protected with the same OSCORE Security Context, with no payload.¶

Otherwise, RS MUST respond with a 4.01 (Unauthorized) error response. RS may provide additional information in the payload of the error response, in order to clarify what went wrong.¶

As specified in Section 5.10.1 of [RFC9200], when receiving an updated access token with updated authorization information from C (see Section 4.1), it is recommended that RS overwrites the previous access token. That is, only the latest authorization information in the access token received by RS is valid. This simplifies the process needed by RS to keep track of authorization information for a given client.¶

4.6. Discarding the Security Context

There are a number of cases where C or RS have to discard the OSCORE Security Context, and possibly establish a new one.¶

C MUST discard the current OSCORE Security Context shared with RS when any of the following occurs.¶

• The OSCORE Sender Sequence Number space of C is exhausted.¶

• The access token associated with the OSCORE Security Context becomes invalid, for example due to expiration or revocation.¶

• C receives a number of unprotected 4.01 (Unauthorized) responses to OSCORE-protected requests, which are sent to RS and protected using the same OSCORE Security Context. The exact number of such received responses needs to be specified by the application. This may for example happen due to lack of storage in RS, which then sends the "AS Request Creation Hints" message (see Section 5.3 of [RFC9200]).¶

• The authentication credential of C (of RS) becomes invalid, e.g., due to expiration or revocation, and it was used as CRED_I (CRED_R) in the EDHOC session to establish the OSCORE Security Context.¶

RS MUST discard the current OSCORE Security Context shared with C when any of the following occurs:¶

• The OSCORE Sender Sequence Number space of RS is exhausted.¶

• The access token associated with the OSCORE Security Context becomes invalid, for example due to expiration or revocation.¶

• The authentication credential of C (of RS) becomes invalid (e.g., due to expiration or revocation), and it was used as CRED_I (CRED_R) in the EDHOC session to establish the OSCORE Security Context.¶

After a new access token is successfully uploaded to RS, and a new OSCORE Security Context is established between C and RS, messages still in transit that were protected with the previous OSCORE Security Context might not be successfully verified by the recipient, since the old OSCORE Security Context might have been discarded. This means that messages sent shortly before C has uploaded the new access token to RS might not be successfully accepted by the recipient.¶

Furthermore, implementations may want to cancel CoAP observations at RS, if registered before the new OSCORE Security Context has been established. Alternatively, applications need to implement a mechanism to ensure that, from then on, messages exchanged within those observations are going to be protected with the newly derived OSCORE Security Context.¶

4.7. Cases of Establishing a New OSCORE Security Context

The procedure of provisioning a new access token to RS specified in this section applies to various cases when an OSCORE Security Context shared between C and RS has been deleted, for example as described in Section 4.6.¶

Another exceptional case is when there is still a valid OSCORE Security Context but it needs to be updated, e.g., due to a policy limiting its use in terms of time or amount of processed data, or to the imminent exhaustion of the OSCORE Sender Sequence Number space. In this case, C and RS SHALL attempt to run the KUDOS key update protocol [I-D.ietf-core-oscore-key-update], which is a lightweight alternative independent of ACE and EDHOC that does not require the posting of an access token. If KUDOS is not supported, then C and RS falls back to EDHOC as outlined above.¶

In either case, C and RS establish a new OSCORE Security Context that replaces the old one and will be used for protecting their communications from then on. In particular, RS MUST associate the new OSCORE Security Context with the current (potentially re-posted) access token. Unless C and RS re-run the EDHOC protocol, they preserve their OSCORE identifiers, i.e., the OSCORE Sender/Recipient IDs.¶

4.8. Access Rights Verification

RS MUST follow the procedures defined in Section 5.10.2 of [RFC9200]. That is, if RS receives an OSCORE-protected request targeting a protected resource from C, then RS processes the request according to [RFC8613], when Version 1 of OSCORE is used. Future specifications may define new versions of OSCORE, which AS can indicate C and RS to use by means of the "osc_version" field of EDHOC_Information (see Section 3).¶

If OSCORE verification succeeds and the target resource requires authorization, RS retrieves the authorization information using the access token associated with the OSCORE Security Context. Then, RS must verify that the authorization information covers the target resource and the action intended by C on it.¶

6.1. Ordered Chain of X.509 Certificates

The confirmation method "x5chain" specifies an ordered array of X.509 certificates [RFC5280]. The semantics of "x5chain" is like that of the "x5chain" COSE Header Parameter specified in [RFC9360].¶

6.2. Unordered Bag of X.509 Certificates

The confirmation method "x5bag" specifies a bag of X.509 certificates [RFC5280]. The semantics of "x5bag" is like that of the "x5bag" COSE Header Parameter specified in [RFC9360].¶

6.3. Hash of an X.509 Certificate

The confirmation method "x5t" specifies the hash value of the end-entity X.509 certificate [RFC5280]. The semantics of "x5t" is like that of the "x5t" COSE Header Parameter specified in [RFC9360].¶

6.4. URI Pointing to an Ordered Chain of X.509 Certificates

The confirmation method "x5u" specifies the URI [RFC3986] of an ordered chain of X.509 certificates [RFC5280]. The semantics of "x5u" is like that of the "x5u" COSE Header Parameter specified in [RFC9360].¶

6.5. Ordered Chain of C509 Certificates

The confirmation method "c5c" specifies an ordered array of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5c" is like that of the "c5c" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.6. Unordered Bag of C509 Certificates

The confirmation method "c5b" specifies a bag of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5b" is like that of the "c5b" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.7. Hash of a C509 Certificate

The confirmation method "c5t" specifies the hash value of the end-entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5t" is like that of the "c5t" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.8. URI Pointing to an Ordered Chain of C509 Certificates

The confirmation method "c5u" specifies the URI [RFC3986] of a COSE_C509 containing an ordered chain of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. COSE_C509 is defined in [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5u" is like that of the "c5u" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.9. CWT Containing a COSE_Key

The confirmation method "kcwt" specifies a CBOR Web Token (CWT) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The semantics of "kcwt" is like that of the "kcwt" COSE Header Parameter specified in [RFC9528].¶

6.10. CCS Containing a COSE_Key

The confirmation method "kccs" specifies a CWT Claims Set (CCS) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The semantics of "kccs" is like that of the "kccs" COSE Header Parameter specified in [RFC9528].¶

7.1. Ordered Chain of X.509 Certificates

The confirmation method "x5c" specifies an ordered array of X.509 certificates [RFC5280]. The semantics of "x5c" is like that of the "x5c" JSON Web Signature and Encryption Header Parameter specified in [RFC7515], with the following difference. The public key contained in the first certificate is the proof-of-possession key and does not have to correspond to a key used to digitally sign the JWS.¶

7.2. Unordered Bag of X.509 Certificates

The confirmation method "x5b" specifies a bag of X.509 certificates [RFC5280]. The semantics of the "x5b" is like that of the "x5c" JWT confirmation method defined in Section 7.1, with the following differences. First, the set of certificates is unordered and may contain self-signed certificates. Second, the composition and processing of "x5b" are like for the "x5bag" COSE Header Parameter defined in [RFC9360].¶

7.3. Hash of an X.509 Certificate

The confirmation method "x5t" specifies the hash value of the end-entity X.509 certificate [RFC5280]. The semantics of "x5t" is like that of the "x5t" JSON Web Signature and Encryption Header Parameter specified in [RFC7515].¶

7.4. URI Pointing to an Ordered Chain of X.509 Certificates

The confirmation method "x5u" specifies the URI [RFC3986] of an ordered chain of X.509 certificates [RFC5280]. The semantics of "x5u" is like that of the "x5u" COSE Header Parameter specified in [RFC9360], with the following difference. The public key contained in the first certificate is the proof-of-possession key and does not have to correspond to a key used to digitally sign the JWS.¶

7.5. Ordered Chain of C509 Certificates

The confirmation method "c5c" specifies an ordered array of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5c" is like that of the "x5c" JWT confirmation method defined in Section 7.1, with the following difference. Each string in the JSON array is a base64-encoded (Section 4 of [RFC4648] - not base64url-encoded) C509 certificate.¶

7.6. Unordered Bag of C509 Certificates

The confirmation method "c5b" specifies a bag of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5b" is like that of the "c5c" JWT confirmation method defined in Section 7.5, with the following differences. First, the set of certificates is unordered and may contain self-signed certificates. Second, the composition and processing of "c5b" is like for the "c5b" COSE Header Parameter defined in [I-D.ietf-cose-cbor-encoded-cert].¶

7.7. Hash of a C09 Certificate

The confirmation method "c5t" specifies the hash value of the end-entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5t" is like that of the "x5t" JWT confirmation method defined in Section 7.3, with the following differences. First, the base64url-encoded SHA-1 thumbprint is computed over the C509 certificate. Second, the public key contained in the C509 certificate does not have to correspond to a key used to digitally sign the JWS.¶

7.8. URI Pointing to an Ordered Chain of C509 Certificates

The confirmation method "c5u" specifies the URI [RFC3986] of COSE_C509 containing an ordered chain of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. COSE_C509 is defined in [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5u" is like that of the "x5u" JWT confirmation method defined in Section 7.4, with the following differences. First, the URI refers to a resource for the C509 certificate chain. Second, the public key contained in one of the C509 certificates and acting as proof-of-possession key does not have to correspond to a key used to digitally sign the JWS.¶

7.9. CWT Containing a COSE_Key

The confirmation method "kcwt" specifies a CBOR Web Token (CWT) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The format of "kcwt" is the base64url-encoded serialization of the CWT.¶

7.10. CCS Containing a COSE_Key

The confirmation method "kccs" specifies a CWT Claims Set (CCS) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The format of "kcwt" is the base64url-encoded serialization of the CWT.¶

10.1. ACE Profiles Registry

IANA is asked to add the following entry to the "ACE Profiles" registry, following the procedure specified in [RFC9200].¶

• Name: coap_edhoc_oscore¶

• Description: Profile for delegating client authentication and authorization in a constrained environment by establishing an OSCORE Security Context [RFC8613] between resource-constrained nodes, through the execution of the lightweight authenticated key exchange protocol EDHOC [RFC9528].¶

• CBOR Value: TBD (value between 1 and 255)¶

• Reference: [RFC-XXXX]¶

10.2. OAuth Parameters Registry

IANA is asked to add the following entry to the "OAuth Parameters" registry.¶

• Name: "edhoc_info"¶

• Parameter Usage Location: token request and token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

10.3. OAuth Parameters CBOR Mappings Registry

IANA is asked to add the following entry to the "OAuth Parameters CBOR Mappings" registry, following the procedure specified in [RFC9200].¶

• Name: "edhoc_info"¶

• CBOR Key: TBD¶

• Value Type: map¶

• Reference: [RFC-XXXX]¶

10.4. JSON Web Token Claims Registry

IANA is asked to add the following entries to the "JSON Web Token Claims" registry, following the procedure specified in [RFC7519].¶

• Claim Name: "edhoc_info"¶

• Claim Description: Information for EDHOC session¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

10.5. CBOR Web Token (CWT) Claims Registry

IANA is asked to add the following entries to the "CBOR Web Token (CWT) Claims" registry, following the procedure specified in [RFC8392].¶

• Claim Name: "edhoc_info"¶

• Claim Description: Information for EDHOC session¶

• JWT Claim Name: "edhoc_info"¶

• Claim Key: TBD¶

• Claim Value Type: map¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

10.6. JWT Confirmation Methods Registry

IANA is asked to add the following entries to the "JWT Confirmation Methods" registry, following the procedure specified in [RFC7800].¶

• Confirmation Method Value: "x5c"¶

• Confirmation Method Description: An ordered chain of X.509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.1 of [RFC-XXXX]¶

• Confirmation Method Value: "x5b"¶

• Confirmation Method Description: An unordered bag of X.509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.2 of [RFC-XXXX]¶

• Confirmation Method Value: "x5t"¶

• Confirmation Method Description: Hash of an X.509 certificate¶

• Change Controller: IETF¶

• Reference: Section 7.3 of [RFC-XXXX]¶

• Confirmation Method Value: "x5u"¶

• Confirmation Method Description: URI pointing to an ordered chain of X.509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.4 of [RFC-XXXX]¶

• Confirmation Method Value: "c5c"¶

• Confirmation Method Description: An ordered chain of C509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.5 of [RFC-XXXX]¶

• Confirmation Method Value: "c5b"¶

• Confirmation Method Description: An unordered bag of C509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.6 of [RFC-XXXX]¶

• Confirmation Method Value: "c5t"¶

• Confirmation Method Description: Hash of a C509 certificate¶

• Change Controller: IETF¶

• Reference: Section 7.7 of [RFC-XXXX]¶

• Confirmation Method Value: "c5u"¶

• Confirmation Method Description: URI pointing to a COSE_C509 containing an ordered chain of C509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.8 of [RFC-XXXX]¶

• Confirmation Method Value: "kcwt"¶

• Confirmation Method Description: A CBOR Web Token (CWT) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• Change Controller: IETF¶

• Reference: Section 7.9 of [RFC-XXXX]¶

• Confirmation Method Value: "kccs"¶

• Confirmation Method Description: A CWT Claims Set (CCS) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• Change Controller: IETF¶

• Reference: Section 7.10 of [RFC-XXXX]¶

10.7. CWT Confirmation Methods Registry

IANA is asked to add the following entries to the "CWT Confirmation Methods" registry, following the procedure specified in [RFC8747].¶

• Confirmation Method Name: x5chain¶

• Confirmation Method Description: An ordered chain of X.509 certificates¶

• JWT Confirmation Method Name: "x5c"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: COSE_X509¶

• Change Controller: IETF¶

• Reference: Section 6.1 of [RFC-XXXX]¶

• Confirmation Method Name: x5bag¶

• Confirmation Method Description: An unordered bag of X.509 certificates¶

• JWT Confirmation Method Name: "x5b"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: COSE_X509¶

• Change Controller: IETF¶

• Reference: Section 6.2 of [RFC-XXXX]¶

• Confirmation Method Name: x5t¶

• Confirmation Method Description: Hash of an X.509 certificate¶

• JWT Confirmation Method Name: "x5t"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: COSE_CertHash¶

• Change Controller: IETF¶

• Reference: Section 6.3 of [RFC-XXXX]¶

• Confirmation Method Name: x5u¶

• Confirmation Method Description: URI pointing to an ordered chain of X.509 certificates¶

• JWT Confirmation Method Name: "x5u"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: uri¶

• Change Controller: IETF¶

• Reference: Section 6.4 of [RFC-XXXX]¶

• Confirmation Method Name: c5c¶

• Confirmation Method Description: An ordered chain of C509 certificates¶

• JWT Confirmation Method Name: "c5c"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: COSE_C509¶

• Change Controller: IETF¶

• Reference: Section 6.5 of [RFC-XXXX]¶

• Confirmation Method Name: c5b¶

• Confirmation Method Description: An unordered bag of C509 certificates¶

• JWT Confirmation Method Name: "c5b"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: COSE_C509¶

• Change Controller: IETF¶

• Reference: Section 6.6 of [RFC-XXXX]¶

• Confirmation Method Name: c5t¶

• Confirmation Method Description: Hash of a C509 certificate¶

• JWT Confirmation Method Name: "c5t"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: COSE_CertHash¶

• Change Controller: IETF¶

• Reference: Section 6.7 of [RFC-XXXX]¶

• Confirmation Method Name: c5u¶

• Confirmation Method Description: URI pointing to a COSE_C509 containing an ordered chain of C509 certificates¶

• JWT Confirmation Method Name: "c5u"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: uri¶

• Change Controller: IETF¶

• Reference: Section 6.8 of [RFC-XXXX]¶

• Confirmation Method Name: kcwt¶

• Confirmation Method Description: A CBOR Web Token (CWT) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• JWT Confirmation Method Name: "kcwt"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: COSE_Messages¶

• Change Controller: IETF¶

• Reference: Section 6.9 of [RFC-XXXX]¶

• Confirmation Method Name: kccs¶

• Confirmation Method Description: A CWT Claims Set (CCS) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• JWT Confirmation Method Name: "kccs"¶

• Confirmation Key: TBD¶

• Confirmation Value Type: map / #6(map)¶

• Change Controller: IETF¶

• Reference: Section 6.10 of [RFC-XXXX]¶

10.8. EDHOC External Authorization Data Registry

IANA is asked to add the following entry to the "EDHOC External Authorization Data" registry defined in Section 10.5 of [RFC9528].¶

The ead_label = TBD and the ead_value define an access token transferred in an EAD item of EDHOC message_3, with processing specified in Section 4.3.¶

• Name: ACE-OAuth Access Token¶

• Label: TBD¶

• Description: An Access Token as used in the ACE-OAuth framework [RFC9200]¶

• Reference: [RFC-XXXX]¶

10.9. EDHOC Information Registry

IANA is requested to create a new "EDHOC Information" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

As registration policy, the registry uses either "Standards Action with Expert Review", or "Specification Required" per Section 4.6 of [RFC8126], or "Expert Review" per Section 4.5 of [RFC8126]. Expert Review guidelines are provided in Section 10.10.¶

All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, review and approval by the designated expert are also required, in order for the WG chairs to determine that the conditions for early allocation are met (see step 2 in Section 3.1 of [RFC7120]).¶

The columns of the registry are:¶

• Name: A descriptive name that enables easier reference to this item. Because a core goal of this document is for the resulting representations to be compact, it is RECOMMENDED that the name be short.¶

  This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts determine that there is a compelling reason to allow an exception. The name is not used in the CBOR encoding.¶

• 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 designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 and strings of maximum length 2 are designated as "Specification Required". Integer values greater than 65535 and strings of length greater than 2 are designated as "Expert Review". 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.¶

• Registry: The registry that values of the item may come from, if one exists.¶

• Description: A brief description of this item.¶

• Specification: A pointer to the public specification for the item, if one exists.¶

This registry will be initially populated by the values in Table 1. In the "Specification" column, the value for all of these entries will be [RFC-XXXX] and [RFC9528].¶

10.10. Expert Review Instructions

The IANA registry established in this document is defined as "Standards Action with Expert Review", "Specification Required", or "Expert Review", depending on the range of values for which an assignment is requested. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.¶

Expert reviewers should take into consideration the following points:¶

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.¶

• Specifications are required for the Standards Action range of point assignment. Specifications should exist for Specification Required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.¶

• Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.¶

A.1. Workflow without Optimizations

The example below considers the simplest (though least efficient) interaction between the Client and RS. That is: first C uploads the access token to RS; then C and RS run EDHOC; and, finally, the Client accesses the protected resource at RS.¶

A.2. Workflow with Optimizations

The example below builds on the example in Appendix A.1, while additionally relying on the two following optimizations.¶

• The access token is not separately uploaded to the /authz-info endpoint at RS, but rather included in the EAD_3 field of EDHOC message_3 sent by C to RS.¶

• The Client uses the EDHOC+OSCORE request defined in [I-D.ietf-core-oscore-edhoc] is used, when running EDHOC both with AS and with RS.¶

These two optimizations used together result in the most efficient interaction between C and RS, as consisting of only two roundtrips to upload the access token, run EDHOC and access the protected resource at RS.¶

D.1. Version -04 to -05

• CBOR diagnostic notation uses placeholders from a CDDL model.¶

• Only CWTs are supported as access tokens in this profile.¶

• The alternative workflow of ACE is only mentioned as an example.¶

• Clarified that both the EDHOC forward and reverse message flows are possible.¶

• Consistent with the used EDHOC message flow, the access token can be in the EAD item of any EDHOC message.¶

• Explicit registration policies for the new IANA registry.¶

• Fixes in the IANA considerations.¶

• Editorial fixes and improvements.¶

D.2. Version -03 to -04

• Fixed column name and prefilling of the "EDHOC Information" registry.¶

• Added EDHOC_Information Parameters originally in draft-tiloca-lake-app-profiles-00.¶

• Removed the case of transporting access token in EAD_1¶

• Removed redundant normative text¶

• Clarifications of association between access token, session_id, EDHOC session and OSCORE security context¶

• Updated references.¶

• Editorial fixes and improvements.¶

D.3. Version -02 to -03

• Restructured presentation of content.¶

• 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.¶

D.4. Version -01 to -02

• Removed use of EDHOC_KeyUpdate.¶

• The Security Context is updated either by KUDOS or a rerun of EDHOC.¶

• The alternative workflow (AS token posting) is specified in separate draft.¶

• Fixed and updated examples.¶

• Editorial improvements.¶

D.5. Version -00 to -01

• 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.¶

• Clarifications and editorial improvements.¶