]> RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden rikard.hoglund@ri.se

Security LAKE Working Group Internet-Draft The Lightweight Authenticated Key Exchange (LAKE) protocol 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 LAKE 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 LAKE application profiles. Furthermore, in order to facilitate interoperability between LAKE implementations and support LAKE extensibility for additional integrations, this document defines a number of means to coordinate the use of LAKE application profiles. Finally, this document defines a set of well-known LAKE application profiles. Discussion Venues Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (lake@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The specification defines the Lightweight Authenticated Key Exchange (LAKE) protocol, which is especially intended for use in constrained scenarios. A main use case for LAKE is the establishment of a Security Context for Object Security for Constrained RESTful Environments (OSCORE) . In order to successfully run LAKE, the two peers acting as Initiator and Responder have to agree on certain parameters. Some of those are in-band and communicated through the protocol execution, during which a few of them may even be negotiated. However, other parameters have to be known out-of-band, before running the LAKE protocol. As discussed in , applications can use LAKE application profiles, which specify the intended usage of LAKE to allow for the relevant processing and verifications to be made. A LAKE application profile may include both in-band and out-of-band parameters. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines the LAKE_Application_Profile object, i.e., a canonical, CBOR-based representation that can be used to describe, distribute, and store LAKE application profiles as CBOR data items (see ). The defined representation is transport- and setup-independent, and it avoids the need to reinvent an encoding for the available options to run the LAKE protocol or the selection logic to apply on those. The LAKE_Application_Profile object is a specialized alternative to the LAKE_Information object defined in , building on a shared parameter namespace. In particular, a LAKE_Information object can be used to provide a context-based description of a LAKE application profile that is supported under a concrete circumstance to which the object applies. Conversely, a LAKE_Application_Profile object provides a description of a LAKE application profile as an established and immutable set of information about how LAKE can be run, irrespective of the concrete circumstance where LAKE is executed. A LAKE_Application_Profile object providing the CBOR-based representation of a LAKE application profile can be, for example: retrieved as a result of a discovery process; or retrieved/provided during the retrieval/provisioning of a LAKE peer's public authentication credential; or obtained during the execution of a device on-boarding/registration workflow. Furthermore, in order to facilitate interoperability between LAKE implementations and to support LAKE extensibility for additional integrations (e.g., external security applications, or handling of authentication credentials), this document defines a number of means to coordinate the use of LAKE application profiles, that is:

• The new IANA registry "LAKE Application Profiles" defined in , where to register integer identifiers of LAKE application profiles to use as corresponding Profile IDs.
• The new parameter "ed-prof" defined in . This parameter is employed to specify a LAKE application profile identified by its Profile ID and can be used as target attribute in a web link to a LAKE resource, or as filter criterion in a discovery request to discover LAKE resources. For instance, the target attribute can be used in a CoRE link-format document describing LAKE resources at a server, when LAKE is transferred over the Constrained Application Protocol (CoAP) (see as well as ).
• The new parameter "app_prof" defined in for the LAKE_Information object specified in . When present within an instance of the LAKE_Information object, this parameter identifies one or more LAKE application profiles that are supported under the concrete circumstance to which the LAKE_Information object applies. In particular, this parameter identifies each LAKE application profile by means of the corresponding Profile ID. For instance, the parameter can be used in the LAKE and OSCORE profile of the Authentication and Authorization for Constrained Environments (ACE) framework , in order to indicate the LAKE application profiles supported by an ACE resource server. This parameter is also used in the LAKE_Application_Profile object defined in of this document. That is, given an instance of the LAKE_Application_Profile object, the parameter "app_prof" included therein specifies the Profile ID of the LAKE application profile that is described by the instance of the object in question.
• New parameters for web linking , which can be used to obtain relevant pieces of information from the LAKE application profile associated with a LAKE resource (see ). These parameters correspond to analogous elements of the LAKE_Information object and extend the set of parameters for web linking originally defined in . In particular, they can be used as target attributes in a web link to a LAKE resource, or as filter criteria in a discovery request to discover LAKE resources.
• A new LAKE External Authorization Data (EAD) item (see ) and a new error code for the LAKE error message (see ). When running LAKE, a peer can use those in order to advertise the LAKE application profiles that it supports to the other peer.
• The use of SVCB Resource Records (RR) to advertise the support for LAKE and for LAKE application profiles of a given server (see ).

Finally, this document defines a set of well-known LAKE application profiles (see ). These application profiles are meant to reflect what is most common and expected to be supported by LAKE peers, while they are not intended as "default" application profiles or as a deviation from what is mandatory to support for LAKE peers (see ). On the other hand, they provide implementers and users with a quick overview of the several available options to run the LAKE protocol and of their most expected combinations.

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. The reader is expected to be familiar with terms and concepts defined in LAKE and with the use of LAKE with CoAP and OSCORE defined in . 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. The reader is also expected to be familiar with the concept of LAKE_Information parameters defined in and with their categorization as prescriptive or non-prescriptive. In particular:

• A prescriptive parameter is used to provide an authoritative statement about how an execution of LAKE has to be performed. An example is the parameter "message_4" 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 parameter "methods" indicating a set of supported LAKE methods.

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. The provided CDDL definitions can be extracted from the XML version of this document using the following XPath expression: CBOR data items are represented using the CBOR extended diagnostic notation as defined in and ("diagnostic notation"). Diagnostic notation comments are used to provide a textual representation of the parameters' keys 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'methods' : [0, 1, 2, 3], e'cipher_suites': 3} stands for {1 : [0, 1, 2, 3], 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.

LAKE_Application_Profile This section defines the LAKE_Application_Profile object, which can be used as a canonical representation of LAKE application profiles for their description, distribution, and storage. A LAKE_Application_Profile object is encoded as a CBOR map . All elements that can be included in the LAKE_Application_Profile object are elements that can be included in the CBOR-encoded LAKE_Information object specified in . In particular, they use the same CBOR abbreviations from the 'CBOR label' column of the IANA registry "LAKE Information" defined in . More specifically, the LAKE_Application_Profile object is a specialized alternative to the LAKE_Information object. In particular, a LAKE_Information object can be used to provide a context-based description of a LAKE application profile that is supported under a concrete circumstance to which the object applies. Conversely, a LAKE_Application_Profile object provides a description of a LAKE application profile as an established and immutable set of information about how LAKE can be run, irrespective of the concrete circumstance where LAKE is executed. The CBOR map encoding a LAKE_Application_Profile object MUST include the element "app_prof" defined in of this document, as well as the elements "methods" and "cred_types" defined in . Within the CBOR map, the element "app_prof" is encoded as a CBOR integer and identifies the LAKE application profile being defined by the instance of the LAKE_Application_Profile object in question. That is, the value of the element "app_prof" encodes the unique integer identifier of the LAKE application profile described by the instance of the object in question. The identifier is taken from the 'Profile ID' column of the "LAKE Application Profiles" registry defined in this document. The CBOR map MUST NOT include the following elements: "session_id", "uri_path", "initiator", "responder", and "trust_anchors". Also, the CBOR map MUST NOT include the element "exporter_out_len" defined in of this document. A consumer MUST ignore those elements if they are included in the LAKE_Application_Profile object. The CBOR map MAY include other elements. Furthermore, consistent with Sections and of and with , the following applies:

• If the element "cipher_suites" is not present in the CBOR map, this indicates that the LAKE application profile uses the LAKE cipher suites 2 and 3, and possibly other cipher suites.
• If the element "id_cred_types" is not present in the CBOR map, this indicates that the LAKE application profile uses "kid" as type of authentication credential identifiers for LAKE, and possibly other types of authentication credential identifiers.
• The absence of any other elements in the CBOR map MUST NOT result in assuming any value.

If an element is present in the CBOR map and the corresponding entry in the IANA registry "LAKE Information" specifies "NP" (non-prescriptive) in the 'Type' column and "True or False" in the 'CBOR type' column, then the following applies: A LAKE peer that adheres to the LAKE application profile in question is either required to support or not required to support the property or feature of LAKE associated with the element in the CBOR map, if that element encodes the CBOR simple value true (0xf5) or false (0xf4), respectively. For example, the presence of the parameter "comb_req" denotes whether LAKE peers adhering to the LAKE application profile have to support the "LAKE + OSCORE request" (denoted as "EDHOC + OSCORE request" in ), or instead do not have to but might if they are willing to. If an element present in the CBOR map specifies an information that is intrinsically a set of one or more co-existing alternatives, then all the specified alternatives apply for the LAKE application profile in question. For example, the element "cipher_suites" with value the CBOR array [0, 2] means that, in order to adhere to the LAKE application profile in question, a LAKE peer has to implement both the LAKE cipher suites 0 and 2, because either of them can be used by another LAKE peer also adhering to the same LAKE application profile. The CDDL grammar describing the LAKE_Application_Profile object is:

CDDL Definition of the LAKE_Application_Profile object int / [2* int], ; methods 6 => int / [2* int], ; cred_types 23 => int, ; app_prof * (int / tstr) => any } ]]>

registers the media type "application/lake-app-profile+cbor-seq" and registers the corresponding CoAP Content-Format. Applications can use this media type to describe, distribute, and store a representation of a set of one or more LAKE application profiles. In particular, the media type can be used by messages whose payload conveys a set of one or more LAKE application profiles. When using this media type, the set of LAKE application profiles is encoded as a CBOR sequence of CBOR maps . Each of the CBOR maps is a LAKE_Application_Profile object as defined in this section.

