]> Ericsson

goran.selander@ericsson.com

Ericsson

john.mattsson@ericsson.com

RISE

marco.tiloca@ri.se

RISE

rikard.hoglund@ri.se

Security ACE Working Group Internet-Draft This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes the Lightweight Authenticated Key Exchange (LAKE) protocol for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. LAKE also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. About This Document Status information for this document may be found at . Discussion of this document takes place on the Authentication and Authorization for Constrained Environments (ace) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document defines the "coap_lake_oscore" profile of the Authentication and Authorization for Constrained Environments (ACE) framework , also denoted as ACE-OAuth framework. This profile addresses a "zero-touch" constrained setting where authenticated and authorized operations can be performed with low overhead without endpoint specific configurations. Like in the "coap_oscore" profile , also in this profile a client (C) and a resource server (RS) use the Constrained Application Protocol (CoAP) to communicate and Object Security for Constrained RESTful Environments (OSCORE) to protect their communications. However, this profile uses the Lightweight Authenticated Key Exchange (LAKE) protocol to establish the OSCORE Security Context. The processing of requests for specific protected resources is identical to what is defined in the "coap_oscore" profile. When using this profile, C accesses protected resources hosted at RS according to the authorization information specified in an access token, which is issued by a trusted authorization server (AS) and is bound to an authentication credential of C. This differs from the "coap_oscore" profile, where the access token is bound to a secret that is generated by AS and is used to derive the OSCORE Security Context. Whereas recommends the use of CBOR Web Tokens (CWTs) as access tokens, this profile requires it (see ). Furthermore, this profile requires that, for messages exchanged between C and AS to request and provide an access token, the payload is encoded in CBOR (see and ), which ACE requires if CoAP is used (see ) and recommends otherwise (see ). An authentication credential can be a CWT; a raw public key, e.g., encoded as a CWT Claims Set (CCS) ; or a public key certificate, e.g., an X.509 certificate or a CBOR-encoded C509 certificate ; or a different type of data structure containing the public key of the peer in question. The ACE framework establishes what those authentication credentials are, and it may transport the actual authentication credentials by value or uniquely refer to them. If an authentication credential is pre-provisioned or can be obtained over less constrained links, then it suffices that ACE provides a unique reference such as a certificate hash (e.g., by using the COSE header parameter "x5t" ). This is in the same spirit as LAKE, where the authentication credentials specified in the ID_CRED_x message fields can be transported by value or referred to (see ). In general, AS and RS are likely to have trusted access to each other's authentication credentials, since AS acts on behalf of RS as per the trust model of ACE. Also, AS needs to have some information about C, including the relevant authentication credential, in order to identify C when C requests an access token and to determine what access rights can be granted. However, the authentication credential of C may potentially be conveyed (or uniquely referred to) within the request for an access token that C makes to AS. The establishment of an association between RS and AS in an ACE ecosystem is out of scope, but one solution is to build on the same primitives as used in this document, i.e., LAKE for authentication and OSCORE for communication security, using for example for onboarding RS with AS and for establishing a trust anchor in RS. A similar procedure can also be applied between C and AS for registering a client and for the establishment of a trust anchor. With reference to initial authentication, the scope of this profile only includes the use of LAKE with authentication methods based on public key authentication, such as those specified in and the one specified in . Future documents can extend this profile to also support the use of LAKE with other (kinds of) authentication methods for initial authentication, such as the one defined in and based on symmetric pre-shared keys (PSKs). Note that, according to this document, it is already possible to use the method defined in in order to perform LAKE session resumption with PSK-based authentication.

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 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 . RESTful terminology follows HTTP . Readers are expected to be familiar with the terms and concepts defined in CoAP , OSCORE , and LAKE . This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in . Identifiers defined literally in or in IANA registries (e.g., the names of the EDHOC registries themselves) are unchanged. Readers are also expected to be familiar with the terms and concepts of the ACE framework described in and in . Terminology for entities in the architecture is defined in OAuth 2.0 , 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 single AS. Note that the term "endpoint" is used here, as in , following its OAuth definition, which is to denote resources such as /token and /introspect at AS, and /authz-info at RS. The CoAP definition, which is "[a]n 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 . The term "claim" is used in this document with the same semantics as in , i.e., it denotes information carried in the access token or returned from introspection. Concise Binary Object Representation (CBOR) and Concise Data Definition Language (CDDL) 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 and . 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 of . 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 of . Finally, please delete this note.

Protocol Overview This section gives an overview of how to use the ACE framework together with the LAKE protocol . By doing so, the client (C) and the resource server (RS) generate an OSCORE Security Context associated with authorization information, and they use that Security Context to protect their communications. The parameters needed by C to negotiate the use of this profile with the authorization server (AS), as well as the OSCORE setup process, are described in detail in the following sections. RS maintains a collection of clients' authentication credentials. These are associated with OSCORE Security Contexts and with authorization information for all clients that RS is communicating with. The authorization information is used to enforce policies for processing requests from those clients. The ACE framework describes how integrity protected authorization information propagates from AS to RS. This profile describes how C requests from AS an access token specifying authorization information for the resources that C wants to access at RS, by sending an access token request to the /token endpoint at AS (see ). If the request is granted, then AS replies to C with a successful response that specifies the authentication credential of RS. Also, AS can provide the access token to C by including it in the response, or instead upload the access token directly to RS as per the alternative workflow defined in . The latter option is not detailed further in this document. In order to establish an OSCORE Security Context, C and RS run the LAKE protocol. If C has obtained an access token from AS, then C specifies the access token within an External Authorization Data (EAD) field of a LAKE message sent during the LAKE session (see ). The authentication credential of C that is used during the LAKE session is the same one that is bound to and specified in the access token. How C and RS run LAKE is detailed in . If C and RS successfully complete the LAKE execution and the validation of each other's authentication credential, they are mutually authenticated and derive the OSCORE Security Context as per . From then on and as long as there is a valid access token, C effectively gains authorized and secure access to protected resources at RS using the established OSCORE Security Context. When RS receives a request from C protected with an OSCORE Security Context derived from a LAKE session according to this profile, then that OSCORE Security Context is used to retrieve the uniquely associated access token indicating the access rights of C. The OSCORE Security Context is discarded when an access token (whether the same or a different one) specifying the same authentication credential of C is used to successfully derive a new OSCORE Security Context for C. outlines an example of the message flow. A more detailed message flow is shown in .

Protocol Outline using the LAKE Forward Message Flow. | | | | +------- POST /token --------------------------------------------->| | | | |<--------------------------------------------- Access Token ------+ | + Access Information | | | | +------- POST /.well-known/edhoc ------->| | | (LAKE message_1) | | | | | |<------------ 2.04 Changed -------------+ | | (LAKE message_2) | | | | | / Authentication of RS / | | | | | / Derivation of OSCORE | | Security Context / | | | | | +------- POST /.well-known/edhoc ------->| | | (LAKE message_3 with | | | access_token in EAD_3) | | | | | | / Authentication of C / | | | | | / Proof of possession / | | | | | / Derivation of OSCORE | | Security Context / | | | | +----------- OSCORE Request ------------>| | | | | |<---------- OSCORE Response ------------| | | | | ]]>

As long as the OSCORE Security Context and the access token are valid, C can contact AS to request an update of its access rights, by sending a similar request as described above to the /token endpoint. This request also includes a "session identifier" (see ) provided by AS in the response to the initial access token request, which allows AS to retrieve the data that it 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 ). If C has obtained from AS an access token belonging to the same token series for updating its access rights, then C transfers the access token to RS using the /authz-info endpoint as specified in , where the exchanged CoAP messages are protected by the previously established OSCORE Security Context (see ). If the access token is valid, RS replies to the request with a 2.01 (Created) response. Upon successful update of access rights, the new issued access token effectively becomes the latest in its token series also for RS, but the session identifier remains the same. When the latest access token of a token series becomes invalid (e.g., when it expires or gets revoked), that token series ends. outlines the message flow for updating access rights.

Protocol Outline for Updating Access Rights. | | | | +-------- POST /token -------------------------------->| | | | |<--------------------------------- Access Token ------+ | + Access Information | | | | +--- POST /authz-info ------>| | | (OSCORE protected with | | | access_token in payload) | | | | | | / Updated access rights / | | | | |<------ 2.01 Created -------+ | | | | | | | +----- OSCORE Request ------>| | | | | |<---- OSCORE Response ------| | | | | ]]>

Client-AS Communication The following subsections describe the details of the POST request and response to the /token endpoint between C and AS. In this exchange, C provides AS with its own authentication credential AUTH_CRED_C. Then, AS issues the access token as securely bound to AUTH_CRED_C, by including it or uniquely referring to it in the access token. Together with the access token, AS provides C with a set of parameters that enable C to run LAKE with RS. In particular, these parameters include information about the authentication credential AUTH_CRED_RS of RS, which is transported by value or uniquely referred to. The request to the /token endpoint and the corresponding response can include LAKE_Information, which is a CBOR map object containing information about the use of LAKE between C and RS (see ). This object is transported in the "lake_info" parameter registered in and .

C-to-AS: POST to /token Endpoint The client-to-AS request is specified in . The client MUST send this POST request to the /token endpoint over a secure channel that guarantees authentication, message integrity, and confidentiality (see ). When using this profile, the payload of the POST request MUST be encoded in CBOR , i.e., the request has media-type "application/ace+cbor". In order to reduce the number of libraries that C has to support, it is RECOMMENDED that C and AS use CoAP as message transfer protocol, OSCORE as security protocol, and LAKE to establish an OSCORE Security Context. AUTH_CRED_C is specified in the "req_cnf" parameter of the POST request, either transported by value or uniquely referred to. AS could explicitly ask C to provide its authentication credential AUTH_CRED_C by value in the access token request, e.g., by relying on the method defined in . For AUTH_CRED_C, its authentication credential type MUST be one of those supported by LAKE, e.g., CWTs and CCSs , X.509 certificates , and C509 certificates . Consequently, the "req_cnf" parameter MUST specify a confirmation method suitable for the type of AUTH_CRED_C, e.g., "x5chain" or "x5t" when AUTH_CRED_C is an X.509 certificate transported by value or referred to, respectively. Note that LAKE does not admit the use of "naked" COSE_Keys as authentication credentials. The closest admitted authentication credential type is a CCS containing a COSE_Key in a "cnf" claim and possibly other claims, which can be transported by value using the confirmation method "kccs". Therefore, the "req_cnf" parameter MUST NOT specify the confirmation method "COSE_Key" (CBOR abbreviation: 1). When receiving an access token request including the "req_cnf" parameter, AS checks whether it is already storing the authentication credential of C, namely AUTH_CRED_C, specified in "req_cnf" by value or reference. If this is not the case, AS retrieves AUTH_CRED_C, either using the "req_cnf" parameter or some other trusted source. After that, AS validates the actual AUTH_CRED_C. In either case, AS also needs to verify that C is in possession of the private key corresponding to the public key associated with AUTH_CRED_C. This may already have been accomplished, for example, through C authenticating to AS using AUTH_CRED_C as authentication credential, or through some other trusted party vouching for C to AS. Alternatively, it is possible to use an approach for achieving proof of possession similar to that in . If the validations are successful, AS stores AUTH_CRED_C as a valid authentication credential. Otherwise, the Client-to-AS request MUST be declined. An example of client-to-AS request is shown in . 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.

Example C-to-AS POST /token Request for an Access Token.

If C wants to update its access rights without changing an existing OSCORE Security Context, it MUST specify a LAKE_Information object in the "lake_info" parameter of its POST request to the /token endpoint. The LAKE_Information object MUST include the "session_id" field. This POST request MUST NOT include the "req_cnf" parameter. An example of such a request is shown in . The identifier "session_id" is assigned by AS as discussed in and identifies an ongoing token series associated with the pair (AUTH_CRED_C, AUTH_CRED_RS). That is, previous access tokens in that series were issued by AS to C, as bound to AUTH_CRED_C and intended for RS as identified by AUTH_CRED_RS. Note that the same "session_id" value might identify multiple ongoing token series, e.g., if those are associated with the same client but different resource servers. In this case, AS can use the "session_id" value together with other information such as the targeted audience (see ) and the authenticated identity of C, in order to determine the exact token series to which the new requested access token has to be added. The "audience" parameter MUST be included in the POST request, if it was included in the POST request that C previously sent to AS for requesting the first access token in the token series to which the new requested access token has to be added. If the "audience" parameter is included in the present POST request, its value MUST be the same value of the "audience" parameter in that previous POST request. AS MUST verify that the received "session_id" identifies a token series to which a still valid access token belongs, such that the access token is issued to C and is intended for the audience specified by the "audience" parameter of the POST request, if present therein, or for the default audience associated with C otherwise. If that is not the case, the Client-to-AS request MUST be declined with the error code "invalid_request" as defined in .

Example C-to-AS POST /token Request for Updating Access Rights to an Access Token.

Token Series This document refers to "token series" as a series of access tokens that are sorted in chronological order of release and are 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 as identified by the same authentication credential.

