]> Ericsson AB

Sweden goran.selander@ericsson.com

Ericsson AB

Sweden john.mattsson@ericsson.com

INRIA

France malisa.vucinic@inria.fr

Sandelman Software Works

Canada mcr+ietf@sandelman.ca

Institute of Embedded Systems, ZHAW

Switzerland aureliorubendario.schellenbaum@zhaw.ch

Security LAKE Working Group Internet-Draft This document describes a procedure for augmenting the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC with third party assisted authorization, targeting constrained IoT deployments (RFC 7228). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction For constrained IoT deployments the overhead and processing contributed by security protocols may be significant which motivates the specification of lightweight protocols that are optimizing, in particular, message overhead (see ). This document describes a procedure for augmenting the lightweight authenticated Diffie-Hellman key exchange EDHOC with third party-assisted authorization. The procedure involves a device, a domain authenticator, and an authorization server. The device and authenticator perform mutual authentication and authorization, assisted by the authorization server which provides relevant authorization information to the device (a "voucher") and to the authenticator. The protocol assumes that authentication between device and authenticator is performed with EDHOC, and defines the integration of a lightweight authorization procedure using the External Authorization Data (EAD) field defined in EDHOC. In this document we consider the target interaction for which authorization is needed to be "enrollment", for example joining a network for the first time (e.g., ), but it can be applied to authorize other target interactions. The protocol enables a low message count by performing authorization and enrollment in parallel with authentication, instead of in sequence which is common for network access. It further reuses protocol elements from EDHOC leading to reduced message sizes on constrained links. This protocol is applicable to a wide variety of settings, and can be mapped to different authorization architectures.

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. Readers are expected to have an understanding of CBOR and EDHOC . Appendix C.1 of contains some basic info about CBOR.

Problem Description The (potentially constrained) device (U) wants to enroll into a domain over a constrained link. The device authenticates and enforces authorization of the (non-constrained) domain authenticator (V) with the help of a voucher, and makes the enrollment request. The domain authenticator, in turn, authenticates the device and authorizes its enrollment. Authentication between device and domain authenticator is made with the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC . The procedure is assisted by a (non-constrained) authorization server (W) located in a non-constrained network behind the domain authenticator providing information to the device and to the domain authenticator as part of the protocol. The objective of this document is to specify such a protocol which is lightweight over the constrained link by reusing elements of EDHOC. See illustration in .

Overview of message flow. EDHOC is used on the constrained link between U and V. Voucher_Info and Voucher are sent in EDHOC External Authorization Data. The link between V and W is not constrained. | Domain +---------->| Authorization | | |<---o-------+ Authenticator |<----------+ Server | | (U) +----+------>| (V) | Voucher | (W) | | | | | | Response | | +----------+ | +---------------+ +---------------+ Voucher ]]>

Assumptions

Device (U) U takes the role as EDHOC Initiator with authentication credential CRED_I. CRED_I may for example be an X.509 certificate or a CBOR Web Token (CWT, ). For identification to W, U is provisioned with an identifier ID_U, from which W shall be able to retrieve CRED_I. ID_U is for example a reference to the device authentication credential, or an identifier from a separate name space. U is also provisioned with information about W:

• A static public DH key of W (G_W) used to protect communication between device and authorization server (see ).
• Location information about the authorization server (LOC_W) that can be used by V. This is typically a URI but may be optimized, e.g., only the domain name.

Domain Authenticator (V) V takes the role as EDHOC Responder with authentication credential CRED_R. CRED_R is a CWT Claims Set (CCS, ) containing the public authentication key of V, PK_V, see V needs to establish secure communication with W based on information in LOC_W. The communication between V and W is assumed to be mutually authenticated and protected; authentication credentials and communication security is out of scope, except for as specified below in this section. V may in principle use different credentials for authenticating to U and to W (CRED_R is used for the former). However, V MUST prove possession of private key of PK_V to W, since W is asserting (by means of a voucher sent to U) that this credential belongs to V. In this version of the draft is assumed that V authenticates to W with the public key PK_V using some authentication protocol providing proof of possession of the private key, for example TLS 1.3 . A future version of this draft may specify explicit proof of possession of the private key of PK_V in VREQ, e.g., by including a signature of the contents of the voucher request made with the private key corresponding to PK_V.