Identifying LAKE Application Profiles by Profile ID This document introduces the concept of Profile IDs, i.e., integer values that uniquely identify LAKE application profiles, for which an IANA registry is defined in . This section defines two parameters to convey such Profile IDs, i.e.:

• The parameter "ed-prof" for web linking (see of this document).
• The parameter "app_prof" of the LAKE_Information object specified in (see of this document). As defined in , Profile IDs are also conveyed by the parameter "app_prof" in the LAKE_Application_Profile object, in order to identify the LAKE application profile described by a given instance of that object.

As defined later in this document, Profile IDs can be used to identify LAKE application profiles also:

• Within certain LAKE messages sent during a LAKE session by a peer that supports such LAKE application profiles (see ).
• When using SVCB Resource Records (RR) to advertise the support for LAKE and for LAKE application profiles of a given server (see ).

In Web Linking defines a number of target attributes that can be used in a web link with resource type "core.edhoc" denoting a LAKE resource (see , where the term "EDHOC resource" is used). This is the case, e.g., when using a CoRE link-format document describing LAKE resources at a server, when LAKE is transferred over CoAP as defined in . This allows a client to obtain relevant information about the LAKE application profile(s) to be used with a certain LAKE resource. In the same spirit, this section defines the following additional parameter, which can be optionally specified as a target attribute with the same name in the link to the respective LAKE resource, or among the filter criteria in a discovery request from a client.

• 'ed-prof', specifying a LAKE application profile supported by the server. This parameter MUST specify a single value, which is taken from the 'Profile ID' column of the "LAKE Application Profiles" registry defined in of this document. This parameter MAY occur multiple times, with each occurrence specifying a LAKE application profile.

When specifying the parameter 'ed-prof' in a link to a LAKE resource, the target attribute rt="core.edhoc" MUST be included. If a link to a LAKE resource includes occurrences of the target attribute 'ed-prof', then the following applies.

• The link MUST NOT include other target attributes that provide information about a LAKE application profile (see, e.g., and of this document), with the exception of the target attribute 'ed-ead' that MAY be included. The recipient MUST ignore other target attributes that provide information about a LAKE application profile, with the exception of the target attribute 'ed-ead'.
• If the link includes occurrences of the target attribute 'ed-ead', the link provides the following information: when using the target LAKE resource as per the LAKE application profile indicated by any occurrence of the target attribute 'ed-prof', the server supports the External Authorization Data (EAD) items that are specified in the definition of that LAKE application profile, as well as the EAD items indicated by the occurrences of the target attribute 'ed-ead'.

The example in shows how a CoAP client discovers two LAKE resources at a CoAP server and obtains information about the application profile corresponding to each of those resources. The CoRE Link Format notation from is used. The example assumes the existence of a LAKE application profile identified by the integer Profile ID 500, which is supported by the LAKE resource at /lake-alt and whose definition includes the support for the EAD items with EAD label 111 and 222. Therefore, the link to the LAKE resource at /lake-alt indicates that, when using that LAKE resource as per the LAKE application profile with Profile ID 500, the server supports the EAD items with EAD label 111, 222, and 333.

The Web Link. ;osc, ;if=sensor, ;rt=core.edhoc;ed-csuite=0;ed-csuite=2; ed-method=0;ed-cred-t=0;ed-cred-t=1;ed-idcred-t=4; ed-i;ed-r;ed-comb-req, ;rt=core.edhoc;ed-prof=500;ed-ead=333 ]]>

In the LAKE_Information Object defines the LAKE_Information object and an initial set of its parameters. The object can be used to convey information that guides peers towards executing the LAKE protocol. This document defines the new parameter "app_prof" of the LAKE_Information object. The parameter is of type non-prescriptive (NP) and is summarized in . The parameter is specified further below. LAKE_Information Parameter "app_prof"

Name	CBOR label	CBOR type	Registry	Description	Type
app_prof	23	int or array	LAKE Application Profiles registry	Set of supported LAKE application profiles	NP

• app_prof: This parameter specifies a set of supported LAKE application profiles, identified by their Profile ID. If the set is composed of a single LAKE application profile, its Profile ID is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one Profile ID. In JSON, the "app_prof" value is an integer or an array of integers. In CBOR, "app_prof" is an integer or an array of integers, and it has label 23. The integer values are taken from the 'Profile ID' column of the "LAKE Application Profiles" registry defined in of this document.

When present within an instance of the LAKE_Information object, the parameter "app_prof" identifies one or more LAKE application profiles that are supported under the concrete circumstance to which the object applies. describes the use of the parameter "app_prof" within an instance of the LAKE_Information object, when using the LAKE and OSCORE profile of the ACE Framework . The CDDL grammar describing the parameter "app_prof" when included in the CBOR-encoded LAKE_Information object is:

CDDL Definition of the Parameter "app_prof" when Included in the CBOR-encoded LAKE_Information Object. int / [2* int] ; app_prof ) ]]>

Use in the LAKE and OSCORE Profile of the ACE Framework defines how the LAKE_Information object can be used within the workflow of the LAKE and OSCORE transport profile of the ACE framework . In particular, the AS-to-C Access Token Response includes the parameter "lake_info", with value a LAKE_Information object. This allows the ACE authorization server (AS) to provide the ACE client (C) with information about how to run the LAKE protocol with the ACE resource server (RS) for which the access token is issued. Similarly, the access token includes the corresponding claim "lake_info", with value a LAKE_Information object. This allows the AS to provide the ACE RS with information about how to run the LAKE protocol with the ACE client, according to the issued access token. In turn, the LAKE_Information object can include the parameter "app_prof" defined in this document. This parameter indicates a set of LAKE application profiles associated with the LAKE resource to use at the RS, which is either implied or specified by the parameter "uri_path" within the same LAKE_Information object. If the LAKE_Information object specified as the value of the parameter/claim "lake_info" includes the parameter "app_prof", then the following applies.

• In addition to the parameter "app_prof", the object MUST NOT include other parameters, with the exception of the following parameters that MAY be included:
  • The parameter "eads".
  • Any parameter that is not allowed in the LAKE_Application_Profile object defined in , unless its inclusion in the LAKE_Information object is explicitly forbidden by the parameter's definition. For example, the parameter "session_id" is not allowed in the LAKE_Application_Profile object (see ) and thus can be included in the LAKE_Information object, where in fact it has to be present (see Sections and of ).
  C and RS MUST ignore other parameters that are not admitted, in the case that they are present in the LAKE_Information object.
• The object might provide an information that corresponds to a LAKE_Information prescriptive parameter (see ), e.g., "message_4". The type of a parameter is indicated in the 'Type' column of the corresponding entry in the IANA registry "LAKE Information" (see ). If the object specifies such an information multiple times, then each occurrence of that information MUST convey exactly the same content. This MUST take into account prescriptive parameters that are included: i) as elements of the LAKE_Information object; or ii) as elements of a LAKE_Application_Profile object (see ) encoding a LAKE application profile, which is identified by its Profile ID specified in the parameter "app_prof" of the LAKE_Information object. A consumer MUST treat as malformed a LAKE_Information object that does not comply with the restriction above.
• If the LAKE_Information object specified in the parameter "lake_info" of the AS-to-C Access Token Response includes the parameter "eads", then the following applies. When using the target LAKE resource as per any LAKE application profile indicated by the parameter "app_prof", the ACE RS for which the access token is issued supports the EAD items that are specified in the definition of that LAKE application profile, as well as the EAD items indicated by the parameter "eads".
• If the LAKE_Information object specified in the claim "lake_info" of the access token includes the parameter "eads", then the following applies. When using the target LAKE resource as per any LAKE application profile indicated by the parameter "app_prof", the ACE client to which the access token is issued supports the EAD items that are specified in the definition of that LAKE application profile, as well as the EAD items indicated by the parameter "eads".

Additional Parameters for Web Linking Building on what is defined and prescribed in , this section defines additional parameters for web linking , which can be used to obtain relevant pieces of information from the LAKE application profile associated with a LAKE resource. These parameters can be optionally specified as target attributes with the same name in a link with resource type "core.edhoc" denoting a LAKE resource (see , where the term "EDHOC resource" is used) targeting a LAKE resource, or as filter criteria in a discovery request from a client. When specifying any of the parameters defined below in a link to a LAKE resource, the target attribute rt="core.edhoc" MUST be included.

• 'ed-ta-edcred-uuid': Specifies the identifier of a trust anchor supported by the server for verifying authentication credentials of other LAKE peers, as a UUID . This parameter MUST specify a single value, which is the UUID in its string format (see Section 4 of ). This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-kid': Specifies the identifier of a trust anchor supported by the server for verifying authentication credentials of other LAKE peers, as a binary key identifier. This parameter MUST specify a single value, which is the base64url-encoding (see ) without padding of the binary representation of the key identifier. This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-c5t': Specifies the identifier of a trust anchor supported by the server for verifying authentication credentials of other LAKE peers, as a hash of a C509 certificate . This parameter MUST specify a single value, which is the base64url-encoding (see ) without padding of the binary representation of the certificate hash encoded as a COSE_CertHash . This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-c5u': Specifies the identifier of a trust anchor supported by the server for verifying authentication credentials of other LAKE peers, as a URI pointing to a C509 certificate . This parameter MUST specify a single value, which is the URI pointing to the certificate. This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-x5t': Specifies the identifier of a trust anchor supported by the server for verifying authentication credentials of other LAKE peers, as a hash of an X.509 certificate . This parameter MUST specify a single value, which is the base64url-encoding (see ) without padding of the binary representation of the certificate hash encoded as a COSE_CertHash . This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-x5u': Specifies the identifier of a trust anchor supported by the server for verifying authentication credentials of other LAKE peers, as a URI pointing to an X.509 certificate . This parameter MUST specify a single value, which is the URI pointing to the certificate. This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-psk-resumption': If present, specifies that the server supports LAKE session resumption with LAKE-PSK . A value MUST NOT be given to this parameter and any present value MUST be ignored by the recipient. Future documents may update the definition of this parameter by expanding its semantics and specifying what it can take as value.