Upon a successful update of access rights (see ), 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. In this profile, a token series comprises access tokens that are used between a given pair (C, RS), are bound to the same authentication credential AUTH_CRED_C of C, and specify the same value in the "session_id" field of the LAKE_Information object (see ) in their "lake_info" claim (see ). AS assigns the value of "session_id" when issuing the first access token of a new series. That "session_id" value remains fixed throughout the series lifetime. When assigning the "session_id" value, AS MUST ensure that, irrespective of the profile of ACE used, such value was not used in a previous series whose access tokens share both the following properties with the access tokens of the new series:

• Issued to the same client C, irrespective of the specific AUTH_CRED_C bound to the access token; and
• Issued for the same RS as identified by the targeted audience, irrespective of the specific AUTH_CRED_RS indicated to C.

If the access token is issued for a group-audience (see ), the token series is associated with all the resource servers in the group-audience. In such case, what is defined above applies, with the difference that the resource servers as identified by the targeted group-audience are collectively considered, irrespective of their specific authentication credentials indicated to C.

AS-to-C: Response After verifying the POST request to the /token endpoint and that C is authorized to access protected resources at RS, AS responds as defined in , with potential modifications as detailed below. When using this profile, consistent with what is specified in , the payload of the response from AS MUST be encoded in CBOR , i.e., the response has media-type "application/ace+cbor". If the request from C was invalid or not authorized, AS returns an error response as described in . AS can signal that the use of LAKE and OSCORE as per this profile is REQUIRED for a specific access token, by including the "ace_profile" parameter with the value "coap_lake_oscore" in the access token response. This means that C MUST use LAKE with RS and derive an OSCORE Security Context, as specified in . 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, 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 . When issuing the first access token of a token series, AS MUST include the following data in the response to C.

• The "lake_info" parameter conveying a LAKE_Information object (see ). The LAKE_Information object MUST include the "session_id" field specifying the identifier of the token series which the issued access token belongs to. The LAKE_Information object MAY include additional fields (see ) to convey information about RS. This information is based on knowledge that AS has about RS, e.g., from a previous onboarding process, with particular reference to what RS supports as a LAKE peer. If the access token is issued for a group-audience (see ), the information specified in the LAKE_Information object refers to the group-audience as a whole. Therefore, it is appropriate for AS to define group-audiences comprising RSs that are all aligned in terms of supported LAKE features and configurations.
• A unique identification of the authentication credential of RS, AUTH_CRED_RS. This is specified in the "rs_cnf" parameter defined in . AUTH_CRED_RS can be transported by value or referred to by means of an appropriate identifier. C could explicitly ask AS to provide AUTH_CRED_RS by value in the access token response, e.g., by relying on the method defined in . 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 expected that the response to C includes 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. For AUTH_CRED_RS, its authentication credential type MUST be one of those supported by LAKE. Consequently, the "rs_cnf" parameter MUST specify a confirmation method suitable for the type of AUTH_CRED_RS. That is, the same considerations about AUTH_CRED_C and the "req_cnf" parameter made in hold for AUTH_CRED_RS and the "rs_cnf" parameter.

When issuing any access token of a token series, the response from AS MUST NOT include the "cnf" parameter. When issuing an access token for dynamically updating access rights (i.e., the access token is not the first in its token series), the response from AS MUST NOT include the "lake_info" and "rs_cnf" parameters (see ). 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.

Example of AS-to-C Access Token Response with LAKE and OSCORE Profile.

Access Token To avoid the complexity of different encodings, an access token of this profile SHALL be a CWT . When issuing any access token of a token series, AS MUST include the following claims in the access token:

• The "lake_info" claim registered in and conveying a LAKE_Information object (see ). The LAKE_Information object MUST include the "session_id" field specifying the identifier of the token series that the issued access token belongs to. The "session_id" value is the same one included in the LAKE_Information object of the response to C from the /token endpoint (see ), when providing C with the first access token in the series.
• The "cnf" claim, specifying the authentication credential AUTH_CRED_C that C specified in its POST request to the /token endpoint, when requesting the first access token in the series that the issued access token belongs to (see ). In the access token, AUTH_CRED_C can be transported by value or uniquely referred to by means of an appropriate identifier. Yet, consistent with the considerations about AUTH_CRED_C and the "req_cnf" parameter made in , the "cnf" claim of the access token MUST specify a confirmation method suitable for the type of AUTH_CRED_C. When issuing the first access token of a token series, the confirmation method used in the "cnf" claim MUST be the same one used in the "req_cnf" parameter of the corresponding POST request from C to the /token endpoint. 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 expected that AUTH_CRED_C is included by value in the "cnf" claim of the access token. When later issuing further access tokens to the same pair (C, RS) using the same AUTH_CRED_C, it is expected that AUTH_CRED_C is identified by reference in the "cnf" claim of the access token. Either transported by value or identified by reference, the authentication credential specified in the "cnf" claim MUST be exactly the one that was specified in the "req_cnf" parameter of the POST request to the /token endpoint, when C requested the first access token in the series that the issued access token belongs to. That is, AS MUST NOT bind to the access token an authentication credential other than the one specified by C.

When issuing the first access token of a token series, AS MAY include additional fields in the LAKE_Information object (see ) specified in the "lake_info" claim of the access token. The access token needs to be protected for various reasons. To prevent manipulation of the content, it needs to be integrity protected. Also, RS has to be able to verify that the access token is issued by a trusted AS, by achieving source authentication. Depending on the use case and deployment, the access token may need to be confidentiality protected, for example due to privacy reasons. AS protects the access token using a COSE method as specified in . Depending on the audience, there can be different ways to most appropriately ensure the confidentiality of an access token. For an audience comprising a single RS, the CWT Claims Set may be wrapped in COSE_Encrypt / COSE_Encrypt0. Instead, if the access token needs to be read by multiple RSs, then the CWT Claims Set may be wrapped in COSE_Sign / COSE_Sign1 and confidentiality protection is applied during transport, e.g., by including the access token in the EAD_3 field of LAKE message_3 sent by C to RS, when using the LAKE forward message flow (see ). shows an example of CWT Claims Set, including the relevant LAKE parameters in the "lake_info" claim. The "cnf" claim specifies the authentication credential of C, as an X.509 certificate transported by value in the "x5chain" field. The authentication credential of C has been truncated for readability.

Example of CWT Claims Set with LAKE Parameters.

Processing at C When receiving an access token response including the "rs_cnf" parameter, C checks whether it is already storing the authentication credential of RS, namely AUTH_CRED_RS, specified in "rs_cnf" by value or reference. If this is not the case, C retrieves AUTH_CRED_RS, either using the "rs_cnf" parameter or some other trusted source. After that, C validates the actual AUTH_CRED_RS. If the validation is successful, C stores AUTH_CRED_RS as a valid authentication credential. Otherwise, C MUST delete the access token.

Update of Access Rights If C has a valid OSCORE Security Context shared with RS and associated with a valid access token, then C can send a request to AS for updating its access rights while preserving the same OSCORE Security Context. If the request is granted, then AS generates a new access token, where the LAKE_Information object specified in the "lake_info" claim MUST include only the "session_id" field. The access token is provisioned to RS either via C as specified in this document, or directly as described in . In either case, the access token response from AS to C MUST NOT include the "lake_info" and "rs_cnf" parameters. As defined in , the "session_id" field is included in the LAKE_Information object specified in the "lake_info" claim of the new access token. This allows RS to identify the old access token to supersede, as well as the OSCORE Security Context already shared between C and RS and to be associated with the new access token.

LAKE_Information LAKE_Information is an object including information about the use of LAKE, e.g., to guide peers towards executing LAKE. In particular, the LAKE_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_lake_oscore" profile of the ACE-OAuth framework, which is specified in this document, the LAKE_Information object MUST be encoded as CBOR. However, for easy applicability to other contexts, the JSON encoding is also defined. The LAKE_Information can be encoded either as a JSON object or as a CBOR map. The set of common fields that can appear in a LAKE_Information can be found in the IANA "LAKE Information" registry defined in for extensibility. All LAKE_Information parameters are optional. The initial set of parameters defined in this document is summarized in and is specified below. LAKE_Information parameters are also categorized, i.e., each has one of two possible types, namely prescriptive or non-prescriptive:

• A prescriptive parameter is used to provide an authoritative statement about how an execution of LAKE has to be performed. An example is the "message_4" parameter indicating whether the use of LAKE message_4 in a LAKE session is mandatory or not. If a prescriptive parameter applies to a LAKE session, a peer participating in the session complies with what is indicated by the parameter, and it aborts the session if it determines that the other peer has violated such indication.
• A non-prescriptive parameter is used to provide convenient information to consider when executing LAKE, e.g., in terms of features supported by peers. Such information is not necessarily exhaustive. An example is the "methods" parameter indicating a set of supported LAKE methods.

This categorization helps coordinate the use of LAKE application profiles (see ) in a robust way, e.g., by using the means defined in . LAKE_Information Parameters. Types: P (Prescriptive), NP (Non-Prescriptive)

Name	CBOR label	CBOR type	Registry	Description	Type
session_id	0	bstr		Identifier of a session	P
methods	1	int or array	EDHOC Method Type registry	Set of supported LAKE methods	NP
cipher_suites	2	int or array	EDHOC Cipher Suites registry	Set of supported LAKE cipher suites	NP
message_4	3	True or False		Mandatory use of LAKE message_4	P
comb_req	4	True or False		Support for the LAKE + OSCORE combined request	NP
uri_path	5	tstr		URI-path of the LAKE resource	P
cred_types	6	int or array	EDHOC Authentication Credential Types registry	Set of supported types of authentication credentials for LAKE	NP
id_cred_types	7	int or tstr or array	COSE Header Parameters registry	Set of supported types of authentication credential identifiers for LAKE	NP
eads	8	uint or array	EDHOC External Authorization Data registry	Set of supported LAKE External Authorization Data (EAD) items	NP
initiator	9	True or False		Support for the LAKE Initiator role	NP
responder	10	True or False		Support for the LAKE Responder role	NP
trust_anchors	11	map	LAKE Trust Anchor Purposes registry and LAKE Trust Anchor Types registry	Set of supported trust anchors	NP

• session_id: This parameter specifies an identifier of a "session" that the LAKE information is associated with, but it does not necessarily identify a specific LAKE session. In this document, "session_id" identifies a token series. In JSON, the "session_id" value is a string, with value the base64url-encoding (see ) without padding of the binary representation of the identifier. In CBOR, the "session_id" type is a byte string with value the binary representation of the identifier, and it has label 0.
• methods: This parameter specifies a set of supported LAKE methods (see ). If the set is composed of a single LAKE method, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one LAKE 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 it has label 1.
• cipher_suites: This parameter specifies a set of supported LAKE cipher suites (see ). If the set is composed of a single LAKE cipher suite, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one LAKE 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 it has label 2.
• message_4: This parameter indicates whether the LAKE message_4 (see ) is supported. In JSON, the "message_4" value is a boolean. In CBOR, "message_4" is the simple value true (0xf5) or false (0xf4), and it has label 3.
• comb_req: This parameter indicates whether the combined LAKE + OSCORE request defined in (denoted therein as "EDHOC + OSCORE request") is supported. In JSON, the "comb_req" value is a boolean. In CBOR, "comb_req" is the simple value true (0xf5) or false (0xf4), and it has label 4.
• uri_path: This parameter specifies the path component of the URI of the LAKE resource where LAKE 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 it has label 5.
• cred_types: This parameter specifies a set of supported types of authentication credentials for LAKE (see ). 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 it has label 6. The integer values are taken from the 'Value' column of the "EDHOC Authentication Credential Types" registry .
• id_cred_types: This parameter specifies a set of supported types of authentication credential identifiers for LAKE (see ). 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 it has label 7. The integer or text string values are taken from the 'Label' column of the "COSE Header Parameters" registry .
• eads: This parameter specifies a set of supported LAKE External Authorization Data (EAD) items, identified by their ead_label (see ). 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 it has label 8. The unsigned integer values are taken from the 'Label' column of the "EDHOC External Authorization Data" registry .
• initiator: This parameter specifies whether the LAKE 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 it has label 9.
• responder: This parameter specifies whether the LAKE 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 it has label 10.
• trust_anchors: This parameter specifies a collection of supported trust anchors for performing authentication. According to what is specified within the collection, these trust anchors are used for different purposes, e.g., for verifying authentication credentials of other LAKE peers in LAKE sessions. More in detail, the collection of trust anchors is composed of one or more sets. Each set includes one or more trust anchors to use for one specific purpose associated with that set. In particular, each set is composed of pairs, each of which specifies a trust anchor type and an identifier of a trust anchor of that type. If the set is composed of a single pair, this pair is specified as a single item. If the set is composed of multiple pairs, these pairs are specified as elements of an array. Trust anchor purposes are selected from the "LAKE Trust Anchor Purposes" registry defined in of this document. Trust anchor types are selected from the "LAKE Trust Anchor Types" registry defined in of this document. In JSON, the "trust_anchors" value is an object with one or more outer entries, each of which is associated with a trust anchor purpose. The following applies for each outer entry:
  • The outer entry's key specifies the associated trust anchor purpose taken from the 'Name' column of the "LAKE Trust Anchor Purposes" registry.
  • The outer entry's value is an object or an array of at least two objects. Each object includes one inner entry, specifying the pair for a trust anchor TA of type TYPE. The inner entry is formatted as follows:
    • The inner entry's key specifies the TA's type TYPE taken from the 'Name' column of the "LAKE Trust Anchor Types" registry.
    • The inner entry's value is the identifier of TA, whose encoding depends on TYPE. Such an encoding is what results from applying the conversion in to the CBOR encoding of the identifier of TA when "trust_anchors" is encoded in CBOR (see below).
  In CBOR, the "trust_anchors" value is a map and has label 11. The map includes one or more outer entries, each of which is associated with a trust anchor purpose. The following applies for each outer entry:
  • The outer entry's key specifies the associated trust anchor purpose encoded as a CBOR integer, with integer value taken from the 'CBOR label' column of the "LAKE Trust Anchor Purposes" registry.
  • The outer entry's value is a map or an array of at least two maps. Each map includes one inner entry, specifying the pair for a trust anchor TA of type TYPE. The inner entry is formatted as follows:
    • The inner entry's key specifies the TA's type TYPE encoded as a CBOR integer, with integer value taken from the 'CBOR label' column of the "LAKE Trust Anchor Types" registry.
    • The inner entry's value specifies the identifier of TA, whose encoding depends on TYPE and is specified by the 'Value type' column of the "LAKE Trust Anchor Types" registry, for the registry entry that has TYPE as value of the 'Name' column.