Authorization Server (W) W has the private DH key corresponding to G_W, which is used to secure the communication with U (see ). Authentication credentials and communication security used with V is out of scope, except for the need to verify the possession of the private key of PK_V as specified in . W provides to U the authorization decision for enrollment with V in the form of a voucher, see . W may provide V with the authorization credential of U, CRED_I, after V has learnt the identity of U. W needs to be available during the execution of the protocol between U and V.

The Protocol

Overview Three security sessions are going on in parallel:

1. EDHOC between device (U) and (domain) authenticator (V)
2. Voucher Request/Response between authenticator (V) and authorization server (W)
3. An exchange of voucher-related information, including the voucher itself, between device (U) and authorization server (W), mediated by the authenticator (V).

provides an overview of the message flow detailed in this section, for more details see Section 3.1 of .

W-assisted authorization of U and V to each other: EDHOC between U and V (only selected message fields shown for simplicity), and Voucher Request/Response between V and W. | | | EDHOC message_1 | H(m1), SS, G_X, ENC_ID, ?PoP_V | | +--------------------------------->| | | Voucher Request (VREQ) | | | | | | H(m1), Voucher | | |<---------------------------------+ | | Voucher Response (VRES) | | Enc(ID_CRED_R, SM_2, EAD_2) | | |<------------------------------+ | | EDHOC message_2 | | | | | | Enc(ID_CRED_I, SM_3) | | +------------------------------>| | | EDHOC message_3 | (Credential lookup:) | | | ID_CRED_I | | |--------------------------------->| | |<---------------------------------| | | CRED_I | | | | where H(m1) = H(message_1) EAD_1 contains Voucher_Info: LOC_W, ENC_ID EAD_2 contains Voucher: MAC(H(message_1), CRED_R) ]]>

Reuse of EDHOC The protocol illustrated in reuses several components of EDHOC:

• G_X, the 'x' parameter of the ephemeral public Diffie-Hellman key of party U, is also used in the protocol between U and W.
• SUITES_I, the cipher suites relevant to U, which includes the selected cipher suite - here denoted SS, also defines the algorithms used between U and W. In particular SS contains information about (see Section 3.6 of ):
  • EDHOC AEAD algorithm: used to encrypt the identity of U
  • EDHOC hash algorithm: used for key derivation and to calculate the voucher
  • EDHOC MAC length in bytes: length of the voucher
  • EDHOC key exchange algorithm: used to calculate the shared secret between U and W
• EAD_1, EAD_2 are the External Authorization Data message fields of message_1 and message_2, respectively, see Section 3.8 of . This document specifies EAD items with ead_label = TBD1, see ).
• ID_CRED_I and ID_CRED_R are used to identify the authentication credentials of U and V. As shown at the bottom of , V may use W to obtain CRED_I, the authentication credential of U. The authentication credential of V, CRED_R, is transported in ID_CRED_R in message_2, see .
• Signature_or_MAC_2 and Signature_or_MAC_3 (abbreviated SM_2 and SM_3 in ), containing data generated using the private key of V and U, respectively, are shown here just to be able to reason about the use of credentials. The definition of these fields depend on EDHOC method, see Section 5 of ).

The protocol also reuses the Extract and Expand key derivation from EDHOC (Section 4 of ).

• The intermediate pseudo-random key PRK is derived using Extract():
  • PRK = Extract(salt, IKM)
    • where salt = 0x (the zero-length byte string)
    • IKM is the ECDH shared secret G_XW (calculated from G_X and W or G_W and X) as defined in Section 6.3.1 of .

The shared secret is derived using Expand() which is defined in terms of the EDHOC hash algorithm of the selected cipher suite, see Section 4.2. of :

• shared secret = Expand(PRK, info, length) where