The example in extends the earlier example in , by additionally showing the use of the target attributes 'ed-ta-edcred-kid' and 'ed-ta-edcred-x5t'. Compared to the example in , the following also applies.

• The link to the LAKE resource at /.well-known/edhoc includes the target attribute 'ed-ta-edcred-kid'. The target attribute has value "AKw", i.e., the base64url-encoding without padding of 0x00ac. The latter is the binary key identifier of a trust anchor supported by the server when running LAKE through that resource.
• The link to the LAKE resource at /lake-alt includes the target attribute 'ed-ta-edcred-kid'. The target attribute has value "_wH_", i.e., the base64url-encoding without padding of 0xff01ff. The latter is the binary key identifier of a trust anchor supported by the server when running LAKE through that resource.
• The link to the LAKE resource at /lake-alt includes the target attribute 'ed-ta-edcred-x5t'. The target attribute has value "gi5IefKkG1EMH5s", i.e., the base64url-encoding without padding of 0x822e4879f2a41b510c1f9b. The latter is the binary representation of the COSE_CertHash corresponding to an X.509 certificate that the server supports as a trust anchor when running LAKE through that resource. In CBOR diagnostic notation, the considered COSE_CertHash is as follows: [-15, h'79f2a41b510c1f9b'].

The Web Link. ;osc, ;if=sensor, ;rt=core.edhoc;ed-csuite=0;ed-csuite=2; ed-method=0;ed-cred-t=0;ed-cred-t=1;ed-idcred-t=4; ed-i;ed-r;ed-comb-req;ed-ta-edcred-kid="AKw", ;rt=core.edhoc;ed-prof=500;ed-ead=333; ed-ta-edcred-kid="_wH_";ed-ta-edcred-x5t="gi5IefKkG1EMH5s" ]]>

Advertising Supported LAKE Application Profiles During a LAKE Session The rest of this section defines means that a LAKE peer can use in order to advertise the LAKE application profiles that it supports to another LAKE peer, when running LAKE with that other peer. Such means are a LAKE EAD item (see ) and a LAKE error message with a dedicated error code (see ). Differently from the discovery mechanisms defined in and , these means display a number of benefits:

• Since EAD fields and the LAKE error message are a core feature of LAKE, supporting the new EAD item and the new error code is the only prerequisite for their use.
• They allow a LAKE peer to advertise what it supports even if it is a client-only peer.
• They allow a LAKE peer to advertise what it supports and prefers in the context of a specific LAKE session and in the light of its current status, instead of only in fixed and broad terms.

In LAKE Message 1 and Message 2 This section defines the LAKE EAD item "Supported LAKE application profiles", which is registered in of this document. The EAD item MAY be included:

• In the EAD_1 field of LAKE message_1, in order to specify LAKE application profiles supported by the Initiator.
• In the EAD_2 field of LAKE message_2, in order to specify LAKE application profiles supported by the Responder.

When the EAD item is present, its ead_label TBD_EAD_LABEL MUST be used only with negative sign, i.e., the use of the EAD item is always critical (see ). The EAD item MUST NOT occur more than once in the EAD fields of LAKE message_1 or message_2. The recipient peer MUST abort the LAKE session and MUST reply with a LAKE error message with error code (ERR_CODE) 1 "Unspecified error", if the EAD item occurs multiple times in the EAD fields of LAKE message_1 or message_2. The EAD item MUST NOT be included in the EAD fields of LAKE message_3 or message_4. In the case that the recipient peer supports the EAD item, the recipient peer MUST silently ignore the EAD item if this is included in the EAD fields of LAKE message_3 or message_4. The EAD item MUST specify an ead_value, as a CBOR byte string with value the binary representation of a CBOR sequence . In particular:

• When the EAD item is included in the EAD_1 field, the value of the CBOR byte string is the binary representation of the CBOR sequence OUTER_SEQ. In turn, OUTER_SEQ is composed of the following elements:
  • The CBOR data item advertise_flag, which MAY be present. If present, it MUST encode the CBOR simple value true (0xf5) or false (0xf4). The semantics of this element is as follows.
    • If advertise_flag is present and encodes the CBOR simple value true (0xf5), the Initiator is asking the Responder to advertise the LAKE application profiles that it supports, within the LAKE message sent in reply to LAKE message_1. If such a message is LAKE message_2, the Responder relies on the EAD item "Supported LAKE application profiles" included in the EAD_2 field. If such a message is a LAKE error message with error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles" (see ), the Responder relies on ERR_INFO. If the Responder sends either of those messages in reply to such a LAKE message_1, the Responder MUST honor the wish of the Initiator and accordingly advertise the LAKE application profiles that it supports.
    • If advertise_flag is present and encodes the CBOR simple value false (0xf4), the Initiator is suggesting the Responder to not advertise the LAKE application profiles that it supports, within the LAKE message sent in reply to LAKE message_1. This is relevant when the Initiator already knows what LAKE application profiles are supported by the Responder, e.g., based on previous interactions with that Responder or on the outcome of a discovery process. In spite of the suggestion from the Initiator, the Responder MAY still advertise the LAKE application profiles that it supports, when replying to LAKE message_1 with LAKE message_2 or with a LAKE error message with error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles" (see ). For example, when sending LAKE message_2, the Responder might wish to steer the rest of the LAKE session in a specific way, by including the EAD item "Supported LAKE application profiles" that specifies information corresponding to LAKE_Information prescriptive parameters (see ).
  • The CBOR sequence APP_PROF_SEQ, which MUST be present and is specified further below.
• When the EAD item is included in the EAD_2 field, the value of the CBOR byte string is the binary representation of the CBOR sequence APP_PROF_SEQ.

The CBOR sequence APP_PROF_SEQ is composed of one or more elements, whose order has no meaning. Each element of the CBOR sequence MUST be either of the following:

• A CBOR integer, specifying the Profile ID of a LAKE application profile. The integer value is taken from the 'Profile ID' column of the "LAKE Application Profiles" registry defined in of this document. This element of the CBOR sequence indicates that the message sender supports the LAKE application profile identified by the Profile ID.
• A CBOR array including at least two elements. In particular:
  • The first element MUST be a CBOR integer, specifying the Profile ID of a LAKE application profile. The integer value is taken from the 'Profile ID' column of the "LAKE Application Profiles" registry.
  • Each of the elements following the first one MUST be a CBOR unsigned integer, specifying the ead_label of an EAD item.
  This element of the CBOR sequence indicates that the message sender supports:
  • The LAKE application profile PROFILE identified by the Profile ID in the first element of the array; and
  • The EAD items identified by the ead_label in the elements following the first one, in addition to the EAD items that are specified in the definition of the LAKE application profile PROFILE.
• A LAKE_Information object encoded in CBOR, i.e., as a CBOR map (see ). The LAKE_Information object MUST NOT include the element "app_prof". Also, it MUST NOT include elements that are not allowed within the LAKE_Application_Profile object defined in , with the exception of the following elements that MAY be included:
  • "trust_anchors".
  • "exporter_out_len" (see ).
  This element of the CBOR sequence indicates that the message sender supports a LAKE application profile consistent with the pieces of information specified by the LAKE_Information object.

When sending LAKE message_1, the Initiator might want to include the EAD item "Supported LAKE application profiles" and not advertise the LAKE application profiles that it supports, but instead just take advantage of advertise_flag and ask the Responder to advertise what is supported on its side. In order to do that, the Initiator can compose ead_value such that, following advertise_flag, the CBOR sequence APP_PROF_SEQ only consists of a single LAKE_Information object as an empty CBOR map. The recipient peer MUST abort the LAKE session and MUST reply with a LAKE error message with error code (ERR_CODE) 1 "Unspecified error", if ead_value is malformed or does not conform with the format defined above. It is possible that ead_value provides information corresponding to LAKE_Information prescriptive parameters (see ), e.g., "message_4". The type of such parameters is indicated in the 'Type' column of the corresponding entry in the IANA registry "LAKE Information" (see ). If the EAD item "Supported LAKE application profiles" is included in LAKE message_1 and/or message_2 during a LAKE session, the peers participating in that session MUST NOT act in violation of what is indicated by prescriptive parameters that are specified in those EAD items. Note that such indications can be provided: as elements of a LAKE_Information object specified within APP_PROF_SEQ; or as elements of a LAKE_Application_Profile object encoding a LAKE application profile, which is identified by its Profile ID specified within APP_PROF_SEQ. Upon receiving a LAKE message and throughout the session, a peer MUST check whether the other peer has violated such indications. If any violation is found, the peer MUST abort the LAKE session and MUST reply with a LAKE error message with error code (ERR_CODE) 1 "Unspecified error". When composing ead_value, the sender peer MUST comply with the content restrictions specified in . The CDDL grammar describing ead_value for the EAD item "Supported LAKE application profiles" is shown in . The parameters "psk_resumption", "exporter_out_len", and "app_prof" of the LAKE_Information object are defined in , , and , respectively.