shows an example where a JSON object includes a property with value a LAKE_Information object.

Example of JSON LAKE_Information

shows an example where a CBOR map includes an element with value a LAKE_Information object.

Example of CBOR LAKE_Information

The CDDL grammar describing the CBOR LAKE_Information is: bstr, ; id ? 1 => int / [2* int], ; methods ? 2 => int / [2* int], ; cipher_suites ? 3 => true / false, ; message_4 ? 4 => true / false, ; comb_req ? 5 => tstr, ; uri_path ? 6 => int / [2* int], ; cred_types ? 7 => int / tstr / [2* (int / tstr)], ; id_cred_types ? 8 => uint / [2* uint], ; eads ? 9 => true / false, ; initiator ? 10 => true / false, ; responder ? 11 => trust_anchors_value, ; trust_anchors * (int / tstr) => any } trust_anchors_value = { 1* int => trust_anchors_outer_entry_value } trust_anchors_outer_entry_value = trust_anchors_container / [2* trust_anchors_container] trust_anchors_container = { int => trust_anchors_inner_entry_value } trust_anchors_inner_entry_value = any ]]>

Client-RS Communication This section describes the exchange between C and RS, including the execution of the LAKE protocol and the uploading of the access token from C to RS. An alternative workflow, where AS uploads the access token directly to RS, is defined in . C and RS run the LAKE protocol (see ) and C uploads the access token through the EAD field of a LAKE message (see ). Once the LAKE session is successfully completed, C and RS derive an OSCORE Security Context (see ). After that, OSCORE is used for protecting communications when C accesses resources at RS, as per the authorization information indicated in the access token (see ). Detailed examples are shown in .

EAD Item for Transporting Access Token This section defines an EAD item (see ) for specifying an access token by value in the EAD field of a LAKE message. The name of the EAD item is ACE-OAuth Access Token, for which the CDDL grammar is shown in .

EAD Item ACE-OAuth Access Token.

In particular:

• ead_label is the integer value TBD registered in .
• ead_value is a CBOR byte string equal to the value of the "access_token" field of the access token response from AS (see ).

Note to RFC Editor: Please replace TBD with the value registered for ACE-OAuth Access Token in , then delete this note. 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 progress the protocol execution using the received access token, or else abort the LAKE session (see ). A client or resource server supporting the profile of ACE defined in this document MUST support this EAD item. This EAD item is used only when uploading the first access token of a token series, but not for the dynamic update of access rights (see ). Example: assuming that ead_label is 24 and that the value of the "access_token" field of the access token response from AS is equal to h'8343a1010aa2044c53...0f6a' (elided for brevity), the critical EAD item is as follows: Note to RFC Editor: Please replace the value of the ead_label with the value registered for ACE-OAuth Access Token in , then delete this note.

LAKE Session 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 LAKE protocol augmented with an access token. During the LAKE session, C specifies the access token to RS, in the EAD field of a LAKE message. According to this document, C uses the EAD item ACE-OAuth Access Token defined in and specifying the access token by value. Future documents can define alternative EAD items for specifying the access token by reference. As per , LAKE can be transferred over CoAP using either the forward or the reverse message flow, thus manifesting the two possible mappings between the ACE roles (client and resource server) and the LAKE roles (Initiator and Responder), whereas the CoAP roles (client and server) remain the same. The choice of message flow and corresponding mapping depends on the deployment setting and in particular on which identity to protect the most, since LAKE protects the identity of the Initiator against active attackers and the identity of the Responder against passive attackers. If the LAKE forward message flow is used (see ), C acts as the LAKE Initiator and the access token MUST be specified in the EAD_3 field of LAKE message_3. If the LAKE reverse message flow is used (see ), C acts as the LAKE Responder and the access token MUST be specified in the EAD_4 field of LAKE message_4. By doing so, the access token specified in the EAD field is always protected by LAKE, using authenticated encryption and achieving confidentiality against active attackers (see Sections and of ). The authentication credential AUTH_CRED_C that C specifies in the ID_CRED_X field during the LAKE session MUST be the same one that C specifies in the access token request to AS (see ) and that is bound to the access token specified to RS during the LAKE session. When RS processes the EAD item ACE-OAuth Access Token, RS MUST verify that the authentication credential AUTH_CRED_C that C specifies in the ID_CRED_X field during the LAKE session is the same one that is bound to the access token specified by the EAD item. If such a verification fails, RS MUST abort the LAKE session. Note that:

• The ID_CRED_X field in question is the ID_CRED_I or ID_CRED_R field, when using the LAKE forward message flow or reverse message flow, respectively.
• The authentication credential bound to the access token is specified by the "cnf" claim of the access token specified by the EAD item.

RS MUST have successfully validated the access token before successfully completing the LAKE session. If completed successfully, the LAKE session is associated with both the access token and the pair (SESSION_ID, AUTH_CRED_C). In particular, SESSION_ID is specified by the "session_id" field, within the LAKE_Information object specified by the "lake_info" claim of the access token. Any previous LAKE session associated with the same access token and with the same pair (SESSION_ID, AUTH_CRED_C) MUST be deleted. The OSCORE Security Context derived from that LAKE session MUST also be deleted. Depending on the message flow used, the LAKE messages will be carried either in CoAP POST requests or in CoAP 2.04 (Changed) responses, as detailed in . C MUST target the LAKE resource at RS with the URI path specified in the "uri_path" field (if present) of the LAKE_Information object within the access token response received from AS, which AS sent to C when issuing the first access token of the token series (see ). If the "uri_path" field is not present in that LAKE_Information object, C assumes the target resource at RS to be the well-known LAKE resource at the path /.well-known/edhoc. In this profile of ACE, RS MUST implement the CoAP Uri-Path-Abbrev Option specified in and MUST understand the corresponding Uri-Path-Abbrev value 2 that abbreviates the path /.well-known/edhoc. While there is no equivalent requirement for C, the above ensures that the CoAP Uri-Path-Abbrev Option and its value are going to be understood by RS, if C includes the Option in a CoAP request that carries a LAKE message and targets the well-known LAKE resource at the path /.well-known/edhoc. RS has to ensure that no requests can be performed on a LAKE resource other than for running the LAKE protocol. Specifically, on a LAKE resource, it SHOULD NOT be possible to perform any other operation than POST.

Forward Message Flow This section details the case where the LAKE forward message flow is used (see ), i.e., where C acts as the Initiator I and RS acts as the Responder R. Consistent with the LAKE forward message flow, C sends LAKE message_1 and LAKE message_3 to a LAKE resource at RS, as CoAP POST requests. RS sends LAKE message_2 and (optionally) LAKE message_4 as CoAP 2.04 (Changed) responses.

LAKE message_1 The processing of LAKE message_1 is as specified in , with the following additions:

• The LAKE method MUST be one of the LAKE methods specified in the "methods" field (if present) of the LAKE_Information object within the access token response received from AS, which AS sent to C when issuing the first access token of the token series (see ).
• The selected cipher suite MUST be one of the LAKE cipher suites specified in the "cipher_suites" field (if present) of the LAKE_Information object within the access token response received from AS, which AS sent to C when issuing the first access token of the token series (see ).

LAKE message_2 The processing of LAKE message_2 is as specified in , with the following additions:

• The authentication credential CRED_R specified by the message field ID_CRED_R is AUTH_CRED_RS.

LAKE message_3 The processing of LAKE message_3 is as specified in , with the following additions:

• The authentication credential CRED_I specified by the message field ID_CRED_I is AUTH_CRED_C.
• The EAD_3 field MUST include an EAD item that specifies the access token issued to C and bound to AUTH_CRED_C. According to this document, such EAD item is ACE-OAuth Access Token (see ), which specifies the access token by value. The EAD_3 field MUST NOT include multiple EAD items specifying the access token. If zero or more than one EAD items specifying the access token are included in the EAD_3 field, then RS MUST abort the LAKE session. RS MUST verify that the access token specified in the EAD item is valid. The validation follows the procedure specified in . If such validation fails, RS MUST reply to C with a LAKE error message with ERR_CODE = 1 (see ), and it MUST abort the LAKE session.

Reverse Message Flow This section details the case where the LAKE reverse message flow is used (see ), i.e., where C acts as the Responder R and RS acts as the Initiator I. Consistent with the LAKE reverse message flow, C sends a trigger message, LAKE message_2, and LAKE message_4 to RS as CoAP POST requests. RS sends LAKE message_1 and LAKE message_3 as CoAP 2.04 (Changed) responses. In this profile of ACE, if C/RS implements the LAKE reverse message flow, then C/RS MUST implement LAKE message_4. In particular, when using the LAKE reverse message flow, C MUST send LAKE message_4 after successfully completing the processing of the incoming LAKE message_3.

Trigger Message As specified in , the trigger message is a POST request with no payload that C sends to the LAKE resource at RS, intended to trigger a response conveying LAKE message_1. If the access token is issued for a group-audience (see ), then C can perform a LAKE "roll call", by sending the trigger message as a group request, e.g., over IP multicast . For the sake of efficiency, it is expected that the group-audience is appropriately associated with a CoAP group and/or application group (see ), so that only the resource servers belonging to the group-audience receive the trigger message. After that, C can receive a different LAKE message_1 from each of the targeted RSs and separately progresses the corresponding LAKE sessions, by sending a different LAKE message_2 to each RS that has replied with a LAKE message_1.

LAKE message_1 The processing of LAKE message_1 is as specified in .

LAKE message_2 The processing of LAKE message_2 is as specified in , with the following additions:

• The authentication credential CRED_R specified by the message field ID_CRED_R is AUTH_CRED_C.

LAKE message_3 The processing of LAKE message_3 is as specified in , with the following additions:

• The authentication credential CRED_I specified by the message field ID_CRED_I is AUTH_CRED_RS.

LAKE message_4 The processing of LAKE message_4 is as specified in , with the following additions:

• The EAD_4 field MUST include an EAD item that specifies the access token issued to C and bound to AUTH_CRED_C. According to this document, such EAD item is ACE-OAuth Access Token (see ), which specifies the access token by value. The EAD_4 field MUST NOT include multiple EAD items specifying the access token. If zero or more than one EAD items specifying the access token are included in the EAD_4 field, then RS MUST abort the LAKE session. RS MUST verify that the access token specified in the EAD item is valid. The validation follows the procedure specified in . If such validation fails, RS MUST reply to C with a LAKE error message with ERR_CODE = 1 (see ), and it MUST abort the LAKE session.

Timing of Access Token Request When C sends to AS an access token request for requesting the first access token of a token series (see ), the "req_cnf" parameter of the access token request specifies C's authentication credential AUTH_CRED_C to be bound to the access token and to be used as CRED_R in the LAKE session with RS. In particular, AUTH_CRED_C has to be consistent with the LAKE session run with RS, i.e., compatible with the LAKE authentication method and selected cipher suite used in that session. However, when using the LAKE reverse message flow, such information is effectively indicated by RS when sending LAKE message_1 to C. Therefore, C is generally not able to specify an appropriate AUTH_CRED_C to AS when requesting an access token as early as before sending the trigger message to RS. In the general case, the following applies.