Device <-> Authorization Server (U <-> W) The protocol between U and W is carried out via V with certain data protected between the endpoints using the equivalent of a hybrid public key encryption scheme such as . U uses the public DH key of the W, G_W, together with the private DH key corresponding to ephemeral key G_X in EDHOC message_1, and vice versa for W. The endpoints calculate a shared secret G_XW (see ), which is used to derive secret keys to protect data between U and W, as detailed in this section. The data exchanged between U and W is carried between U and V in message_1 and message_2 (), and between V and W in the Voucher Request/Response ().

Voucher Info The external authorization data EAD_1 contains an EAD item with ead_label = TBD1 and ead_value = Voucher_Info, which is a CBOR byte string: where

• LOC_W is location information of W, used by V
• ENC_ID is the encrypted blob carrying an identifier of U passed on from V to W, calculated as follows:

ENC_ID is 'ciphertext' of COSE_Encrypt0 (Section 5.2-5.3 of ) computed from the following:

• The encryption key K_1 and nonce IV_1 are derived as specified below.
• 'protected' is a byte string of size 0
• 'plaintext and 'external_aad' as below:

where

• ID_U is an identity of the device, for example a reference to the device authentication credential, see .
• SS is the selected cipher suite in SUITES_I.

The derivation of K_1 = Expand(PRK, info, length) uses the following input to the info struct ():

• label = TBD1
• context = h''
• length is length of key of the EDHOC AEAD algorithm in bytes

The derivation of IV_1 = Expand(PRK, info, length) uses the following input to the info struct ():

• label = TBD1
• context = h'00'
• length is length of nonce of the EDHOC AEAD algorithm in bytes

Voucher The voucher is an assertion for U that W has performed the relevant verifications and that U is authorized to continue the protocol with V. The voucher is essentially a message authentication code which binds the authentication credential of V to message_1 of EDHOC, integrity protected with the shared secret context between U and W. The external authorization data EAD_2 contains an EAD item with ead_label = TBD1 and ead_value = Voucher, which is a CBOR byte string: calculated with the following input to the info struct ():

• label is TBD1
• context = bstr .cbor voucher_input
• length is EDHOC MAC length in bytes

where context is a CBOR bstr wrapping of the following CBOR sequence: where

• H(message_1) is copied from the associated voucher request.
• CRED_R is a CWT Claims Set (CCS, ) containing the public authentication key of V, PK_V, see

Device <-> Authenticator (U <-> V) This section describes the processing in U and V, which execute the EDHOC protocol using their respective authentication credentials, see . Normal EDHOC processing is omitted here.

Message 1

Processing in U U composes EDHOC message_1 using authentication method, identifiers, etc. according to an agreed application profile, see Section 3.9 of . The selected cipher suite, in this document denoted SS, applies also to the interaction with W as detailed in , in particular, to the key agreement algorithm which is used with the static public DH key G_W of W. As part of the normal EDHOC processing, U generates the ephemeral public key G_X which is reused in the interaction with W, see . The device sends EDHOC message_1 with EAD item (-TBD1, Voucher_Info) included in EAD_1, where Voucher_Info is specified in . The negative sign indicates that the EAD item is critical, see Section 3.8 in .

Processing in V V receives EDHOC message_1 from U and processes it as specified in Section 5.2.3 of , with the additional step of processing the EAD item in EAD_1. Since the EAD item is critical, if V does not recognize it or it contains information that V cannot process, then V MUST discontinue EDHOC, see Section 3.8 in . Otherwise, the ead_label = TBD1, triggers the voucher request to W as described in . The exchange between V and W needs to be completed successfully for the EDHOC exchange to be continued.

Message 2

Processing in V V receives the voucher response from W as described in . V sends EDHOC message_2 to U with the critical EAD item (-TBD1, Voucher) included in EAD_2, where the Voucher is specified in . CRED_R is a CWT Claims Set (CCS, ) containing the public authentication key of the authenticator PK_V encoded as a COSE_Key in the 'cnf' claim, see Section 3.5.2 of . ID_CRED_R contains the CCS with 'kccs' as COSE header_map, see Section 9.6 of . The Signature_or_MAC_2 field calculated using the private key corresponding to PK_V is either a signature or a MAC depending on EDHOC method.