CDDL Definition of ead_value for the EAD Item "Supported LAKE application profiles" any } ; psk_resumption $$LAKE_Information_item //= ( 21: true / false ) ; exporter_out_len $$LAKE_Information_item //= ( 22: [1* [uint, uint]] ) ; app_prof $$LAKE_Information_item //= ( 23: profile_id / [2* profile_id] ) ]]>

Examples of ead_value are shown in .

Content Restrictions When the sender peer composes ead_value of the LAKE EAD item "Supported LAKE application profiles", the following applies. It is possible that ead_value provides an information corresponding to a LAKE_Information prescriptive parameter (see ). If ead_value specifies such an information multiple times, then each occurrence of that information MUST convey exactly the same content. With reference to the CBOR sequence APP_PROF_SEQ defined in , the enforcement of these content restrictions MUST take into account prescriptive parameters that are included:

• As elements of a LAKE_Information object specified within APP_PROF_SEQ; or
• As elements of a LAKE_Application_Profile object encoding a LAKE application profile, which is identified by its Profile ID specified within APP_PROF_SEQ.

If the Responder has received the EAD item in the EAD_1 field of LAKE message_1 and intends to include the EAD item in the EAD_2 field of LAKE message_2, then the Responder MUST further take into account the presence of such information in the received EAD item when composing ead_value. A consumer MUST treat as malformed an EAD item "Supported LAKE application profiles" whose ead_value does not comply with the restrictions above.

Indicating Support for Session Resumption with LAKE-PSK The specification defines LAKE-PSK, a LAKE authentication method by which two peers use a symmetric Pre-Shared Key (PSK) to mutually authenticate during a LAKE session. In particular, defines how LAKE-PSK is used to perform session resumption. That is, after successfully completing a LAKE session, two peers that support session resumption with LAKE-PSK can derive a resumption PSK and the corresponding key identifier. Later on, the two peers can run LAKE using the authentication method LAKE-PSK, authenticating each other by using the resumption PSK. This document defines the new parameter "psk_resumption" of the LAKE_Information object (see ). The parameter is of type non-prescriptive (NP) and is summarized in . The parameter is specified further below. LAKE_Information Parameter "psk_resumption"

Name	CBOR label	CBOR type	Registry	Description	Type
psk_resumption	21	True or False		Support for LAKE session resumption with LAKE-PSK	NP

• psk_resumption: This parameter indicates whether LAKE session resumption with the authentication method LAKE-PSK is supported, as per . In JSON, the "psk_resumption" value is a boolean. In CBOR, "psk_resumption" is the simple value true (0xf5) or false (0xf4), and has label 21.

The CDDL grammar describing the parameter "psk_resumption" when included in the CBOR-encoded LAKE_Information object is:

CDDL Definition of the Parameter "psk_resumption" when Included in the CBOR-encoded LAKE_Information Object. true / false ; psk_resumption ) ]]>

Agreeing on EDHOC_Exporter Output Lengths The main output of a successfully completed LAKE session is the shared secret session key PRK_out (see ). After having established PRK_out, the two peers can use the EDHOC_Exporter interface defined in , e.g., to derive keying material for an application protocol. Among its inputs, the EDHOC_Exporter interface includes "exporter_label" as a registered numeric identifier of the intended output and "length" as the length in bytes of the intended output. When using the EDHOC_Exporter interface, it is crucial that the two peers agree about the length in bytes of each intended output, in order to ensure the correctness of their operations. To this end, the two peers can rely on pre-defined default lengths, or agree out-of-band on alternative lengths. However, the two peers might need or prefer to explicitly agree about specific output lengths to use on a per-session basis. As described below, this can be achieved in-band, by using the LAKE EAD item "Supported LAKE application profiles" defined in . This document defines the new parameter "exporter_out_len" of the LAKE_Information object (see ). The parameter is of type prescriptive (P) and is summarized in . The parameter is specified further below. LAKE_Information Parameter "exporter_out_len"

Name	CBOR label	CBOR type	Registry	Description	Type
exporter_out_len	22	array	EDHOC Exporter Labels	Set of output lengths to use with the EDHOC_Exporter interface	P

• exporter_out_len: This parameter specifies a set of one or more pairs (X, Y), where:
  • The first element X specifies a value to use as first argument "exporter_label" when invoking the EDHOC_Exporter interface (see ). The value of X is taken from the 'Label' column of the "EDHOC Exporter Labels" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group .
  • The second element Y specifies the value to use as third argument "length" when invoking the EDHOC_Exporter interface using the value specified by X as first argument "exporter_label" (see ). The value specified by Y MUST be a valid value to use as "length" when using the value specified by X as "exporter_label". For example, when X specifies 0 as the "exporter_label" to derive an OSCORE Master Secret , Y is required to be not less than the "length" default value defined in , i.e., the key length (in bytes) of the application AEAD Algorithm of the selected cipher suite for the LAKE session.
  The set is encoded as a non-empty array, each element of which MUST be an array of exactly two elements, hence encoding one pair (X, Y). That is, each inner array includes X encoded as an unsigned integer and Y encoded as an unsigned integer, in this order. Within the set of pairs (X, Y), the order of the inner arrays encoding the pairs is not relevant. The set MUST NOT specify multiple pairs that have the same unsigned integer value as their first element X. In JSON, the "exporter_out_len" value is a non-empty array, each element of which is an array including two unsigned integers. In CBOR, "exporter_out_len" is a non-empty array that has label 22, each element of which is an array including two unsigned integers.

The CDDL grammar describing the parameter "exporter_out_len" when included in the CBOR-encoded LAKE_Information object is:

CDDL Definition of the Parameter "exporter_out_len" when Included in the CBOR-encoded LAKE_Information Object. [1* [uint, uint]] ; exporter_out_len ) ]]>

Within ead_value of the EAD item "Supported LAKE application profiles", the parameter "exporter_out_len" can be included within instances of the LAKE_Information object that are specified within the CBOR sequence APP_PROF_SEQ (see ). The recipient peer MUST abort the LAKE session and MUST reply with a LAKE error message with error code (ERR_CODE) 1 "Unspecified error", if any of the following occurs:

• The recipient peer does not recognize the value encoded by the first element X of a pair (X, Y) as a valid "exporter_label" to be used when invoking the EDHOC_Exporter interface.
• In a pair (X, Y), the value encoded by the second element Y is not valid to be used as "length" when invoking the EDHOC_Exporter interface using the value encoded by the first element X as "exporter_label".
• For a pair (X, Y), the recipient peer is not going to be able to invoke the EDHOC_Exporter interface using the values encoded by X and Y as the first argument "exporter_label" and the third argument "length", respectively.

If the Responder has received a LAKE message_1 including the EAD item "Supported LAKE application profiles" and specifying the parameter "exporter_out_len", then the following applies if the Responder includes the EAD item "Supported LAKE application profiles" in LAKE message_2, with ead_value specifying the parameter "exporter_out_len". Within ead_value of the EAD item included in LAKE message_2, the Responder MUST NOT specify any pair (X, Y) such that the unsigned integer value encoded by X was encoded by the first element of a pair within the EAD item included in the received LAKE message_1. If the Initiator receives a LAKE message_2 including the EAD item "Supported LAKE application profiles" and specifying the parameter "exporter_out_len", then the following applies if the Initiator included the EAD item "Supported LAKE application profiles" in LAKE message_1, with ead_value specifying the parameter "exporter_out_len". The Initiator MUST abort the LAKE session and MUST reply with a LAKE error message with error code (ERR_CODE) 1 "Unspecified error", if ead_value of the EAD item included in LAKE message_2 specifies any pair (X, Y) such that the unsigned integer value encoded by X was encoded by the first element of a pair of the EAD item included in the sent LAKE message_1. Since the parameter "exporter_out_len" is of type prescriptive, the restrictions compiled in apply. In particular, the "information" corresponding to the prescriptive parameter "exporter_out_len" is the "length" Y to use when invoking the EDHOC_Exporter interface using the paired "exporter_label" X. That is, if ead_value provides the length of the EDHOC_Exporter output for a given "exporter_label" multiple times, then each of such occurrences MUST specify the same "length" value. Within this constraint, it remains possible for ead_value to specify multiple instances of the LAKE_Information object within APP_PROF_SEQ and for each of such instances to include the parameter "exporter_out_len", which can overall encode a value different from that of the same parameter in another instance of the LAKE_Information object. The recipient peer MUST abort the LAKE session and MUST reply with a LAKE error message with error code (ERR_CODE) 1 "Unspecified error", if the parameter "exporter_out_len" is malformed or does not conform with the format and constraints defined above. In a LAKE session during which the EAD item "Supported LAKE application profiles" has been included in LAKE message_1 and/or message_2 as specifying the parameter "exporter_out_len", the following applies.

• The Initiator (Responder) considers the successful verification of LAKE message_2 (message_3) as a confirmed agreement with the other peer about how to invoke the EDHOC_Exporter interface, once the session key PRK_out for the present LAKE session is available. That is, for each pair (X, Y) specified by the exchanged EAD items, the two peers MUST use the unsigned integer values encoded by X and Y as the first argument "exporter_label" and the third argument "length", respectively.
• If a particular "exporter_label" value is not specified by the exchanged EAD items, then a possible invocation of the EDHOC_Exporter interface using that value as its first argument takes as value for its third argument "length" a pre-defined default value, or an alternative value agreed out-of-band.

When using the LAKE and OSCORE transport profile of the ACE framework , the parameter "exporter_out_len" MUST NOT be included within the LAKE_Information object specified as the value of the parameter/claim "lake_info".