• If C knows the right AS associated with RS before sending the trigger message, then C can send the access token request to AS as soon as it receives and successfully processes LAKE message_1 from RS. In particular, the "req_cnf" parameter of the access token request specifies the authentication credential AUTH_CRED_C that C uses in the ongoing LAKE session, as specified through ID_CRED_R of LAKE message_2 from C. The exchange of access token request/response between C and AS can occur in parallel with the exchange of LAKE message_2 and message_3 between C and RS. However, receiving an access token response from AS is required by C to complete the processing of LAKE message_3 from RS (unless C already stores RS' authentication credential AUTH_CRED_RS) and to compose LAKE message_4 to send to RS.
• If C does not know the right AS associated with RS before sending the trigger message, C can gain knowledge of such AS during the LAKE session, by including the EAD item Request Creation Hints in LAKE message_2 and retrieving the information specified by RS from the EAD item Request Creation Hints in LAKE message_3 (see ). Consequently, C can send the access token request to AS as soon as it receives LAKE message_3 from RS. In particular, the "req_cnf" parameter of the access token request specifies the authentication credential AUTH_CRED_C that C uses in the ongoing LAKE session and that was specified through ID_CRED_R of LAKE message_2 from C. Like in the previous case, receiving an access token response from AS is required by C to complete the processing of LAKE message_3 from RS (unless C already stores RS' authentication credential AUTH_CRED_RS) and to compose LAKE message_4 to send to RS.

If C knows the right AS associated with RS before sending the trigger message, there are however particular circumstances under which C is able to send the access token request to AS even before sending the trigger message to RS. For example:

• C owns only one authentication credential AUTH_CRED_C; or
• C knows in advance the LAKE authentication method and selected cipher suite that RS is going to indicate in LAKE message_1. Therefore, C can determine in advance an appropriate AUTH_CRED_C to bind to an access token and to specify in the access token request to AS.

Possible Conflicting Information from AS In the best-case scenario, C uses the LAKE forward message flow and knows the right AS associated with RS before sending LAKE message_1. Consequently, when requesting the first access token of a token series, C can first complete the access token request-response exchange with AS, and then send LAKE message_1 to RS, consistent with what AS specified within the LAKE_Information object of the access token response (see , , and ). In other scenarios, C has to request the first access token of a token series during an already ongoing LAKE session with RS, i.e.:

• When using the LAKE forward message flow without knowing in advance the right AS associated with RS, which C learns during the LAKE session through the EAD item Request Creation Hints (see ). That is, the access token request-response exchange with AS occurs after C has received LAKE message_2 from RS.
• When using the LAKE reverse message flow, as discussed in . That is, the access token request-response exchange with AS occurs after C has received LAKE message_1 or message_3 from RS, depending on whether or not C knows in advance the right AS associated with RS before sending the trigger message to RS.

In the scenarios above, the information that AS specifies within the LAKE_Information object of the access token response could contradict the already ongoing LAKE session between C and RS. With reference to the LAKE_Information object in the access token response, this particularly concerns:

• The URI path of the LAKE resource targeted in the session, which might differ from the one indicated by the "uri_path" field if present, or from the path /.well-known/edhoc otherwise.
• The LAKE method used in the session and indicated in LAKE message_1, which might not be indicated by the "methods" field (if present).
• The selected cipher suite used in the session and indicated in LAKE message_1, which might not be indicated by the "cipher_suites" field (if present).

When C receives the access token response from AS, if C detects any contradiction between the ongoing LAKE session with RS and the information specified in the received LAKE_Information object, C MUST reply to RS with a LAKE error message with ERR_CODE = 1 (see ), and it MUST abort the LAKE session. Note that such error message is sent in reply to:

• LAKE message_2, when using the LAKE forward message flow.
• LAKE message_1 or message_3, when using the LAKE reverse message flow, depending on whether or not C knows in advance the right AS associated with RS before sending the trigger message to RS.

After aborting the LAKE session, C can take advantage of the just issued access token and run a new LAKE session with RS as intended to be bound to that access token. The new session is run consistent with the received LAKE_Information object that was conveyed in the access token response from AS. In particular:

• If C decides to use the LAKE forward message flow, it sends LAKE message_1 consistent with the received LAKE_Information object.
• If C decides to use the LAKE reverse message flow, it sends the trigger message to RS consistent with the received LAKE_Information object. In practice, this is simply about sending the trigger message to the LAKE resource with URI path indicated by the "uri_path" field, if present in the LAKE_Information object, or with URI path /.well-known/edhoc otherwise.

OSCORE Security Context Once the LAKE session is successfully completed, C and RS derive an OSCORE Security Context as defined in . In addition, RS associates the latest LAKE session and the derived OSCORE Security Context with the stored access token, which is bound to the authentication credential AUTH_CRED_C used in the LAKE session. The access token is also associated with the pair (SESSION_ID, AUTH_CRED_C), where SESSION_ID is the identifier of the token series to which the access token belongs. If supported by C, C MAY use the LAKE + OSCORE combined request defined in (denoted therein as "EDHOC + OSCORE request"), unless the LAKE_Information object specified by the "lake_info" parameter of the access token response included the "comb_req" field encoding the CBOR simple value false (0xf4). In the combined request, both LAKE message_3 and the first OSCORE-protected application request are combined together in a single OSCORE-protected CoAP request, thus saving one round trip. This requires C to derive the OSCORE Security Context with RS already after having successfully processed the received LAKE message_2 and before sending LAKE message_3. An example is provided in .

Update of Access Rights If C has a valid OSCORE Security Context associated with a valid access token at RS, then C can request from AS an update of the access rights as described in . If the request is granted, then AS generates a new access token containing updated access rights for C (see ), in the same token series of the current access token (see ). According to this document, AS provides the new access token to C (see ) for further uploading to RS (see ). Alternatively, the new access token can be uploaded by AS directly to RS, as described in . If all validations are successful, C can access protected resources at RS according to the updated access rights, using the previously established OSCORE Security Context. The rest of this section describes the message exchange for the uploading of the new access token from C to RS.

C-to-RS: POST to /authz-info Endpoint C can update its access rights by uploading the updated access token to RS using CoAP and the Authorization Information endpoint as described in . 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 , the Content-Format of the POST request MUST be "application/cwt" to reflect the format of the transported access token. C MUST protect the POST request using the current OSCORE Security Context shared with RS. Upon receiving an access token from C, RS MUST follow the procedures defined in . That is, RS MUST verify the validity of the access token. RS MAY make an introspection request (see ) to validate the access token at AS. RS MUST check the following conditions:

• RS checks whether it stores an access token T_OLD, such that:
  • The "session_id" field of the LAKE_Information object specified by the "lake_info" claim matches the "session_id" field of the LAKE_Information object specified by the "lake_info" claim of the new access token T_NEW.
  • The authentication credential specified by the "cnf" claim matches the authentication credential specified by the "cnf" claim of the new access token T_NEW. Note that, in T_OLD and T_NEW, the same authentication credential can be transported by value or uniquely referred to by means of an appropriate identifier.
• 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, the new access token T_NEW supersedes T_OLD, i.e., RS MUST replace the authorization information specified in T_OLD with that specified in T_NEW, and it MUST associate T_NEW with the OSCORE Security Context CTX. Note that C and RS do not execute the LAKE protocol, they do not establish a new OSCORE Security Context, and AUTH_CRED_C remains the same.

RS-to-C: 2.01 (Created) If all validations are successful, RS stores the new access token in such a way that it is possible to retrieve it based on the pair (SESSION_ID, AUTH_CRED_C), where SESSION_ID is the identifier of the token series to which the access token belongs. Note that SESSION_ID is specified in the "session_id" field of the LAKE_Information object, within the "lake_info" claim of the access token. Then, RS MUST reply to the POST request by sending a 2.01 (Created) response with no payload. The response is protected with the same OSCORE Security Context used to protect the corresponding request. After that, C can access protected resources at RS according to the updated access rights, using the previously established OSCORE Security Context. Instead, if any validation fails, 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 , when receiving a valid access token with updated authorization information from C (see ), 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.

Discarding the OSCORE Security Context There are a number of cases where C or RS have to discard the OSCORE Security Context that they share, after which they can establish a new one (see ). 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 can happen, for example, due to lack of storage at RS, which then sends the "AS Request Creation Hints" message (see ).
• The authentication credential of C (of RS) becomes invalid, e.g., due to expiration or revocation, and it was used as AUTH_CRED_C (AUTH_CRED_RS) in the LAKE 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 AUTH_CRED_C (AUTH_CRED_RS) in the LAKE 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.

Establishing a New OSCORE Security Context The procedure for provisioning a new access token to RS specified in this section applies to various cases where an OSCORE Security Context shared between C and RS has been deleted, for example as described in . Another exceptional case is that where 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 MAY alternatively attempt to run a key update protocol that they both support. One lightweight example is KUDOS , which is independent of ACE and LAKE and does not require the uploading of an access token. If C and RS do not support a common key update protocol to use for updating their still valid OSCORE Security Context, then C and RS fall back to running LAKE. Regardless of whether a valid Security Context is available, if the access token is still valid, C and RS can rerun LAKE to perform session resumption with PSK-based authentication , assuming that they support session resumption and the underlying LAKE authentication method. When doing so, the access token is not specified in the LAKE messages sent to RS. Also, consistent with , the previous LAKE session and the OSCORE Security Context derived thereof are deleted, and the new LAKE session becomes associated with the same pair (SESSION_ID, AUTH_CRED_C) that was associated with the previous session. Note that AUTH_CRED_C is the authentication credential of C that is bound to the access token and that C used for its initial authentication based on public keys. 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-uploaded) access token. Furthermore, the SESSION_ID identifying the token series to which the access token belongs remains unchanged, even if C and RS have established a new LAKE session. Unless C and RS re-run the LAKE protocol, they preserve their OSCORE identifiers, i.e., their OSCORE Sender/Recipient IDs.

Access Rights Verification RS MUST follow the procedures defined in . That is, if RS receives an OSCORE-protected request targeting a protected resource from C, then RS processes the request according to . 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.

Access Token Invalidity When an access token becomes invalid (e.g., due to its expiration or revocation), the following applies:

• RS MUST delete the access token and the associated OSCORE Security Context.
• RS MUST abort and purge the LAKE session from which the deleted OSCORE Security Context was derived.
• RS notifies C with a 4.01 (Unauthorized) error response for any long-running request, as specified in .

Authentication Credential Invalidity If an authentication credential AUTH_CRED_C of C is invalidated (e.g., it expires), then the following applies:

• RS MUST delete all the stored access tokens that specify AUTH_CRED_C in the "cnf" claim.
• C MUST delete every stored access token such that, when C requested the first access token of the same series, the access token request to AS specified AUTH_CRED_C (see ).
• RS and C MUST abort and purge all the LAKE sessions that used AUTH_CRED_C and successfully completed. Also, RS and C MUST delete the OSCORE Security Contexts derived from those sessions (see ).

If an authentication credential AUTH_CRED_RS of RS is invalidated (e.g., it expires), then the following applies:

• C MUST delete every stored access token such that, when C requested the first access token of the same series, the access token response from AS specified AUTH_CRED_RS (see ).
• C MUST delete every stored access token that C specified during a LAKE session that used AUTH_CRED_RS and successfully completed.
• RS and C MUST abort and purge all the LAKE sessions that used AUTH_CRED_RS and successfully completed. Also, RS and C MUST delete the OSCORE Security Contexts derived from those sessions (see ).

LAKE Session Invalidity If a LAKE session is aborted and purged for other reasons than those listed in , then RS and C that established the session MUST delete the OSCORE Security Context derived from that session (see ).

Using AS Request Creation Hints When replying to an unauthorized resource request message from a client, RS can send an unprotected AS Request Creation Hints message as a 4.01 (Unauthorized) error response (see ). The message payload can specify a number of parameters that help the sender client acquire a valid access token from AS. These parameters include "audience" and "scope". If RS supports the LAKE reverse message flow and sends an unprotected AS Request Creation Hints message, the following applies:

• The message payload MUST NOT include the "audience" parameter.
• The message payload SHOULD NOT include the "scope" parameter, unless its value cannot contribute to expose the identity of RS.

This ensures that, if LAKE is run per its reverse message flow (see ), the protection of RS' identity against active attackers is not defeated by exposing information about RS such as audience and scope. AS Request Creation Hints can also be requested and retrieved by means of the EAD item Request Creation Hints defined in this section. The CDDL grammar for the EAD item is shown in and its ead_label is registered in . An example of its usage is provided in .

EAD item Request Creation Hints. any } ]]>

This EAD item is intended to be used in EAD fields of LAKE messages exchanged between C and RS as follows:

• In EAD_1 and EAD_2, when using the LAKE forward message flow.
• In EAD_2 and EAD_3, when using the LAKE reverse message flow.