Processing in U U receives EDHOC message_2 from V and processes it as specified in Section 5.3.2 of , with the additional step of processing the EAD item in EAD_2. If U does not recognize the EAD item or the EAD item contains information that U cannot process, then U MUST discontinue EDHOC, see Section 3.8 in . Otherwise U MUST verify the Voucher by performing the same calculation as in using H(message_1) and CRED_R received in ID_CRED_R of message_2. If the voucher calculated in this way is not identical to what was received in message_2, then U MUST discontinue the protocol.

Message 3

Processing in U If all verifications are passed, then U sends EDHOC message_3. The Signature_or_MAC_3 field calculated using the private key corresponding to PK_U is either a signature or a MAC depending on EDHOC method. EAD_3 MAY contain a certificate enrollment request, see e.g., CSR specified in , or other request which the device is now authorized to make. EDHOC message_3 may be combined with an OSCORE request, see .

Processing in V V performs the normal EDHOC verifications of message_3. V may retrieve CRED_I from W, after V learnt ID_CRED_I from U.

Authenticator <-> Authorization Server (V <-> W) V and W are assumed to be able to authenticate and set up a secure connection, out of scope for this specification, for example TLS 1.3 authenticated with certificates. V is assumed to authenticate with the public key PK_V, see . This secure connection protects the Voucher Request/Response Protocol (see protocol between V and W in ). The hash of EDHOC message_1, H(message_1), acts as session identifier of the Voucher Request/Response protocol, and binds together instances of the two protocols (U<->V and V<->W).

Voucher Request

Processing in V Unless already in place, V and W establish a secure connection. V uses H(message_1) as a session identifier associated to this connection with W. If the same value of H(message_1) is already used for a connection with this or other W, the protocol SHALL be discontinued. V sends the voucher request to W. The Voucher Request SHALL be a CBOR array as defined below: where the parameters are defined in , except:

• PoP_V is a proof-of-possession of public key PK_V using the corresponding private key. PoP_V is optional.

Editor's note: Define PoP_V (include G_X, ENC_ID in the calculation for binding to this EDHOC session). One case to study is when V authenticates to U with static DH and to W with signature.

Processing in W W receives the voucher request, verifies and decrypts ENC_ID, and associates the session identifier H(message_1) to ID_U. If H(message_1) is not unique among session identifiers associated to this identity, the protocol SHALL be discontinued. W uses the identity of the device, ID_U, to look up and verify the associated authorization policies for U. This is out of scope for the specification.

Voucher Response

Processing in W W retrieves the public key of V, PK_V, used to authenticate the secure connection with V, and constructs the CCS (see ) and the Voucher (see ). Editor's note: Make sure the CCS is defined to allow W to generate it uniquely from PK_V. W generates the voucher response and sends it to V over the secure connection. The Voucher_Response SHALL be a CBOR array as defined below: where

• H(message_1) is copied from the associated voucher request.
• The Voucher is defined in .

Processing in V V receives the voucher response from W over the secure connection. If the received session identifier does not match the session identifier H(message_1) associated to the secure connection, the protocol SHALL be discontinued.

REST Interface at W The interaction between V and W is enabled through a RESTful interface exposed by W. V SHOULD access the resources exposed by W through the protocol indicated by the scheme in LOC_W URI. In case the scheme indicates "https", V SHOULD perform a TLS handshake with W and use HTTP. In case the scheme indicates "coaps", V SHOULD perform a DTLS handshake with W and access the same resources using CoAP. In both cases, V MUST perform client authentication to authenticate to W, using a certificate containing the PK_V public key.

HTTP URIs W MUST support the use of the path-prefix "/.well-known/", as defined in , and the registered name "lake-authz". A valid URI thus begins with "https://www.example.com/.well-known/lake-authz". Each operation specified in the following is indicated by a path-suffix.

Voucher Request (/voucherrequest) To request a voucher, V MUST issue an HTTP request:

• Method is POST
• Payload is the serialization of the Voucher Request object, as specified in .

In case of successful processing at W, W MUST issue a 200 OK response with payload containing the serialized Voucher Response object, as specified in .