Examples of ead_value shows an example in CBOR diagnostic notation of ead_value for the LAKE EAD item "Supported LAKE application profiles", when used in LAKE message_1. With reference to the CDDL grammar in , the following applies. The CBOR data item advertise_flag is present and encodes the CBOR simple value true (0xf5), hence asking the Responder to advertise the LAKE application profiles that it supports, when replying to the present LAKE message_1. The CBOR sequence APP_PROF_SEQ includes the following three elements:

• An element profile_id, specifying the Profile ID of a LAKE application profile supported by the Initiator. Specifically, that LAKE application profile is the well-known application profile MINIMAL-CS-2 defined in .
• An element profile_id, specifying the Profile ID of a LAKE application profile supported by the Initiator. Specifically, that LAKE application profile is the well-known application profile MINIMAL-CS-0 defined in .
• An element LAKE_Information, which in turn includes the following parameters:
  • "message_4", with value the CBOR simple value true (0xf5), hence indicating that LAKE message_4 is expected in the current LAKE session.
  • "eads", with value a CBOR array. The array includes two elements encoded as unsigned integers, i.e., the EAD labels 500 and 333 of the corresponding EAD items supported by the Initiator.
  • "trust_anchors", with value a CBOR map. The map includes a single element with value a CBOR array, which pertains to trust anchors whose purpose is the verification of authentication credentials of other LAKE peers in a LAKE session. In turn, the array includes two CBOR maps. Within the first CBOR map, its entry's value is a CBOR byte string that encodes 0x00ac. Within the second CBOR map, its entry's value is a CBOR byte string that encodes 0xff01ff. Both 0x00ac and 0xff01ff are binary key identifiers of trust anchors supported by the Initiator in the current LAKE session.

Example of ead_value for the EAD Item "Supported LAKE application profiles" in LAKE message_1 > ]]>

shows an example in CBOR diagnostic notation of ead_value for the LAKE EAD item "Supported LAKE application profiles", when used in LAKE message_2. With reference to the CDDL grammar in , the following applies. The CBOR sequence APP_PROF_SEQ includes the following two elements:

• An element profile_id, specifying the Profile ID of a LAKE application profile supported by the Responder. Specifically, that LAKE application profile is the well-known application profile MINIMAL-CS-2 defined in .
• An element LAKE_Information, which in turn includes the following parameters:
  • "comb_req", with value the CBOR simple value true (0xf5), hence indicating that the Responder supports the LAKE + OSCORE combined request defined in (denoted therein as "EDHOC + OSCORE request").
  • "eads", with value a CBOR array. The array includes two elements encoded as unsigned integers, i.e., the EAD labels 500 and 999 of the corresponding EAD items supported by the Responder.
  • "trust_anchors", with value a CBOR map. The map includes a single element with value an inner CBOR map, which pertains to trust anchors whose purpose is the verification of authentication credentials of other LAKE peers in a LAKE session. Within the inner map, its entry's value is a CBOR byte string that encodes 0x91ab, i.e., the binary key identifier of a trust anchor supported by the Responder in the current LAKE session.

Example of ead_value for the EAD Item "Supported LAKE application profiles" in LAKE message_2 > ]]>

In the LAKE Error Message This section defines the error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles", which is registered in of this document. The error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles" MUST only be used when replying to LAKE message_1. If a LAKE error message with error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles" is received as reply to a LAKE message different from LAKE message_1, then the recipient of the error message MUST ignore what is specified in ERR_INFO. The Responder MUST NOT abort a LAKE session exclusively due to the wish of sending an error message with error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles". Instead, the Responder can advertise the LAKE application profiles that it supports to the Initiator by means of the EAD item "Supported LAKE application profiles" defined in , specifying it in the EAD_2 field of the LAKE message_2 to send in the LAKE session. When replying to a LAKE message_1 with an error message, the Responder has to consider the reason for which it is aborting the LAKE session and MUST NOT specify error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles" if a different, more appropriate error code can be specified instead. For example, if the negotiation of the selected cipher suite fails (see ), the error message MUST NOT specify error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles", since the error message intended to be used in that case specifies error code (ERR_CODE) 2 "Wrong selected cipher suite" and conveys SUITES_R as ERR_INFO. When using error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles", the error information specified in ERR_INFO MUST be a CBOR byte string with value the binary representation of the CBOR sequence ERROR_OUTER_SEQ. In turn, ERROR_OUTER_SEQ is composed of the following elements, in the order specified below:

• The CBOR text string diagnostic_info, which encodes a human-readable diagnostic message that SHOULD be written in English (for example, "Method not supported"). The diagnostic text message provides information about the error that occurred, and it is mainly intended for software engineers who during debugging need to interpret it in the context of the LAKE specification. The diagnostic message SHOULD be provided to the calling application where it SHOULD be logged. This element conveys the same information that would be conveyed by ERR_INFO within a LAKE error message with error code (ERR_CODE) 1 "Unspecified error" (see ).
• The CBOR sequence APP_PROF_SEQ, which has the same format and semantics specified in , except for the following difference: for each element of the CBOR sequence that is a LAKE_Information object, such an object MUST NOT include the element "exporter_out_len" defined in . The recipient peer MUST silently ignore elements of the CBOR sequence APP_PROF_SEQ that are malformed or do not conform with the intended format of APP_PROF_SEQ.

The CDDL grammar describing ERR_INFO is shown in .

CDDL Definition of ERR_INFO for the LAKE Error Message with Error Code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles"

Example of ERR_INFO shows an example in CBOR diagnostic notation of ERR_INFO for the LAKE error message with error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles". With reference to the CDDL grammar in and , the following applies. The CBOR text string diagnostic_info encodes the text string "Method not supported". The CBOR sequence APP_PROF_SEQ includes the following two elements:

• An element profile_id, specifying the Profile ID of a LAKE application profile supported by the Responder. Specifically, that LAKE application profile is the well-known application profile MINIMAL-CS-0 defined in .
• An element LAKE_Information, which in turn includes the following parameters:
  • "comb_req", with value the CBOR simple value true (0xf5), hence indicating that the Responder supports the LAKE + OSCORE combined request defined in (denoted therein as "EDHOC + OSCORE request").
  • "eads", with value a CBOR array. The array includes two elements encoded as unsigned integers, i.e., the EAD labels 500 and 777 of the corresponding EAD items supported by the Responder.
  • "trust_anchors", with value a CBOR map. The map includes a single element with value an inner CBOR map, which pertains to trust anchors whose purpose is the verification of authentication credentials of other LAKE peers in a LAKE session. Within the inner map, its entry's value is a COSE_CertHash corresponding to an X.509 certificate that the Responder supports as a trust anchor when running LAKE.

Example of ERR_INFO for the LAKE Error Message with Error Code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles" > ]]>

Advertising Supported LAKE Application Profiles using DNS SVCB Resource Records Given a server, its support for LAKE and for LAKE application profiles can be advertised using DNS SVCB Resource Records (RR) . To this end, this document specifies the SvcParamKeys "lakepath" and "lake-app-prof", which are defined below and are registered in .

• "lakepath" - The SvcParamKey "lakepath" is single-valued and specifies a list of one or more absolute paths to LAKE resources at the server.
  • The wire-format value of "lakepath" is the binary representation of the CBOR data item lakepath-value, which MUST exactly fill the SvcParamValue. In particular, lakepath-value MUST be a CBOR byte string PATH_BSTR or a CBOR array. In the latter case, the array MUST include at least two elements, each of which MUST be a CBOR byte string PATH_BSTR. The SVCB RR MUST be considered malformed if the SvcParamValue ends within lakepath-value or if lakepath-value is malformed. The value of each CBOR byte string PATH_BSTR is the binary representation of a CBOR sequence PATH_SEQ composed of zero or more CBOR text strings. In particular, each PATH_SEQ specifies the URI path of a LAKE resource at the server, with each CBOR text string within that PATH_SEQ specifying a URI path segment. If lakepath-value is a CBOR array, it MUST NOT include any two elements that specify the same URI path. The CDDL grammar describing the CBOR data item lakepath-value is shown in .
  • The presentation format value of "lakepath" SHALL be a comma-separated list (see ) of one or more absolute paths to LAKE resources at the server. The same considerations for the "," and "\" characters in paths for zone-file implementations as for the alpn-ids in an "alpn" SvcParam apply (see ). The i-th path in the presentation format value is the textual representation of the path specified by the i-th CBOR sequence PATH_SEQ in the wire-format value (see above). The textual representation of each path follows the semantics of path-absolute shown in the ABNF definition in , which is provided by the ABNF for path-absolute in . In particular, given the path specified by a CBOR sequence PATH_SEQ, segment-nz is the value of the first CBOR text string in PATH_SEQ (if any), while each segment is the value of a CBOR text string following the first one in PATH_SEQ (if any).