In the first LAKE message from C to RS, the EAD item has no ead_value and asks RS to include the same EAD item in the next LAKE message. In the first LAKE message from RS to C, the EAD item has ead_value. In particular, ead_value is a CBOR byte string whose value encodes the CBOR map that is used as payload in an unprotected AS Request Creation Hints message (see ). The keys of the CBOR map are defined in the IANA registry "ACE Authorization Server Request Creation Hints" . This EAD item is non-critical, i.e., it can be ignored by the recipient peer. The EAD item is OPTIONAL to implement. Example: assuming ead_label 1 and the AS Request Creation Hints CBOR map containing one element with key 1 and with value the CBOR text string encoding "coap://www.example.com/token" (i.e., the absolute URI of the /token endpoint at AS), the non-critical EAD item in the first LAKE message from RS to C is as follows: Note to RFC Editor: Please replace the value of the ead_label with the value registered for Request Creation Hints in , then delete this note. Since C has not made an actual request targeting a specific application resource, RS may not know what resource C is interested in accessing. Moreover, such information needs to be matched against the privacy policy of the application. Since LAKE message_2 is only protected against passive attackers, the AS Request Creation Hints CBOR map MUST NOT include "audience" and SHOULD NOT include "scope" when present in the EAD item conveyed in the EAD_2 field.

Requesting Authentication Credential By Value LAKE peers need access to each other's authentication credentials to complete the protocol. To reduce unnecessary overhead, LAKE allows identifying credentials by reference alternatively to transporting them by value. The ACE protocol includes the initial transport of authentication credentials of C and RS by value, and thus it matches the identification of credentials by reference in LAKE. However, if one of the peers has deleted the other peer's authentication credential from its local storage, then there should be a way to restore it without requesting a new access token. Consider first the LAKE forward message flow. If the ACE client / LAKE Initiator identifies its credential AUTH_CRED_C by reference in ID_CRED_I of message_3, then the ACE resource server / LAKE Responder can return a LAKE error message with error code (ERR_CODE) 3 "Unknown credential referenced". This enables the Initiator to restart the protocol using some other ID_CRED_I (typically, the authentication credential AUTH_CRED_C specified by value), thereby resolving the issue. Instead, if the ACE resource server / LAKE Responder identifies its credential AUTH_CRED_RS by reference in ID_CRED_R of message_2, then a LAKE error message with error code (ERR_CODE) 3 "Unknown credential referenced" returned by the ACE client / LAKE Initiator does not automatically solve the problem: since the Responder has aborted the LAKE session without authenticating the Initiator, the Responder has no reliable way to act differently in a following LAKE session with that other peer. In order to remedy this situation, this section specifies the EAD item Credential By Value for requesting the peer's authentication credential by value. The CDDL grammar for the EAD item is shown in and its ead_label is registered in . An example of its usage is provided in .

EAD item Credential By Value.

This EAD item has no ead_value, and it can be used in the EAD_1 field of LAKE message_1 and in the EAD_2 field of LAKE message_2. When present in EAD_1, the EAD item requests the Responder to specify its authentication credential by value in ID_CRED_R of LAKE message_2. When present in EAD_2, the EAD item requests the Initiator to specify its authentication credential by value in ID_CRED_I of LAKE message_3. This EAD item is non-critical, i.e., it can be ignored by the recipient peer. The EAD item is OPTIONAL to implement. Example: assuming ead_label 15, the non-critical EAD item is as follows: Note to RFC Editor: Please replace the value of the ead_label with the value registered for Credential By Value in , then delete this note. In the LAKE reverse message flow, this EAD item can be employed for better control of the transport of authentication credentials by value. Note that, in the reverse message flow, both C and RS are able to recover from a LAKE error message with error code (ERR_CODE) 3 "Unknown credential referenced", but at the cost of more round trips that can be avoided by using this EAD item. That is:

• The first case consists in the ACE client / LAKE Responder that specifies its authentication credential AUTH_CRED_C by reference in ID_CRED_R of message_2 and receives a LAKE error message with error code (ERR_CODE) 3 "Unknown credential referenced" as a reply from the ACE resource server / LAKE Initiator. After that, the ACE client / LAKE Responder can trigger a new LAKE session and specify its authentication credential by value in ID_CRED_R of message_2.
• The second case consists in the ACE resource server / LAKE Initiator that specifies its authentication credential AUTH_CRED_RS by reference in ID_CRED_I of message_3 and receives an LAKE error message with error code (ERR_CODE) 3 "Unknown credential referenced" as a reply from the ACE client / LAKE Responder. After that, since the ACE resource server / LAKE Initiator authenticated C, it can store C's authentication credential AUTH_CRED_C and specify its own authentication credential AUTH_CRED_RS by value in ID_CRED_I of message_3, during the next LAKE session with C.

Secure Communication with AS As specified in the ACE framework (see Sections and of ), the requesting entity (RS and/or C) and AS communicate via the /token or /introspect endpoint. When using this profile, the use of CoAP and OSCORE for this communication is RECOMMENDED, in order to reduce the number of libraries that C and RS have to support. Other protocols fulfilling the security requirements defined in Sections and of (such as HTTP and DTLS or TLS ) MAY be used instead. If OSCORE is used, the requesting entity and AS need to have an OSCORE Security Context in place. While this can be pre-installed, the requesting entity and AS can establish such an OSCORE Security Context, for example, by running the LAKE protocol, as shown between C and AS by the examples in . This also applies to the communication between RS and AS, for example to protect the upload of access tokens from AS directly to RS as described in .

Use with Application Profiles of ACE for Group Key Provisioning The LAKE and OSCORE profile specified in the present document can be used in combination with application profiles of ACE for key provisioning for group communication , such as and . When doing so, the LAKE and OSCORE profile is used by a client that wants to join a security group and by an RS that acts as the Key Distribution Center (KDC) responsible for that group. According to what is defined in the present document, the client does not upload the first access token of a token series to the /authz-info endpoint at RS over an unprotected channel. Consequently, the client does not obtain the N_S challenge from RS acting as KDC (see ). Therefore, when using the LAKE and OSCORE profile in combination with one of the application profiles of mentioned above, the following holds for computing the N_S challenge used in such application profiles.

• In the ACE application profile specified in , when the provisioning of the access token to the Group Manager (i.e., the KDC) has relied on the LAKE and OSCORE profile of ACE specified in the present document and the access token was specified in the EAD item ACE-OAuth Access Token (see ), then N_S is derived using the EDHOC_Exporter interface defined in . Specifically, N_S is exported from the LAKE session associated with the access token and established between the client and the Group Manager. The following is provided as input to the EDHOC_Exporter interface:
  • The 'exporter_label' parameter is the unsigned integer EXPORTER_LABEL_TBD_26, which is registered in of the present document.
  • The 'context' parameter is h'' (0x40), i.e., the empty CBOR byte string.
  • The 'length' parameter is 32, i.e., the intended length of N_S in bytes.
• In the ACE application profile specified in , when the provisioning of the access token to the KDC has relied on the LAKE and OSCORE profile of ACE specified in the present document and the access token was specified in the EAD item ACE-OAuth Access Token (see ), then N_S is derived using the EDHOC_Exporter interface defined in . Specifically, N_S is exported from the LAKE session associated with the access token and established between the client and the KDC. The following is provided as input to the EDHOC_Exporter interface:
  • The 'exporter_label' parameter is the unsigned integer EXPORTER_LABEL_TBD_27, which is registered in of the present document.
  • The 'context' parameter is h'' (0x40), i.e., the empty CBOR byte string.
  • The 'length' parameter is 32, i.e., the intended length of N_S in bytes.

CWT Confirmation Methods This document defines a number of new CWT confirmation methods, which are registered in . The semantics of each confirmation method is defined below.

Ordered Chain of X.509 Certificates The confirmation method "x5chain" specifies an ordered array of X.509 certificates . The semantics of "x5chain" is like that of the "x5chain" COSE Header Parameter specified in .

Unordered Bag of X.509 Certificates The confirmation method "x5bag" specifies a bag of X.509 certificates . The semantics of "x5bag" is like that of the "x5bag" COSE Header Parameter specified in .

Hash of an X.509 Certificate The confirmation method "x5t" specifies the hash value of the end-entity X.509 certificate . The semantics of "x5t" is like that of the "x5t" COSE Header Parameter specified in .

URI Pointing to an X.509 Certificate The confirmation method "x5u" specifies a URI that identifies an X.509 certificate . The semantics of "x5u" is like that of the "x5u" COSE Header Parameter specified in .

Ordered Chain of C509 Certificates The confirmation method "c5c" specifies an ordered array of C509 certificates . The semantics of "c5c" is like that of the "c5c" COSE Header Parameter specified in .

Unordered Bag of C509 Certificates The confirmation method "c5b" specifies a bag of C509 certificates . The semantics of "c5b" is like that of the "c5b" COSE Header Parameter specified in .

Hash of a C509 Certificate The confirmation method "c5t" specifies the hash value of the end-entity C509 certificate . The semantics of "c5t" is like that of the "c5t" COSE Header Parameter specified in .

URI Pointing to a C509 Certificate The confirmation method "c5u" specifies a URI that identifies a C509 certificate . The semantics of "c5u" is like that of the "c5u" COSE Header Parameter specified in .

CWT Containing a COSE_Key The confirmation method "kcwt" specifies a CWT containing a COSE_Key in a "cnf" claim and possibly other claims. The semantics of "kcwt" is like that of the "kcwt" COSE Header Parameter specified in .

CCS Containing a COSE_Key The confirmation method "kccs" specifies a CCS containing a COSE_Key in a "cnf" claim and possibly other claims. The semantics of "kccs" is like that of the "kccs" COSE Header Parameter specified in .

JWT Confirmation Methods This document defines a number of new JWT confirmation methods, which are registered in . The semantics of each confirmation method is defined below.

Ordered Chain of X.509 Certificates The confirmation method "x5c" specifies an ordered array of X.509 certificates . The semantics of "x5c" is like that of the "x5c" JSON Web Signature and Encryption Header Parameter specified in , 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.

Unordered Bag of X.509 Certificates The confirmation method "x5b" specifies a bag of X.509 certificates . The semantics of "x5b" is like that of the "x5c" JWT confirmation method defined in , 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 .

Hash of an X.509 Certificate The confirmation method "x5t" specifies the hash value of the end-entity X.509 certificate . The semantics of "x5t" is like that of the "x5t" JSON Web Signature and Encryption Header Parameter specified in .

URI Pointing to an X.509 Certificate The confirmation method "x5u" specifies a URI that identifies an X.509 certificate . It specifies a JSON string, with value the URI. The semantics of "x5u" is like that of the "x5u" COSE Header Parameter specified in , with the following difference. The public key contained in the X.509 certificate is the proof-of-possession key and does not have to correspond to a key used to digitally sign the JWS.

Ordered Chain of C509 Certificates The confirmation method "c5c" specifies an ordered array of C509 certificates . The semantics of "c5c" is like that of the "x5c" JWT confirmation method defined in , with the following difference. Each string in the JSON array is the base64-encoding ( - not base64url-encoding) of the binary representation of a C509 certificate.

Unordered Bag of C509 Certificates The confirmation method "c5b" specifies a bag of C509 certificates . The semantics of "c5b" is like that of the "c5c" JWT confirmation method defined in , 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 .

Hash of a C509 Certificate The confirmation method "c5t" specifies the hash value of the end-entity C509 certificate . The semantics of "c5t" is like that of the "x5t" JWT confirmation method defined in , 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.

URI Pointing to a C509 Certificate The confirmation method "c5u" specifies a URI that identifies a C509 certificate . It specifies a JSON string, with value the URI. The semantics of "c5u" is like that of the "x5u" JWT confirmation method defined in , with the following differences. First, the URI refers to a resource for the C509 certificate. Second, the public key contained in the C509 certificate and acting as proof-of-possession key does not have to correspond to a key used to digitally sign the JWS.

CWT Containing a COSE_Key The confirmation method "kcwt" specifies a CWT containing a COSE_Key in a "cnf" claim and possibly other claims. It specifies a JSON string, with value the base64url-encoding () of the binary representation of the CWT.

CCS Containing a COSE_Key The confirmation method "kccs" specifies a CCS containing a COSE_Key in a "cnf" claim and possibly other claims. It specifies a JSON string, with value the base64url-encoding () of the binary representation of the CCS.

LAKE Trust Anchor Purposes This document defines the following LAKE trust anchor purpose. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. LAKE Trust Anchor Purposes

Name	CBOR label	Description	Reference
lake_cred	0	Verifying authentication credentials of other LAKE peers in LAKE sessions	[RFC-XXXX]

Trust anchors with purpose "lake_cred" are used for verifying authentication credentials of other LAKE peers in a LAKE session, and they typically are authentication credentials of Certificate Authorities (CAs).

LAKE Trust Anchor Types This document defines the following LAKE trust anchor types. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. LAKE Trust Anchor Types

Name	CBOR label	Value type	Description	Reference
uuid	0	#6.37(bstr)	Binary CBOR-encoded UUID	[RFC-XXXX]
kid	4	bstr	Key identifier	[RFC-XXXX]
c5t	22	COSE_CertHash	Hash of a C509 certificate	[RFC-XXXX][draft-ietf-cose-cbor-encoded-cert]
c5u	23	uri	URI pointing to a C509 certificate	[RFC-XXXX][draft-ietf-cose-cbor-encoded-cert]
x5t	34	COSE_CertHash	Hash of an X.509 certificate	[RFC-XXXX]
x5u	35	uri	URI pointing to an X.509 certificate	[RFC-XXXX]