Certificate Request (/certrequest) V requests the public key certificate of U from W through the "/certrequest" path-suffix. To request U's authentication credential, V MUST issue an HTTP request:

• Method is POST
• Payload is the serialization of the ID_CRED_I object, as received in EDHOC message_3.

In case of a successful lookup of the authentication credential at W, W MUST issue 200 OK response with payload containing the serialized CRED_I.

Security Considerations This specification builds on and reuses many of the security constructions of EDHOC, e.g., shared secret calculation and key derivation. The security considerations of EDHOC apply with modifications discussed here. EDHOC provides identity protection of the Initiator, here the device. The encryption of the device identity in the first message should consider potential information leaking from the length of the identifier ID_U, either by making all identifiers having the same length or the use of a padding scheme. Although W learns about the identity of U after receiving VREQ, this information must not be disclosed to V, until U has revealed its identity to V with ID_CRED_I in message_3. W may be used for lookup of CRED_I from ID_CRED_I, or this credential lookup function may be separate from the authorization function of W. The trust model used here is that U decides to which V it reveals its identity. In an alternative trust model where U trusts W to decide to which V it reveal's U's identity, CRED_I could be sent in Voucher Response. As noted Section 8.2 of an ephemeral key may be used to calculate several ECDH shared secrets. In this specification the ephemeral key G_X is also used to calculate G_XW, the shared secret with the authorization server. The private ephemeral key is thus used in the device for calculations of key material relating to both the authenticator and the authorization server. There are different options for where to implement these calculations, one option is as an addition to EDHOC, i.e., to extend the EDHOC API in the device with input of public key of W (G_W) and identifier of U (ID_U), and produce the encryption of ID_U which is included in Voucher_Info in EAD_1.

IANA Considerations

EDHOC External Authorization Data Registry IANA has registered the following entry in the "EDHOC External Authorization Data" registry under the group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)". The ead_label = TBD_1 corresponds to the ead_value Voucher_Info in EAD_1, and Voucher in EAD_2 with processing specified in and , respectively, of this document. Addition to the EDHOC EAD registry

Label	Value Type	Description
TBD1	bstr	Voucher related information

The Well-Known URI Registry IANA has registered the following entry in "The Well-Known URI Registry", using the template from :

• URI suffix: lake-authz
• Change controller: IETF
• Specification document: [[this document]]
• Related information: None

Well-Known Name Under ".arpa" Name Space This document allocates a well-known name under the .arpa name space according to the rules given in and . The name "lake-authz.arpa" is requested. No subdomains are expected, and addition of any such subdomains requires the publication of an IETF Standards Track RFC. No A, AAAA, or PTR record is requested.

References Normative References 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. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. Ericsson AB Ericsson AB Ericsson AB 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 OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low. Informative References 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. This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. 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. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Ericsson RISE AB RISE AB Fraunhofer AISEC Ericsson The lightweight authenticated key exchange protocol EDHOC can be run over CoAP and used by two peers to establish an OSCORE Security Context. This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group 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 all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. Inria Ericsson AB Ericsson AB Odin Solutions S.L. This document compiles the requirements for a lightweight authenticated key exchange protocol for OSCORE. This draft has completed a working group last call (WGLC) in the LAKE working group. Post-WGLC, the requirements are considered sufficiently stable for the working group to proceed with its work. It is not currently planned to publish this draft as an RFC. n.d.

Use with Constrained Join Protocol (CoJP) This section outlines how the protocol is used for network enrollment and parameter provisioning. An IEEE 802.15.4 network is used as an example of how a new device (U) can be enrolled into the domain managed by the domain authenticator (V).

Use of draft-selander-lake-authz with CoJP. | | | Optional network solicitation | | |<-----------------------------------+ | | Network discovery | | | | | +----------------------------------->| | | EDHOC message_1 | | | +----------------------------->| | | Voucher Request (VREQ) | | |<-----------------------------+ | | Voucher Response (VRES) | |<-----------------------------------+ | | EDHOC message_2 | | | | | | | | +----------------------------------->| | | EDHOC message_3 + CoJP request | | | | | +<-----------------------------------| | | CoJP response | | | ]]>