• "lake-app-prof" - The SvcParamKey "lake-app-prof" is single-valued and specifies a set of LAKE application profiles that the server supports.
  • The wire-format value of "lake-app-prof" is the binary representation of the CBOR data item lake-app-prof-value, which MUST exactly fill the SvcParamValue. In particular, lake-app-prof-value MUST be a CBOR byte string. The value of the CBOR byte string is the binary representation of the CBOR sequence SVCB_LAKE_APP_PROF, which is composed of one or two elements as specified below. The SVCB RR MUST be considered malformed if the SvcParamValue ends within lake-app-prof-value or if lake-app-prof-value is malformed.
    • The first element advertise_flag_svcb is OPTIONAL. If present, it MUST encode the CBOR simple value true (0xf5). If advertise_flag_svcb is present, a peer that runs LAKE with the server is encouraged to advertise the LAKE application profiles that it supports, when sending to the server its first LAKE message in a LAKE session. In order to do that, the peer can rely as appropriate on the LAKE EAD item "Supported LAKE application profiles" (see ) when sending a LAKE message_1 or message_2, or on a LAKE error message with error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles" (see ). If the peer supports the LAKE EAD item "Supported LAKE application profiles" or the error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles", the peer MUST use those as appropriate to honor the wish of the server and accordingly advertise the LAKE application profiles that it supports.
    • The second element server_info is REQUIRED, and it MUST be a CBOR byte string APP_BSTR or a CBOR array. In the latter case, the array MUST include at least two elements, each of which MUST be a CBOR byte string APP_BSTR. The value of each CBOR byte string APP_BSTR is the binary representation of the CBOR sequence APP_PROF_SEQ. In particular, APP_PROF_SEQ has the same format and semantics specified in , except for the following difference: for each element of the CBOR sequence that is a LAKE_Information object, such an object MUST NOT include the element "exporter_out_len" defined in . The SVCB RR MUST be considered malformed if APP_PROF_SEQ is malformed or does not conform with the intended format.
    An SVCB RR might not be intended to advertise what LAKE application profiles a server supports for a given LAKE resource that it hosts. In such a case, server_info can be composed such that the CBOR sequence APP_PROF_SEQ pertaining to that resource only consists of a single LAKE_Information object as an empty CBOR map. The CDDL grammar describing the CBOR data item lake-app-prof-value is shown in .
  • The presentation format value of "lake-app-prof" SHALL be the CBOR extended diagnostic notation (see and ) of lake-app-prof-value in the wire-format value (see above). When producing the presentation format value, care ought to be taken in representing Unicode with the limited ASCII character subset (e.g., by means of Punycode ) and in removing unnecessary common blank spaces within the CBOR extended diagnostic notation.

If the SvcParamKey "lake-app-prof" is not present in the SVCB RR, then the SvcParamKey "lakepath", if present, still specifies the URI paths of LAKE resources at the server. However, no information is provided about what LAKE application profiles the server supports. If the SvcParamKey "lake-app-prof" is present in the SVCB RR, then the following applies to server_info therein.

• If the SvcParamKey "lakepath" is not present in the SVCB RR, then server_info MUST be a CBOR byte string. The information specified by the SvcParamKey "lake-app-prof" pertains to the LAKE resource at the server with URI path "/.well-known/edhoc".
• If the SvcParamKey "lakepath" is present in the SVCB RR, then the following applies.
  • If the value of the SvcParamKey "lakepath" is a CBOR byte string, then server_info MUST be a CBOR byte string. The information specified by the SvcParamKey "lake-app-prof" pertains to the LAKE resource at the server with URI path specified by the SvcParamKey "lakepath".
  • If the value of the SvcParamKey "lakepath" is a CBOR array including N elements, then server_info MUST be a CBOR array including N elements. The information specified by the i-th element of server_info pertains to the LAKE resource at the server with URI path specified by the i-th element of the CBOR array within the SvcParamKey "lakepath".

A consumer MUST treat as malformed an SVCB RR, in the case that the SvcParamKeys "lakepath" and "lake-app-prof", if present, do not comply with the format and restrictions defined above.

CDDL Definition of the Value of the SvcParamKey "lakepath"

ABNF Definition of path-absolute

CDDL Definition of the Value of the SvcParamKey "lake-app-prof"

Examples of Wire-Format Values of the SvcParamKeys Using CBOR diagnostic notation, this section provides examples of wire-format values of the SvcParamKeys "lakepath" and "lake-app-prof", within an SVCB RR corresponding to a given server. shows an example of the SvcParamKey "lakepath", with reference to the CDDL grammar in . In the example, two URI paths are specified, i.e., one for the LAKE resource at "/.well-known/edhoc" and one for the LAKE resource at "/lake-alt".

Example of Wire-Format Value of the SvcParamKey "lakepath" within an SVCB RR >, << / PATH_BSTR / "lake-alt" / path_segment / >> ] ]]>

Assuming an SVCB RR that includes the SvcParamKey "lakepath" shown in , the following shows an example of the SvcParamKey "lake-app-prof" within the same SVCB RR, with reference to the CDDL grammar in . In particular, the following applies. The CBOR data item advertise_flag_svcb is present and encodes the CBOR simple value true (0xf5), hence indicating that a peer that runs LAKE with the server is encouraged to advertise the LAKE application profiles that it supports, when sending to the server its first LAKE message in a LAKE session. The CBOR data item server_info is a CBOR array, which includes two CBOR byte strings APP_BSTR. In particular:

• The value of the first CBOR byte string is the binary representation of a CBOR sequence APP_PROF_SEQ, which advertises the LAKE application profiles that the server supports when running LAKE through the resource with URI path "/.well-known/edhoc".
• The value of the second CBOR byte string is the binary representation of a CBOR sequence APP_PROF_SEQ, which advertises the LAKE application profiles that the server supports when running LAKE through the resource with URI path "/lake-alt".

Example of Wire-Format Value of the SvcParamKey "lake-app-prof" within an SVCB RR >, << / APP_BSTR / e'APP-PROF-MINIMAL-CS-2', / profile_id / { / LAKE_Information / e'comb_req' : true, e'eads' : [500, 999], e'trust_anchors' : { e'lake_cred' : { e'kid_ta_type' : h'91ab' } } } >> ] >> ]]>

Well-Known LAKE Application Profiles This section defines a set of well-known LAKE application profiles that are meant to reflect what is most common and expected to be supported by LAKE peers. The well-known application profiles are not to be intended as "default" profiles to use, in the case that no other indication is provided to LAKE peers. In particular, a LAKE peer MUST NOT assume that, unless otherwise indicated, any of such profiles is used when running LAKE through a well-known LAKE resource, such as the resource at /.well-known/edhoc when LAKE messages are transported as payload of CoAP messages (see ). Building on the above, the well-known application profiles are not intended to deviate from what is mandatory to support for LAKE peers, which is defined by the compliance requirements in . In the rest of this section, each well-known application profile is represented by means of a LAKE_Application_Profile object (see ) using the CBOR extended diagnostic notation. An entry for each well-known application profile is also registered at the "LAKE Application Profiles" registry defined in of this document.

Well-Known Application Profile MINIMAL-CS-2 This minimal application profile is suitable for LAKE peers with very limited capabilities, as they benefit from efficiently using: non-signature keys for authentication with LAKE method 3; LAKE cipher suite 2, which is already expected to be supported; the compact credential type CBOR Web Token Claims Set (CCS) identified by reference with a compact "kid". This application profile is aligned with the example trace of LAKE compiled in .

Well-Known Application Profile MINIMAL-CS-0 This minimal application profile is suitable for LAKE peers with very limited capabilities, and it differs from the one in only by indicating a different LAKE cipher suite (0) from those intended for constrained environments.

Well-Known Application Profile BASIC-CS-2-X509 This basic application profile is suitable for LAKE peers with fairly limited capabilities, which can afford using: signature keys or non-signature keys for authentication with LAKE method 0 or 3; LAKE cipher suite 2; the credential type CCS identified by reference with "kid", or X.509 certificates identified by reference with "x5t". This application profile is aligned with the example trace of LAKE compiled in .

Well-Known Application Profile BASIC-CS-0-X509 This basic application profile is suitable for LAKE peers with fairly limited capabilities, and it differs from the one in only by indicating a different LAKE cipher suite (0) from those intended for constrained environments. This application profile is aligned with the example trace of LAKE compiled in .

Well-Known Application Profile BASIC-CS-2-C509 This basic application profile is suitable for LAKE peers with fairly limited capabilities, and it differs from the one in only by indicating support for C509 certificates identified by reference with "c5t", instead of X.509 certificates identified by reference with "x5t".

Well-Known Application Profile BASIC-CS-0-C509 This basic application profile is suitable for LAKE peers with fairly limited capabilities, and it differs from the one in only by indicating support for C509 certificates identified by reference with "c5t", instead of X.509 certificates identified by reference with "x5t".

Well-Known Application Profile INTERMEDIATE-CS-2 This intermediate application profile is suitable for LAKE peers that, even if with somewhat limited capabilities, can afford a moderate set of options: signature keys or non-signature keys for authentication with LAKE method 0 or 3; LAKE cipher suite 2; the credential type CCS identified by reference with "kid" or by value with "kccs", or X.509 certificates identified by reference with "x5t" or by value with "x5chain", or C509 certificates identified by reference with "c5t" or by value with "c5c". This application profile is aligned with the example trace of LAKE compiled in .

Well-Known Application Profile INTERMEDIATE-CS-0 This intermediate application profile is suitable for LAKE peers that, even if with somewhat limited capabilities, can afford a moderate set of options, and it differs from the one in only by indicating a different LAKE cipher suite (0) from those intended for constrained environments. This application profile is aligned with the example trace of LAKE compiled in .

Well-Known Application Profile EXTENSIVE This extensive application profile is suitable for LAKE peers that, even if with somewhat limited capabilities, can afford an extensive set of options: all the four original LAKE cipher suites intended for constrained environments; all the four original LAKE authentication methods based on public key authentication; the credential type CCS identified by reference with "kid" or by value with "kccs", or CBOR Web Token (CWT) identified by reference with "kid" or by value with "kcwt", or X.509 certificates identified by reference with "x5t" or by value with "x5chain", or C509 certificates identified by reference with "c5t" or by value with "c5c". This application profile is aligned with the example traces of LAKE compiled in Sections and of .