Operational Considerations In addition to the considerations already discussed in this document, this section compiles additional operational considerations that hold for this document.

RS Belonging to Multiple Audiences with Different Authentication Credentials It is possible that RS supports multiple LAKE cipher suites and methods. In such case, it could happen that RS has different authentication credentials, each consistent with one or more supported combinations of cipher suites and methods. For example, if RS supports LAKE cipher suites 0 and 2 as well as methods 0 and 3, RS needs to have the following authentication credentials:

• One credential using EdDSA with curve Ed25519 for method 0.
• One credential using ECDSA with curve P-256 for method 0.
• One credential using ECDSA with curve P-256 for method 3.
• One credential using X25519 for method 3.

To allow AS to select the appropriate authentication credential of RS when composing the access token response to C (see ), RS should belong to a different audience for each of its authentication credentials. When C requests an access token from AS (see ), it specifies an audience corresponding to an authentication credential of RS that is compatible with the authentication credential of C specified in the access token request. This means that, prior to requesting an access token, C has to determine which LAKE cipher suites and methods RS supports and the corresponding audience values. The discovery of RS' capabilities can rely on pre-configuration or on mechanisms defined in . The knowledge of audience values can be pre-configured.

Keeping Information About C and RS Up-to-Date at AS In this profile, the LAKE_Information object is built by AS to guide C and RS towards executing the LAKE protocol. Note that, when AS builds a LAKE_Information object intended for C (included in an access token response) or RS (included in an access token), the object must specify information that is aligned with the capabilities of C and RS, to the best of AS' knowledge. In practice, this means that it is important that the information that AS has about C and RS is kept up-to-date, to reflect what C and RS support as LAKE peers. The means that AS uses to achieve this are out of scope for this document.

Security Considerations This document specifies a profile for the ACE framework . Thus, the general security considerations from the ACE framework also apply to this profile. Furthermore, the security considerations from OSCORE and from LAKE also apply to this specific use of the OSCORE and LAKE protocols. Proof of possession is achieved by RS during the LAKE session, as soon as both the following conditions hold. The LAKE message flow used by C and RS determines when the two conditions are met during the LAKE session at the earliest.

• RS has received from C the LAKE message that specifies the access token, which in turn is bound to and specifies C's authentication credential AUTH_CRED_C; and
• RS has authenticated C as per AUTH_CRED_C, thereby proving that C owns the private key corresponding to the public key associated with AUTH_CRED_C.

As previously stated, once completed the LAKE session, C and RS are mutually authenticated through their respective authentication credentials, whose retrieval has been facilitated by AS. Also, once completed the LAKE session, C and RS have established a long-term secret key PRK_out enjoying forward secrecy. This is in turn used by C and RS to establish an OSCORE Security Context. When using the LAKE forward message flow (see ), RS achieves confirmation that C has PRK_out when receiving and successfully processing LAKE message_3 from C. Instead, C achieves confirmation that RS has PRK_out when receiving and successfully processing the optional LAKE message_4 from RS, or when receiving and successfully verifying a response from RS protected with the established OSCORE Security Context. When using the LAKE reverse message flow (see ), RS achieves confirmation that C has PRK_out when receiving and successfully processing LAKE message_4 from C. Instead, C achieves confirmation that RS has PRK_out when receiving and successfully processing LAKE message_3 from RS. OSCORE is designed to secure point-to-point communication, providing a secure binding between a request and the corresponding response(s). Thus, the basic OSCORE protocol is not intended for use in point-to-multipoint communication (e.g., enforced via multicast or a publish-subscribe model). Implementers of this profile should make sure that their use case of OSCORE corresponds to the expected one, in order to prevent weakening the security assurances provided by OSCORE. When using this profile, it is RECOMMENDED that RS stores only one access token per client. The use of multiple access tokens for a single client increases the strain on RS, since it must consider every access token associated with the client and calculate the actual permissions that the client has. Also, access tokens indicating different or disjoint permissions from each other may lead RS to enforce wrong permissions. If one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection. Developers SHOULD avoid using multiple access tokens for the same client. Furthermore, with reference to access tokens issued in accordance with this profile, RS MUST NOT store more than one access token per client per PoP-key (i.e., per client's authentication credential). This profile defines the confirmation methods "kcwt" and "kccs" corresponding to the use of CWTs and CCSs, respectively. Security considerations for CWTs and CCSs and for the COSE header parameters "kcwt" and "kccs" are given in , and they also apply to the corresponding confirmation methods defined in and of this document. In particular, the contents of the CWT or CCS must be processed as untrusted input. The application needs to define a trust-establishment mechanism and identify the relevant trust anchors.

Privacy Considerations This document specifies a profile for the ACE framework . Thus, the general privacy considerations from the ACE framework also apply to this profile. Furthermore, the privacy considerations from OSCORE and from LAKE also apply to this specific use of the OSCORE and LAKE protocols. An unprotected response to an unauthorized request may disclose information about RS and/or its existing relationship with C. It is advisable to include as little information as possible in an unencrypted response from RS (see also ). When an OSCORE Security Context already exists between C and RS, more detailed information may be included in a protected response from RS. The (encrypted) access token is never sent in an unprotected POST request to the /authz-info endpoint at RS. Thus, even if C uses the same single access token from multiple locations, the access token's value does not contribute to the risk of C being tracked. The identifiers used in OSCORE, i.e., the OSCORE Sender/Recipient IDs, are negotiated by C and RS during the execution of LAKE. When using the LAKE forward (reverse) message flow:

• The LAKE Connection Identifier C_I (C_R) of C is going to be the OSCORE Recipient ID of C, i.e., the OSCORE Sender ID of RS.
• The LAKE Connection Identifier C_R (C_I) of RS is going to be the OSCORE Recipient ID of RS, i.e., the OSCORE Sender ID of C.

These OSCORE identifiers are privacy sensitive (see ). In particular, they could reveal information about C or may be used for correlating different requests from C, e.g., across different networks that C has joined and left over time. This can be mitigated if C and RS dynamically update their OSCORE identifiers (e.g., by using the method defined in ), or if C and RS obfuscate their OSCORE identifiers in their OSCORE-protected messages (e.g., by using the method defined in ).

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

ACE Profiles Registry IANA is asked to add the following entry to the "ACE Profiles" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in .

• Name: coap_lake_oscore
• Description: Profile for delegating client authentication and authorization in a constrained environment by establishing an OSCORE Security Context between resource-constrained nodes, through the execution of the LAKE protocol .
• CBOR Value: TBD (value between 1 and 23)
• Reference: [RFC-XXXX]

OAuth Parameters Registry IANA is asked to add the following entry to the "OAuth Parameters" registry within the "OAuth Parameters" registry group.

• Name: lake_info
• Parameter Usage Location: token request and token response
• Change Controller: IETF
• Reference: [RFC-XXXX]

OAuth Parameters CBOR Mappings Registry IANA is asked to add the following entry to the "OAuth Parameters CBOR Mappings" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in .

• Name: lake_info
• CBOR Key: TBD (value between 1 and 255)
• Value Type: map
• Reference: [RFC-XXXX]
• Original Specification: [RFC-XXXX]

JSON Web Token Claims Registry IANA is asked to add the following entry to the "JSON Web Token Claims" registry within the "JSON Web Token (JWT)" registry group, following the procedure specified in .

• Claim Name: lake_info
• Claim Description: Information for LAKE session
• Change Controller: IETF
• Reference: [RFC-XXXX]

CBOR Web Token (CWT) Claims Registry IANA is asked to add the following entry to the "CBOR Web Token (CWT) Claims" registry within the "CBOR Web Token (CWT) Claims" registry group, following the procedure specified in .

• Claim Name: lake_info
• Claim Description: Information for LAKE session
• JWT Claim Name: lake_info
• Claim Key: TBD (value between 1 and 255)
• Claim Value Type: map
• Change Controller: IETF
• Reference: [RFC-XXXX]

JWT Confirmation Methods Registry IANA is asked to add the following entries to the "JWT Confirmation Methods" registry within the "JSON Web Token (JWT)" registry group, following the procedure specified in .

• Confirmation Method Value: x5c
• Confirmation Method Description: An ordered chain of X.509 certificates
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Value: x5b
• Confirmation Method Description: An unordered bag of X.509 certificates
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Value: x5t
• Confirmation Method Description: Hash of an X.509 certificate
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Value: x5u
• Confirmation Method Description: URI pointing to an X.509 certificate
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Value: c5c
• Confirmation Method Description: An ordered chain of C509 certificates
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Value: c5b
• Confirmation Method Description: An unordered bag of C509 certificates
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Value: c5t
• Confirmation Method Description: Hash of a C509 certificate
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Value: c5u
• Confirmation Method Description: URI pointing to a C509 certificate
• Change Controller: IETF
• Reference: 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: 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: of [RFC-XXXX]

CWT Confirmation Methods Registry IANA is asked to add the following entries to the "CWT Confirmation Methods" registry within the "CBOR Web Token (CWT) Claims" registry group, following the procedure specified in .

• Confirmation Method Name: x5chain
• Confirmation Method Description: An ordered chain of X.509 certificates
• JWT Confirmation Method Name: x5c
• Confirmation Key: TBD (value between 24 and 255)
• Confirmation Value Type: COSE_X509
• Change Controller: IETF
• Reference: 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 (value between 24 and 255)
• Confirmation Value Type: COSE_X509
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Name: x5t
• Confirmation Method Description: Hash of an X.509 certificate
• JWT Confirmation Method Name: x5t
• Confirmation Key: TBD (value between 1 and 23)
• Confirmation Value Type: COSE_CertHash
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Name: x5u
• Confirmation Method Description: URI pointing to an X.509 certificate
• JWT Confirmation Method Name: x5u
• Confirmation Key: TBD (value between 24 and 255)
• Confirmation Value Type: uri
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Name: c5c
• Confirmation Method Description: An ordered chain of C509 certificates
• JWT Confirmation Method Name: c5c
• Confirmation Key: TBD (value between 24 and 255)
• Confirmation Value Type: COSE_C509
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Name: c5b
• Confirmation Method Description: An unordered bag of C509 certificates
• JWT Confirmation Method Name: c5b
• Confirmation Key: TBD (value between 24 and 255)
• Confirmation Value Type: COSE_C509
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Name: c5t
• Confirmation Method Description: Hash of a C509 certificate
• JWT Confirmation Method Name: c5t
• Confirmation Key: TBD (value between 1 and 23)
• Confirmation Value Type: COSE_CertHash
• Change Controller: IETF
• Reference: of [RFC-XXXX]

• Confirmation Method Name: c5u
• Confirmation Method Description: URI pointing to a C509 certificate
• JWT Confirmation Method Name: c5u
• Confirmation Key: TBD (value between 24 and 255)
• Confirmation Value Type: uri
• Change Controller: IETF
• Reference: 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 (value between 1 and 23)
• Confirmation Value Type: COSE_Messages
• Change Controller: IETF
• Reference: 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 (value between 1 and 23)
• Confirmation Value Type: map / #6(map)
• Change Controller: IETF
• Reference: of [RFC-XXXX]

EDHOC External Authorization Data Registry IANA is asked to add the following entries to the "EDHOC External Authorization Data" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.

• Name: ACE-OAuth Access Token
• Label: TBD (value between 24 and 255)
• Description: An Access Token as used in the ACE-OAuth framework
• Reference: [RFC-XXXX],

• Name: Credential By Value
• Label: TBD (value between 1 and 23)
• Description: The sender peer wishes to receive the other peer's credential transported by value (and not identified by reference)
• Reference: [RFC-XXXX],

• Name: Request Creation Hints
• Label: TBD (value between 1 and 23)
• Description: Request or convey AS Request Creation Hints
• Reference: [RFC-XXXX],

EDHOC Exporter Labels IANA is asked to register the following entries in the "EDHOC Exporter Labels" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.

• Label: 26 (suggested value)
• Description: Derived N_S challenge for key provisioning for Group OSCORE using the ACE framework .
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Label: 27 (suggested value)
• Description: Derived N_S challenge for key provisioning for CoAP Pub-Sub using the ACE framework .
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

LAKE Information Registry IANA is requested to create a new "LAKE Information" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in . The registration policy is either "Private Use", "Standards Action with Expert Review", "Specification Required" per , or "Expert Review" per . "Expert Review" guidelines are provided in . All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per , with Expert Review additionally required per . The procedure for early IANA allocation of Standards Track code points defined in also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in . The columns of the registry are:

• Name: A descriptive name that enables easier reference to this item. These names MUST be unique. 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 text 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 the item.
• Type: The category of the item, i.e., P if prescriptive or NP if non-prescriptive (see ).
• Specification: A pointer to the public specification for the item, if one exists.

This registry has been initially populated with the entries in . In the "Specification" column, the value for all those entries includes [RFC-XXXX] and .

LAKE Trust Anchor Purposes Registry IANA is requested to create a new "LAKE Trust Anchor Purposes" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in . The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per . "Expert Review" guidelines are provided in . All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per , with Expert Review additionally required per . The procedure for early IANA allocation of Standards Track code points defined in also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in . The columns of this registry are:

• Name: This field contains the descriptive name of the trust anchor purpose, to enable easier reference to the item. These names MUST be unique.
• CBOR label: This field contains the value used to identify the trust anchor purpose. These values MUST be unique. The value can be an unsigned integer or a negative integer. Different ranges of values use different registration policies:
  • Integer values from -24 to 23 are designated as "Standards Action with Expert Review".
  • Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required".
  • Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".
• Description: This field contains a short description of the trust anchor purpose.
• Reference: This field contains a pointer to the public specification for the trust anchor purpose.

This registry has been initially populated with the entry in .

LAKE Trust Anchor Types Registry IANA is requested to create a new "LAKE Trust Anchor Types" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in . The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per . "Expert Review" guidelines are provided in . All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per , with Expert Review additionally required per . The procedure for early IANA allocation of Standards Track code points defined in also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in . The columns of this registry are:

• Name: This field contains the descriptive name of the type of trust anchor, to enable easier reference to the item. These names MUST be unique.
• CBOR label: This field contains the value used to identify the type of trust anchor. These values MUST be unique. The value can be an unsigned integer or a negative integer. Different ranges of values use different registration policies:
  • Integer values from -24 to 23 are designated as "Standards Action with Expert Review".
  • Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required".
  • Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".
• Value type: This field contains the CBOR type for the value portion of the label.
• Description: This field contains a short description of the type of trust anchor.
• Reference: This field contains a pointer to the public specification for the type of trust anchor.

This registry has been initially populated with the entries in .

Expert Review Instructions "Standards Action with Expert Review", "Specification Required", and "Expert Review" are three of the registration policies defined for the IANA registries established in this document. 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:

• Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts need to make sure that the object of registration is clearly defined in the corresponding specification. Entries that do not meet these objectives of clarity and completeness must not be registered.
• 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 with Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. 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. Documents published via Standards Action can also register points outside the Standards Action 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.

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members that act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as the Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO Inc. This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. Sandelman Software Works Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus using (relatively verbose) well-known URI paths. This document introduces the Uri-Path-Abbrev CoAP option that allows expressing well-known URI paths in as little as two bytes. Using this option revealed a subtle flaw in RFC7252 that severely limited the extension point of critical options. This document updates RFC7252 to rectify that. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. Ericsson Brunel University RISE AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. Inria Ericsson Ericsson University of Murcia University of Murcia This document specifies a Pre-Shared Key (PSK) authentication method for the Lightweight Authenticated Key Exchange (LAKE) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection, and quantum resistance while incurring lower computational costs than the public-key authentication methods specified for LAKE. It is suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous LAKE session (resumption PSK). This document details the PSK message flow, key derivation changes, message formatting, processing, and security considerations. IANA IANA IANA IANA IANA IANA IANA IANA IANA IANA IANA IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB This document updates the Authentication and Authorization for Constrained Environments framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when Concise Binary Object Representation (CBOR) is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. RISE AB RISE AB Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. RISE AB RISE AB Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. Ericsson AB Ericsson AB INRIA INRIA Sandelman Software Works Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. Ericsson AB RISE Nexus Inria Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. ASSA ABLOY Ericsson This document defines a format for transport of hints about Trust Anchors of trusted third parties when using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). RISE AB RISE AB The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, in order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. RISE AB RISE AB Ericsson AB This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information that pertains to the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving the access token. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA ISI, R.C. ATHENA This document specifies extensions to the Lightweight Authenticated Key Exchange (LAKE) protocol, formerly known as Ephemeral Diffie- Hellman over COSE (EDHOC), to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) Key Encapsulation Mechanisms (KEMs) for both key exchange and authentication. It defines a new signature-free KEM-based authentication method in which both parties authenticate using KEMs, enabling quantum-resistant authentication without relying on digital signatures when PQC KEMs, such as the NIST-standardized ML-KEM, are used. RISE AB Ericsson AB RISE AB Ericsson AB The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE Option, where the "Partial IV" field specifies the sequence number value used by the message sender and the "kid" field specifies the identifier of the message sender. In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document defines a lightweight add-on method that obfuscates certain fields of the OSCORE Option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand-in identifier. Therefore, it updates RFC 8613. With minor adaptations, the defined method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP.