Network Discovery When a device first boots, it needs to discover the network it attempts to join. The network discovery procedure is defined by the link-layer technology in use. In case of Time-slotted Channel Hopping (TSCH) networks, a mode of , the device scans the radio channels for Enhanced Beacon (EB) frames, a procedure known as passive scan. EBs carry the information about the network, and particularly the network identifier. Based on the EB, the network identifier, the information pre-configured into the device, the device makes the decision on whether it should join the network advertised by the received EB frame. This process is described in Section 4.1. of . In case of other, non-TSCH modes of IEEE 802.15.4 it is possible to use the active scan procedure and send solicitation frames. These solicitation frames trigger the nearest network coordinator to respond by emitting a beacon frame. The network coordinator emitting beacons may be multiple link-layer hops away from the domain authenticator (V), in which case it plays the role of a Join Proxy (see ). Join Proxy does not participate in the protocol and acts as a transparent router between the device and the domain authenticator. For simplicity, illustrates the case when the device and the domain authenticator are a single hop away and can communicate directly.

The Enrollment Protocol with Parameter Provisioning

Flight 1 Once the device has discovered the network it wants to join, it constructs the EDHOC message_1, as described in . The device SHALL map the message to a CoAP request:

• The request method is POST.
• The type is Confirmable (CON).
• The Proxy-Scheme option is set to "coap".
• The Uri-Host option is set to "lake-authz.arpa". This is an anycast type of identifier of the domain authenticator (V) that is resolved to its IPv6 address by the Join Proxy.
• The Uri-Path option is set to ".well-known/edhoc".
• The Content-Format option is set to "application/cid-edhoc+cbor-seq"
• The payload is the (true, EDHOC message_1) CBOR sequence, where EDHOC message_1 is constructed as defined in .

Flight 2 The domain authenticator receives message_1 and processes it as described in . The message triggers the exchange with the authorization server, as described in . If the exchange between V and W completes successfully, the domain authenticator prepares EDHOC message_2, as described in . The authenticator SHALL map the message to a CoAP response:

• The response code is 2.04 Changed.
• The Content-Format option is set to "application/edhoc+cbor-seq"
• The payload is the EDHOC message_2, as defined in .

Flight 3 The device receives EDHOC message_2 and processes it as described in }. Upon successful processing of message_2, the device prepares flight 3, which is an OSCORE-protected CoJP request containing an EDHOC message_3, as described in . EDHOC message_3 is prepared as described in . The OSCORE-protected payload is the CoJP Join Request object specified in Section 8.4.1. of . OSCORE protection leverages the OSCORE Security Context derived from the EDHOC exchange, as specified in Appendix A of . To that end, specifies that the Sender ID of the client (device) must be set to the connection identifier selected by the domain authenticator, C_R. OSCORE includes the Sender ID as the kid in the OSCORE option. The network identifier in the CoJP Join Request object is set to the network identifier obtained from the network discovery phase. In case of IEEE 802.15.4 networks, this is the PAN ID. The device SHALL map the message to a CoAP request:

• The request method is POST.
• The type is Confirmable (CON).
• The Proxy-Scheme option is set to "coap".
• The Uri-Host option is set to "lake-authz.arpa".
• The Uri-Path option is set to ".well-known/edhoc".
• The EDHOC option is set and is empty.
• The payload is prepared as described in Section 3.2. of , with EDHOC message_3 and the CoJP Join Request object as the OSCORE-protected payload.

Note that the OSCORE Sender IDs are derived from the connection identifiers of the EDHOC exchange. This is in contrast with where ID Context of the OSCORE Security Context is set to the device identifier (pledge identifier). Since the device identity is exchanged during the EDHOC handshake, and the certificate of the device is communicated to the authenticator as part of the Voucher Response message, there is no need to transport the device identity in OSCORE messages. The authenticator playing the role of the JRC obtains the device identity from the execution of the authorization protocol.

Flight 4 Flight 4 is the OSCORE response carrying CoJP response message. The message is processed as specified in Section 8.4.2. of .