Identifiers of Well-Known LAKE Application Profiles This document defines the following identifiers of well-known LAKE application profiles. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. LAKE Well-Known Application Profiles

Profile ID	Name	Description	Reference
0	MINIMAL-CS-2	Method 3; Cipher Suite 2; CCS; kid	[RFC-XXXX, ]
1	MINIMAL-CS-0	Method 3; Cipher Suite 0; CCS; kid	[RFC-XXXX, ]
2	BASIC-CS-2-X509	Methods (0, 3); Cipher Suite 2; (CCS, X.509 certificates); (kid, x5t)	[RFC-XXXX, ]
3	BASIC-CS-0-X509	Methods (0, 3); Cipher Suite 0; (CCS, X.509 certificates); (kid, x5t)	[RFC-XXXX, ]
4	BASIC-CS-2-C509	Methods (0, 3); Cipher Suite 2; (CCS, C509 certificates); (kid, c5t)	[RFC-XXXX, ]
5	BASIC-CS-0-C509	Methods (0, 3); Cipher Suite 0; (CCS, C509 certificates); (kid, c5t)	[RFC-XXXX, ]
6	INTERMEDIATE-CS-2	Methods (0, 3); Cipher Suite 2; (CCS, X.509/C509 certificates); (kid, kccs, x5t, x5chain, c5t, c5c)	[RFC-XXXX, ]
7	INTERMEDIATE-CS-0	Methods (0, 3); Cipher Suite 0; (CCS, X.509/C509 certificates); (kid, kccs, x5t, x5chain, c5t, c5c)	[RFC-XXXX, ]
8	EXTENSIVE	Methods (0, 1, 2, 3); Cipher Suites (0, 1, 2, 3); (CCS, CWT, X.509/C509 certificates); (kid, kccs, kcwt, x5t, x5chain, c5t, c5c)	[RFC-XXXX, ]

Operational Considerations This section compiles the operational considerations that hold for this document.

Relation with Network Operations The means defined in this document are largely about aiding peers in running the LAKE protocol by achieving a common understanding of what they support, thereby facilitating interoperability between LAKE implementations. Such coordination is expected to keep authenticated key exchange through LAKE a smooth process in itself and with respect to network operation and management. The use of these coordinating means in itself is not expected to have a notable impact on performance and network operations, and it is embedded within other relevant network protocols and components such as: the discovery of resources through web-linking and CoRE Link Format (see and ); the execution of the LAKE protocol itself (see ); and the discovery of server-related information via DNS SVCB RR (see ).

Source of Data for Network Operators As further discussed in , information about what LAKE application profiles a peer supports could be advertised in plain, depending on the approach specifically used. In such a case, a network operator can passively observe the plain exchange of such information, thereby gaining (a partial) knowledge of LAKE application profiles that are supported and used in the network. From the perspective of an individual network operator, this knowledge can be useful for (fine-)tuning the allocation of network resources. Multiple, cooperating network operators could build an aggregated knowledge that indicates broad "trends" about LAKE application profiles and their use. This raises awareness of what appears to be most supported and preferred by LAKE peers, which can influence priority decisions about the development and use of LAKE implementations, as well as the operations of infrastructures for provisioning and validating public authentication credentials. As noted in , well-known LAKE application profiles are not meant to be default profiles to use, and they are not meant to deviate from the LAKE compliance requirements compiled in . Instead, they are meant to reflect what is most common and expected to be supported by LAKE peers. Hence, developing aggregated knowledge on typical uses of LAKE can help identify LAKE application profiles that have become de facto well-known, thereby further accelerating their adoption.

Logging and Reporting When using the means defined in this document, LAKE peers are not expected to keep any particular log of such use, or to go beyond expectations already in place as to the logging of LAKE sessions. However, after gaining knowledge about what LAKE application profiles are supported by a given LAKE peer and verifying that such knowledge is reliable and authentic (see ), it is encouraged to locally persist that knowledge for a non-negligible amount of time determined by the application. Especially under the assumption that what LAKE peers support does not (often) change, this avoids the need to repeatedly re-gain the same knowledge at least in the short term. If a LAKE session fails due to an apparent mismatch with gained knowledge about commonly supported LAKE application profiles, a peer can report such a failure to a network manager or infrastructure operator. This can help identify peers whose behavior deviates from what is advertised in terms of LAKE application profiles that they allegedly support. In turn, this can be used to detect misbehaving peers, outdated information about what peers support, or ongoing tampering of such information if that is advertised in plain (see ). It is out of the scope of this document what specific semantics and data model are used for producing and processing such reports. Specific semantics and data models can be defined by applications and future specifications.

Security Considerations The security considerations compiled in hold for this document. The security considerations compiled in also apply, when LAKE is transported over CoAP and specifically when using the LAKE + OSCORE request defined in (denoted therein as "EDHOC + OSCORE request"). Instances of the LAKE_Application_Profile objects (see ) ought to be accepted only if provided by an identifiable, trusted party by using secure communication. When this is not the case, a LAKE peer can be induced to: erroneously identify a given LAKE application profile with a wrong Profile ID; erroneously believe a given LAKE application profile to exist in the first place; develop a wrong understanding of what a given LAKE application profile consists of. Different security guarantees can be achieved about the acquired information on the LAKE application profiles supported by a given peer, depending on the specific approach used. The potential consequences of acquiring such information in a non secured way are discussed later in this section.

• With respect to using web linking (see and ), the security considerations in apply. When specifically relying on CoRE Link Format , the security considerations in also apply. Clearly, the discovery of LAKE resources at a server is intended to happen before running LAKE with the server. At that point in time, the peer attempting to discover LAKE resources at the server is unlikely to already have a secure communication association with the server. Therefore, the discovery process is likely to use unsecured communication. Alternatively, LAKE resources at a server can be discovered by securely interacting with separate discovery services, e.g., by using the CoRE Resource Directory .
• With respect to using the LAKE EAD item "Supported LAKE application profiles" (see ), the following applies.
  • When the EAD item is included in LAKE message_1, the information conveyed therein is not protected. However, changing LAKE message_1 in transit (e.g., by adding, removing, or modifying the EAD item) would result in the Initiator aborting the LAKE session, after receiving and failing to verify LAKE message_2.
  • When the EAD item is included in LAKE message_2, the information conveyed therein is protected by LAKE.
• With respect to using a LAKE error message with error code (ERR_CODE) TBD_ERROR_CODE "Unspecified error and supported LAKE application profiles", the information conveyed in ERR_INFO is not protected, just like when any other error code is used.
• With respect to using the SvcParamKeys "lakepath" and "lake-app-prof" within an SVCB RR (see ), the security considerations from and apply. It is encouraged that DNS is used with secure communication. Known threats for unprotected DNS are described in and .

If information about LAKE application profiles supported by a peer is distributed in an unprotected way (e.g., through unsecured communication), a consumer treats such information as a hint and MUST NOT locally persist that information until verifying that it is reliable and authentic. For example, if the Responder receives a LAKE message_1 that includes the LAKE EAD item "Supported LAKE application profiles", the Responder will initially treat the information conveyed therein as a hint, and it is able to verify such information as reliable and authentic after receiving and successfully processing the later LAKE message_3 in the same LAKE session. If the acquired information has been tampered with and does not reflect what a given peer supports and intends to advertise, this can set wrong expectations about what is effectively possible to do when running LAKE with that peer. Although this can still result in successfully running LAKE with a configuration that is commonly supported, such configuration would probably not have been selected, had reliable and authentic information been acquired. In the worst case, there might be the erroneous belief that there is not sufficient shared support with that peer. What is discussed above does not have an impact on the security of the LAKE protocol in itself. That is, even when the available information about supported LAKE application profiles is not guaranteed to be reliable and authentic, the successful completion of a LAKE session still provides the security guarantees that are expected as per the way the session was run (e.g., based on the selected cipher suite and LAKE method used).

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.

Media Type Registrations IANA is asked to register the media type "application/lake-app-profile+cbor-seq". This registration follows the procedures specified in . Type name: application Subtype name: lake-app-profile+cbor-seq Required parameters: N/A Optional parameters: N/A Encoding considerations: Must be encoded as a CBOR sequence of CBOR maps . Each of the CBOR maps is a LAKE_Application_Profile object (see of [RFC-XXXX]). Each element of each CBOR map is also defined as an element of the CBOR-encoded LAKE_Information object from . Security considerations: See of [RFC-XXXX]. Interoperability considerations: N/A Published specification: [RFC-XXXX] Applications that use this media type: Applications that need to describe, distribute, and store a representation of a set of one or more LAKE application profiles (see of [RFC-XXXX] and ). Fragment identifier considerations: N/A Additional information: N/A Person & email address to contact for further information: LAKE WG mailing list (lake@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org) Intended usage: COMMON Restrictions on usage: None Author/Change controller: IETF Provisional registration: No

CoAP Content-Formats Registry IANA is asked to add the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Content Type: application/lake-app-profile+cbor-seq Content Coding: - ID: TBD (range 0-255) Reference: [RFC-XXXX]

Target Attributes Registry IANA is asked to register the following entries in the "Target Attributes" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

• Attribute Name: ed-prof
• Brief Description: A supported LAKE application profile
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Attribute Name: ed-ta-edcred-uuid
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other LAKE peers, as a UUID
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Attribute Name: ed-ta-edcred-kid
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other LAKE peers, as a binary key identifier
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Attribute Name: ed-ta-edcred-c5t
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other LAKE peers, as a hash of a C509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Attribute Name: ed-ta-edcred-c5u
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other LAKE peers, as a URI pointing to a C509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Attribute Name: ed-ta-edcred-x5t
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other LAKE peers, as a hash of an X.509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Attribute Name: ed-ta-edcred-x5u
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other LAKE peers, as a URI pointing to an X.509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Attribute Name: ed-psk-resumption
• Brief Description: Hint: support for LAKE session resumption with LAKE-PSK
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