Examples This appendix provides examples where this profile of ACE is used. In particular:

• does not make use of any optimization.
• makes use of the optimizations defined in , hence reducing the round trips of the interactions between C and AS as well as between C and RS.
• makes use of the EAD items Request Creation Hints (see ) and Credential By Value (see ), with the former allowing C to receive AS Request Creation Hints during a LAKE session. This is useful if C is not able to determine in advance the appropriate AS to contact.

All these examples build on the following assumptions, as relying on expected early procedures performed at AS. These include the registration of resource servers by the respective resource owners, as well as the registrations of clients authorized to request access tokens for accessing protected resources at those resource servers.

• AS knows the authentication credential AUTH_CRED_C of C.
• C knows the authentication credential AUTH_CRED_AS of AS.
• AS knows the authentication credential AUTH_CRED_RS of RS.
• RS knows the authentication credential AUTH_CRED_AS of AS. This is relevant in the case that AS and RS actually require a secure association (e.g., for RS to perform token introspection at AS, or for AS to upload an access token to RS on behalf of C as defined in ).

As a result of the assumptions above, it is possible to limit the transport of AUTH_CRED_C and AUTH_CRED_RS by value only to the following two cases, and only when C requests an access token for RS for the first time when considering the pair (AUTH_CRED_C, AUTH_CRED_RS).

• In the access token response from AS to C, where AUTH_CRED_RS is specified by the "rs_cnf" parameter.
• In the access token, where AUTH_CRED_C is specified by the "cnf" claim.

Note that, even under the circumstance mentioned above, AUTH_CRED_C might rather be identified by reference. This is possible if RS can effectively use such a reference from the access token to retrieve AUTH_CRED_C (e.g., from a trusted repository of authentication credentials reachable through a non-constrained link) and if AS is in turn aware of that. In any other circumstance, it is otherwise possible to identify both AUTH_CRED_C and AUTH_CRED_RS by reference, when performing the ACE access control workflow as well as later on when C and RS run LAKE.

Workflow without Optimizations The example below shows a simple interaction between C and RS: C and RS run LAKE wherein C uploads the access token to RS, after which C accesses a protected resource at RS. | | | | | | | | | LAKE message_2 | | M02 |<----------------------------------------+ | | ID_CRED_R identifies | | | CRED_R = AUTH_CRED_AS by reference | | | | | | | | | LAKE message_3 to /.well-known/edhoc | | M03 +---------------------------------------->| | | ID_CRED_I identifies | | | CRED_I = AUTH_CRED_C by reference | | | | | | | | | Access token request to /token | | | (OSCORE-protected message) | | M04 +---------------------------------------->| | | "req_cnf" identifies | | | AUTH_CRED_C by reference | | | | | | | | | Access token response | | | (OSCORE-protected message) | | M05 |<----------------------------------------+ | | "rs_cnf" specifies | | | AUTH_CRED_RS by value | | | | | | "ace_profile" specifies the | | | ACE profile "coap_lake_oscore" | | | | | | "lake_info" specifies: | | | { | | | e'session_id' : h'01', | | | e'cipher_suites' : 2, | | | e'methods' : 3, | | | e'uri_path' : "/lake" | | | } | | | | | | In the access token: | | | - the "cnf" claim specifies | | | AUTH_CRED_C by value | | | - the "lake_info" claim | | | specifies the same as | | | "lake_info" above | | | | | Possibly after chain verification, C adds AUTH_CRED_RS to the set of its trusted peer authentication credentials, relying on AS as trusted provider. | | | | | | | LAKE message_1 to /lake | | | (no access control is enforced) | | M06 +---------------------------------------------------------------->| | | | | | | | LAKE message_2 | | M07 |<----------------------------------------------------------------+ | ID_CRED_R identifies | | | CRED_R = AUTH_CRED_RS by reference | | | | | | | | | LAKE message_3 to /lake | | | (no access control is enforced) | | M08 +---------------------------------------------------------------->| | EAD_3 contains: | | | - EAD item ACE-OAuth Access Token | | | (access token) | | | | | | ID_CRED_I identifies | | | CRED_I = AUTH_CRED_C by reference | | | | | Possibly after chain verification, RS adds AUTH_CRED_C to the set of its trusted peer authentication credentials, relying on AS as trusted provider. | | | | | | | Access to protected resource | | | (OSCORE-protected message) | | | (access control is enforced) | | M09 +---------------------------------------------------------------->| | | | | Response | | | (OSCORE-protected message) | | M10 |<----------------------------------------------------------------+ | | | Later on, the access token expires ... - C and RS delete their OSCORE Security Context and purge the LAKE session used to derive it. - RS retains AUTH_CRED_C as still valid, and AS knows about it. - C retains AUTH_CRED_RS as still valid, and AS knows about it. | | | | | | Time passes ... | | | | | | C asks for a new access token; now all the authentication credentials can be identified by reference. The cost falls on AS, which must remember that at least one access token has been issued for the pair (C, RS) and considering the pair (AUTH_CRED_C, AUTH_CRED_RS). | | | | | | | Access token request to /token | | | (OSCORE-protected message) | | M11 +---------------------------------------->| | | "req_cnf" identifies | | | CRED_I = AUTH_CRED_C by reference | | | | | | | | | Access token response | | | (OSCORE-protected message) | | M12 |<----------------------------------------+ | | "rs_cnf" identifies | | | AUTH_CRED_RS by reference | | | | | | "ace_profile" specifies the | | | ACE profile "coap_lake_oscore" | | | | | | "lake_info" specifies: | | | { | | | e'session_id' : h'05', | | | e'cipher_suites' : 2, | | | e'methods' : 3, | | | e'uri_path' : "/lake" | | | } | | | | | | In the access token: | | | - the "cnf" claim identifies | | | AUTH_CRED_C by reference | | | - the "lake_info" claim | | | specifies the same as | | | "lake_info" above | | | | | | | | | | | | LAKE message_1 to /lake | | | (no access control is enforced) | | M13 +---------------------------------------------------------------->| | | | | | | | LAKE message_2 | | M14 |<----------------------------------------------------------------+ | ID_CRED_R identifies | | | CRED_R = AUTH_CRED_RS by reference | | | | | | | | | LAKE message_3 to /lake | | | (no access control is enforced) | | M15 +---------------------------------------------------------------->| | EAD_3 contains: | | | - EAD item ACE-OAuth Access Token | | | (access token) | | | | | | ID_CRED_I identifies | | | CRED_I = AUTH_CRED_C by reference | | | | | | | | | Access to protected resource /r | | | (OSCORE-protected message) | | | (access control is enforced) | | M16 +---------------------------------------------------------------->| | | | | | | | Response | | | (OSCORE-protected message) | | M17 |<----------------------------------------------------------------+ | | | ]]>

Workflow with Optimizations The example below builds on the example in . In particular, C additionally uses the LAKE + OSCORE request defined in (denoted therein as "EDHOC + OSCORE request") when running LAKE both with AS and with RS. Consequently, the interaction between C and RS consists of only two round trips to run LAKE, upload the access token, and access the protected resource at RS. | | | | | | | | | LAKE message_2 | | M02 |<------------------------------------------+ | | ID_CRED_R identifies | | | CRED_R = AUTH_CRED_AS by reference | | | | | | | | | LAKE + OSCORE request to /token | | | (OSCORE-protected message) | | M03 +------------------------------------------>| | | - LAKE message_3 | | | ID_CRED_I identifies | | | CRED_I = AUTH_CRED_C by reference | | | --- --- --- | | | - OSCORE-protected part | | | Access token request | | | "req_cnf" identifies | | | AUTH_CRED_C by reference | | | | | | | | | Access token response | | | (OSCORE-protected message) | | M04 |<------------------------------------------+ | | "rs_cnf" specifies | | | AUTH_CRED_RS by value | | | | | | "ace_profile" specifies the | | | ACE profile "coap_lake_oscore" | | | | | | "lake_info" specifies: | | | { | | | e'session_id' : h'01', | | | e'cipher_suites' : 2, | | | e'methods' : 3, | | | e'uri_path' : "/lake" | | | } | | | | | | In the access token: | | | - the "cnf" claim specifies | | | AUTH_CRED_C by value | | | - the "lake_info" claim | | | specifies the same as | | | "lake_info" above | | | | | Possibly after chain verification, C adds AUTH_CRED_RS to the set of its trusted peer authentication credentials, relying on AS as trusted provider. | | | | LAKE message_1 to /lake | | | (no access control is enforced) | | M05 +---------------------------------------------------------------->| | | | | | | | | | | LAKE message_2 | | M06 |<----------------------------------------------------------------+ | ID_CRED_R identifies | | | CRED_R = AUTH_CRED_RS by reference | | | | | | | | | LAKE + OSCORE request to /r | | | (OSCORE-protected message) | | M07 +---------------------------------------------------------------->| | - LAKE message_3 | | | EAD_3 contains: | | | - EAD item ACE-OAuth Access Token | | | (access token) | | | | | | ID_CRED_I identifies | | | CRED_I = AUTH_CRED_C by reference | | | --- --- --- | | | - OSCORE-protected part | | | Application request to /r | | | | | Possibly after chain verification, RS adds AUTH_CRED_C to the set of its trusted peer authentication credentials, relying on AS as trusted provider After the LAKE processing is completed, access control is enforced on the rebuilt OSCORE-protected request, like if the request had been sent stand-alone | | | | | | | Response | | | (OSCORE-protected message) | | M08 |<----------------------------------------------------------------+ | | | ]]>