LAKE Information Registry IANA is asked to register the following entries in the "LAKE Information" registry defined in within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.

• Name: psk_resumption
• CBOR label: 21 (suggested)
• CBOR type: True or False
• Registry:
• Description: Support for LAKE session resumption with LAKE-PSK
• Type: NP
• Specification: [RFC-XXXX]

• Name: exporter_out_len
• CBOR label: 22 (suggested)
• CBOR type: array
• Registry: EDHOC Exporter Labels
• Description: Set of output lengths to use with the EDHOC_Exporter interface
• Type: P
• Specification: [RFC-XXXX]

• Name: app_prof
• CBOR label: 23 (suggested)
• CBOR type: int or array
• Registry: LAKE Application Profiles registry
• Description: Set of supported LAKE application profiles
• Type: NP
• Specification: [RFC-XXXX]

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

• Name: Supported LAKE application profiles
• Label: TBD_EAD_LABEL (range 0-23)
• Description: Set of supported LAKE application profiles
• Reference: [RFC-XXXX, ]

EDHOC Error Codes Registry IANA is asked to register the following entry in the "EDHOC Error Codes" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.

• ERR_CODE: TBD_ERROR_CODE (range -24 to 23)
• ERR_INFO Type: bstr
• Description: Unspecified error and supported LAKE application profiles
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

DNS SVCB Service Parameter Keys (SvcParamKeys) IANA is asked to add the following entries to the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry within the "DNS Service Bindings (SVCB)" registry group.

• Number: TBD1
• Name: lakepath
• Meaning: LAKE resource path
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Number: TBD2
• Name: lake-app-prof
• Meaning: Supported LAKE application profiles
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

LAKE Application Profiles Registry IANA is requested to create a new "LAKE Application Profiles" 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:

• Profile ID: This field contains the value used to identify the LAKE application profile. These values MUST be unique. The value can be a positive 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".
• Name: This field contains the name of the LAKE application profile.
• Description: This field contains a short description of the LAKE application profile.
• Reference: This field contains a pointer to the public specification for the LAKE application profile.

This registry has been initially populated with the values in .

Expert Review Instructions "Standards Action with Expert Review" and "Specification Required" are two of the registration policies defined for the IANA registry 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] This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. 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. 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. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. 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. 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. 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. 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 the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. 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. 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 Ericsson RISE RISE 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. 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. 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 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 Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK] Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community. This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. This document contains example traces of Ephemeral Diffie-Hellman Over COSE (EDHOC). 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).

CDDL Model

CDDL model

Document Updates

Version -06 to -07

• Relate the LAKE_Application_Profile object to the corresponding media type "application/lake-app-profile+cbor-seq".
• Use normative language on not storing hints until verified.
• Use "app_prof_param" in the CDDL model of abbreviations.
• Fixed reference to BCP14/RFC2119/RFC8174.

Version -05 to -06

• Renamed EDHOC to LAKE as appropriate. This also includes:
  • EDHOC_Application_Profile -> LAKE_Application_Profile
  • EDHOC_Information -> LAKE_Information
  • "EDHOC Application Profiles" registry -> "LAKE Application Profiles" registry
  • "EDHOC Information" registry -> "LAKE Information" registry
  • "EDHOC Trust Anchor Purposes" registry -> "LAKE Trust Anchor Purposes" registry
  • "EDHOC Trust Anchor Types" registry -> "LAKE Trust Anchor Types" registry
• Fixed CDDL definitions:
  • Of OUTER_SEQ and ERROR_OUTER_SEQ.
  • Of advertise_flag_svcb in the SvcParamKey (was advertise_flag).
• Added reference to RFC 4648; more precise wording on base64 encoding.
• IANA considerations: use TBD placeholders for SvcParamKeys.
• Editorial fixes.

Version -04 to -05

• Fixed CDDL definitions of the EDHOC_Application_Profile object and of the ead_value for the new EAD Item.
• Improved EDHOC error message with the new error code:
  • Extended semantics of ERR_INFO to also provide diagnostic information.
  • Updated error code description to "Unspecified error and supported EDHOC application profiles"
• Defined the web link parameter "ed-psk-resumption" and the EDHOC_Information object parameter "psk_resumption", to indicate support for session resumption with EDHOC-PSK.
• Clarifications:
  • Purpose of "app_prof" in the EDHOC_Application_Profile object and in the EDHOC_Information object.
  • Difference between the EDHOC_Application_Profile object and the EDHOC_Information object.
  • Purpose and applicability of parameters for web linking in the introduction.
  • Motivation and benefits of the new EAD item and error code.
  • Handling of deviations from what is specified by prescriptive EDHOC_Information parameters.
  • Extraction of CDDL definitions from the XML, using an XPath expression.
  • Short explanation of well-known profiles.
  • Full name of error codes used through the text.
  • Gained knowledge about other peers is persisted only if verified as reliable and authentic.
• IANA considerations:
  • Added references to IANA registries.
  • More details in the media type registration.
  • Proposed codepoints picked up among unassigned ones.
• Editorial fixes and improvements.

Version -03 to -04

• Removed parameters that were removed from draft-ietf-ace-edhoc-oscore-profile.
• Renamed "reply_flag" to "advertise_flag".
• Defined use of "advertise_flag" also in SVCB Resource Records.
• Added guidelines on using the EAD item "Supported EDHOC application profiles" only to take advantage of advertise_flag.
• Added guidelines on having per-resource empty advertisements in an SVCB RR.
• Clarifications:
  • Deviations from prescriptive parameters are assessed throughout the whole EDHOC session.
• CDDL definitions:
  • Added CDDL definitions of the parameters "app_prof" and "exporter_out_len" for the CBOR-encoded EDHOC_Information object.
  • Fixed CDDL definition of ead_value of the EAD item "Supported EDHOC application profiles".
• Added new examples:
  • Response in CoRE link-format using the target attributes 'ed-ta-edcred-*'.
  • ead_value for the EDHOC EAD item "Supported EDHOC application profiles".
  • Added examples of wire-format values of the SvcParamKeys "edhocpath" and "edhoc-app-prof".
  • ERR_INFO for the EDHOC error message with Error Code TBD_ERROR_CODE.
• Added "Operational Considerations" section.
• Added security considerations.
• Editorial fixes and improvements.

Version -02 to -03

• Removed restrictions on the scope of the EDHOC_Application_Profile object.
• Forbidden violations of prescriptive indications in the EAD item. The EDHOC session fails if such a violation is detected.
• Extended semantics of ead_value: optional boolean flag when the EAD item is used in EDHOC message_1.
• Defined parameter "exporter_out_len", for in-band negotiation of EDHOC_Exporter output lengths through the EAD item "Supported EDHOC application profiles".
• Specified wire-format and presentation format for the SvcParamKeys.
• Fixed errors in CDDL notations.
• Specified type of "app_prof" in the IANA registration request.
• Clarifications and editorial improvements.

Version -01 to -02

• Revised order of sections.
• Use of parameters aligned with corresponding updates in draft-ietf-ace-edhoc-oscore-profile.
• EAD item "Supported EDHOC application profiles":
  • It can be used only in a critical way.
  • Improved semantics of ead_value.
  • Content restrictions to avoid inconsistent information.
• Use of the parameter "app_prof" in draft-ietf-ace-edhoc-oscore-profile:
  • Improved co-existence with other parameters.
  • Content restrictions to avoid inconsistent information.
• Error handling:
  • EAD item "Supported EDHOC application profiles" occurring multiple times in EDHOC message_1 or message_2.
  • EAD item "Supported EDHOC application profiles" in EDHOC message_3 or message_4.
  • Invalid ead_value in EAD item "Supported EDHOC application profiles".
  • Invalid information in EDHOC error message with new error code.
• Fixed encoding of ERR_INFO for the EDHOC error message with the new error code.
• EDHOC_Application_Profile object
  • Clarified scope.
  • Clarified meaning of boolean parameters that are non-prescriptive.
  • Forbid the presence of the element "trust_anchors".
• Advertisement of Supported EDHOC Application Profiles using SVCB Resource Records.
• Updated integer abbreviations for the EDHOC_Information parameters.
• Editorial improvements.

Version -00 to -01

• Clarified motivation in the abstract and introduction.
• Moved definition of EDHOC_Information parameters to draft-ietf-ace-edhoc-oscore-profile.
• Renamed ed-idep-t x as ed-epid-t.
• Content-Format abbreviated as "ct" (not "cf").
• CBOR abbreviation of "app_prof" changed to 23.
• Added preamble on identifying application profiles by Profile ID.
• Defined target attributes "ed-ta-*" for specifying supported trust anchors.
• Defined new EAD item and error code to advertise supported EDHOC application profiles.
• Defined how to handle non admitted parameters.
• Renamed well-known EDHOC application profiles.
• Updated IANA considerations:
  • Suggested range 0-255 for CoAP Content-Format ID.
  • Requested registration for target attributes "ed-ta-*".
  • Removed requests for registration of removed parameters.
• Updated references.
• Editorial improvements.

Acknowledgments The authors sincerely thank , , , , , , , , , , and for their feedback and comments. The target attributes "ed-ta-*" for specifying supported trust anchors build on a proposal originally described in . This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.