Non-sequential Workflow When this profile is used, C might not be able to determine in advance the appropriate AS to contact. In such cases, C may initiate LAKE with RS prior to obtaining an access token and rely on RS to provide this information. As detailed in this section, one approach is for RS to convey this information within an EAD item included in LAKE message_2. The content of the EAD item is the information conveyed in an AS Request Creation Hints response, thereby helping C identify the correct AS, and possibly other relevant parameters needed to request an access token from AS. The following describes an example scenario where this functionality is used in the LAKE forward message flow, in particular taking advantage of the EAD items Request Creation Hints (see ) and Credential By Value (see ).

1. Without having an access token, C sends LAKE message_1 to RS, including in EAD_1:
   • The EAD item Request Creation Hints, with no ead_value. By doing so, C asks RS to include the same EAD item in EAD_2, specifying as ead_value the information that would be included in an AS Request Creation Hints response.
   • The EAD item Credential By Value. By doing so, C asks RS to specify its authentication credential AUTH_CRED_RS by value in ID_CRED_R of LAKE message_2.
2. RS replies with LAKE message_2, specifying its authentication credential AUTH_CRED_RS by value in ID_CRED_R. In the same LAKE message_2, the EAD_2 field includes the EAD item Request Creation Hints, whose CBOR byte string specified as ead_value encodes the information that would have been included in an AS Request Creation Hints response to an unauthorized request sent to RS. In particular, this information includes the URI to the /token endpoint at AS. Note that C has not made an actual request with a specific request method and targeting a specific application resource. That is, RS does not know yet what resources C is actually interested in accessing later on.
3. C requests an access token for the right audience and scope from the right AS, based on pre-configured parameters on C and on the information from the EAD item Request Creation Hints within LAKE message_2, like if C had received an AS Request Creation Hints response from RS. C needs to know in advance the right audience and scope to specify in the access token request to AS, since that information is not provided by RS in the EAD item Request Creation Hints within LAKE message_2 (see ). There may also be default audience and scope set at AS to use, if none is specified by C in its access token request.
4. C sends LAKE message_3 to RS, specifying the access token by means of the EAD item ACE-OAuth Access Token.
5. If a protected request from C for accessing a resource at RS is not authorized per the issued access token, then RS replies with a protected error response. Within that error response, RS can provide C with information that would have been specified in an AS Request Creation Hints response. This time, that information also includes "audience" and "scope". After this, C can request from AS a new access token that dynamically updates access rights accordingly (see ). Note that this applies also if C uses the LAKE + OSCORE combined request , hence combining LAKE message_3 with the first OSCORE-protected request to access a protected resource at RS (see ).

Instead, if the LAKE reverse message flow is used, then the following differences apply compared to what is described above:

• C includes the EAD items Request Creation Hints and Credential By Value in LAKE message_2. By doing so, C asks RS to provide the AS Request Creation Hints information and to specify its authentication credential AUTH_CRED_RS by value in ID_CRED_I when sending LAKE message_3.
• RS includes the EAD item Request Creation Hints in LAKE message_3, specifying as ead_value the AS Request Creation Hints information.
• After receiving LAKE message_3, C requests the access token from AS, based on the information from the EAD item Request Creation Hints within LAKE message_3.
• Finally, C sends LAKE message_4 to RS, specifying the access token by means of the EAD item ACE-OAuth Access Token.

The interactions between AS, RS, and C are shown in the following example, where the LAKE forward message flow is used. | | EAD_1 contains: | | | - EAD item Request Creation Hints | | | (no ead_value) | | | - EAD item Credential By Value | | | (no ead_value) | | | | | | | | | LAKE message_2 | | M02 |<----------------------------------------------------------------+ | EAD_2 contains: | | | - EAD item Request Creation Hints | | | (AS Request Creation Hints) | | | | | | ID_CRED_R identifies | | | CRED_R = AUTH_CRED_RS by value | | | | | | | | | LAKE message_1 to /.well-known/edhoc | | M03 +---------------------------------------->| | | | | | | | | LAKE message_2 | | M04 |<----------------------------------------+ | | ID_CRED_R identifies | | | CRED_R = AUTH_CRED_AS by reference | | | | | | | | | LAKE message_3 to /.well-known/edhoc | | M05 +---------------------------------------->| | | ID_CRED_I identifies | | | CRED_I = AUTH_CRED_C by reference | | | | | | | | | Access token request to /token | | | (OSCORE-protected message) | | M06 +---------------------------------------->| | | "req_cnf" identifies | | | AUTH_CRED_C by reference | | | | | | | | | Access token response | | | (OSCORE-protected message) | | M07 |<----------------------------------------+ | | "rs_cnf" specifies | | | AUTH_CRED_RS by value | | | | | | "ace_profile" specifies the | | | ACE profile "coap_lake_oscore" | | | | | | "lake_info" specifies: | | | { | | | e'session_id' : h'01', | | | e'cipher_suites' : 2, | | | e'methods' : 3, | | | } | | | | | | In the access token: | | | - the "cnf" claim specifies | | | AUTH_CRED_C by value | | | - the "lake_info" claim | | | specifies the same as | | | "lake_info" above | | | | | Possibly after chain verification, C adds AUTH_CRED_RS to the set of its trusted peer authentication credentials, relying on AS as trusted provider. Regardless, when continuing the LAKE session, C uses as authentication credential of RS the one identified by ID_CRED_R in LAKE message_2 from RS. | | | | LAKE message_3 to /.well-known/edhoc | | | (no access control is enforced) | | M08 +---------------------------------------------------------------->| | EAD_3 contains: | | | - EAD item ACE-OAuth Access Token | | | (access token) | | | | | | ID_CRED_I identifies | | | CRED_I = AUTH_CRED_C by reference | | | | | | | | | Access to protected resource | | | (OSCORE-protected message) | | | (access control is enforced) | | M09 +---------------------------------------------------------------->| | | | | Response | | | (OSCORE-protected message) | | M10 |<----------------------------------------------------------------+ | | | If instead access is not authorized, RS replies to M09 with a protected error response including updated Request Creation Hints. C can then request a new access token from AS. ]]>

Profile Requirements This section lists the specifications of this profile based on the requirements of the framework, as requested in .

• Optionally, define new methods for the client to discover the necessary permissions and AS for accessing a resource, different from the one proposed in : AS discovery is supported by using the EAD item Request Creation Hints as described in .
• Optionally, specify new grant types: Not specified.
• Optionally, define the use of client certificates as client credential type: C can use authentication credentials of any type admitted by the LAKE protocol, including public key certificates such as X.509 certificates and C509 certificates .
• Specify the communication protocol the client and RS must use: CoAP.
• Specify the security protocol the client and RS must use to protect their communication: OSCORE.
• Specify how the client and RS mutually authenticate: Explicitly, by successfully executing the LAKE protocol, after which a common OSCORE Security Context is exported from the LAKE session. As per the LAKE authentication method used during the LAKE session, authentication is provided by digital signatures, or by Message Authentication Codes (MACs) computed from an ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) shared secret.
• Specify the proof-of-possession protocol(s) and how to select one, if several are available. Also specify which key types (e.g., symmetric/asymmetric) are supported by a specific proof-of-possession protocol: LAKE authentication methods and LAKE algorithms for RS to authenticate C during the LAKE session, per C's public authentication credential used in the session and bound to the access token specified to RS in the session.
• Specify a unique ace_profile identifier: coap_lake_oscore.
• If introspection is supported, specify the communication and security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE).
• Specify the communication and security protocol for interactions between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE).
• Specify if/how the authz-info endpoint is protected, including how error responses are protected: Not protected.
• Optionally, define methods of token transport other than the authz-info endpoint: C can upload the access token when executing LAKE with RS, by specifying the access token through a dedicated EAD item such as the EAD item ACE-OAuth Access Token (see ). The LAKE message where the EAD item is included depends on the LAKE message flow used.

CDDL Model

CDDL model

Document Updates

Version -11 to -12

• Renamed EDHOC to LAKE as appropriate.
• Clarification: for initial authentication, only methods based on public keys can be used. PSK-based authentication can be used for session resumption.
• Added new section on possible conflicting information from AS to C.
• Fixed JSON and CBOR examples of the LAKE_Information object.
• More precise wording on base64 encoding.
• Updated privacy considerations about OSCORE identifiers.
• Editorial fixes and improvements.

Version -10 to -11

• Clarify instructions on when to include audience when C performs update of access rights.
• Clarified definition of "prescriptive" / "non-prescriptive" parameters.
• In the reverse message flow, C can upload the access token to RS only in message_4.
• Discussed timing of access token request when using the EDHOC reverse message flow.
• Fixed mix-up between proof of possession and key confirmation.
• New EAD items:
  • Consistent and simpler naming.
  • Revised format/style of their definition.
  • Revised normative language for using AS Request Creation Hints.
  • Fixed CDDL definition of ead_request_creation_hints.
• Removed definition of the EAD item Session ID.
• Added the "Operational Considerations" section.
  • RS belonging to multiple audiences with different credentials.
  • Keeping knowledge about C and RS up-to-date at AS.
• Added figure with message flow for Non-sequential Workflow.
• Improved notation and details in examples of message exchanges.
• Aligned the "c5u" confirmation method with draft-ietf-cose-cbor-encoded-cert-20.
• Fixes to the confirmation methods "x5u", "kcwt", and "kccs".
• Added references to IANA registries.
• Avoid normative language with inherited normative behavior.
• Updated compliance with profile requirements.
• Editorial improvements.

Version -09 to -10

• Fixed CDDL definition of the EDHOC_Information object.
• Removed excessive EDHOC_Information parameters: "max_msgsize", "coap_ct", "ep_id_types", and "transports".
• Removed definition of some IANA registries: "EDHOC Endpoint Identity Types" and "EDHOC Transports".
• Defined derivation of N_S, when combining this profile with application profiles of RFC 9594.
• Editorial fixes and improvements.

Version -08 to -09

• Parameter "cnf" explicitly forbidden in the access token response.
• Clarification about content of "cnf" claim in the access token.
• RS must support the CoAP Uri-Path-Abbrev Option and its value abbreviating /.well-known/edhoc.
• Example of Request Creation Hints provided in EAD item.
• Examples showing content of new EAD items.

Version -07 to -08

• KUDOS is just an example of protocol to use for optional key update.
• message_4 is mandatory to support for an RS that supports the reverse message flow.
• Method in -workflow-and-params as example for coordinating the exchange of authentication credentials by value or reference.
• Revised initial set of EDHOC_Information parameters.
• Defined categorization of EDHOC_Information parameters.
• New EAD item for C to retrieve Request Creation Hints information from RS.
• New EAD item for requesting authentication credential by value.
• Means for AS to achieve proof of possession of C's private key.
• Editorial improvements.

Version -06 to -07

• Renamed id_ep_types as ep_id_types.
• Revised rules for AS to assign session ID values.
• Added explicit validation of AUTH_CRED_C at AS.
• "edhoc_info" only in AS-to-C response for first token in a series.
• With a group-audience, "edhoc_info" refers to the whole audience.
• Defined parameters for the EDHOC_Information object:
  • Parameters moved here from draft-ietf-lake-app-profiles.
  • New parameter "trust_anchors".
• Access token request/response messages must be encoded in CBOR.
• Explicit statement on admitted confirmation methods.
• First token in a series: the "cnf" claim uses the same confirmation method of the "req_cnf" request to /token.
• Revised examples in CBOR diagnostic notation.
• With a group-audience, the reverse message flow can use a roll call.
• Matching authentication credentials from ID_CRED_X and EAD item.
• Handling authentication credentials and EDHOC session that become invalid.
• Limited use of ACE Request Creation Hints when supporting the EDHOC reverse message flow.
• Changed CBOR abbreviations to not collide with existing codepoints.
• Updates and fixes in the IANA considerations.
• Updated references.
• Clarifications and editorial improvements.

Version -05 to -06

• The access token can be uploaded through EDHOC in EAD_3, EAD_2, or EAD_4.
• Ruled out the upload of the access token to the /authz-info endpoint over an unprotected channel.
• Defined an EDHOC EAD item for transporting a Session ID.
• Provided more details and added example of dynamic update of access rights.
• Defined in detail the use of the EDHOC reverse message flow.
• Provided details on access token invalidity.
• Revised examples with message exchanges.
• Clarifications and editorial improvements.

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.

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.

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.

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.

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.

Acknowledgments The authors sincerely thank and for their comments and feedback. The parameter "trust_anchors" for specifying supported trust anchors builds on a proposal originally described in . This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).