| Internet-Draft | Lightweight Authorization using EDHOC | July 2023 |
| Selander, et al. | Expires 25 January 2024 | [Page] |
This document describes a procedure for authorizing enrollment of new devices using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). The procedure is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://ericssonresearch.github.io/ace-ake-authz/draft-selander-lake-authz.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-selander-lake-authz/.¶
Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (mailto:lake@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lake/. Subscribe at https://www.ietf.org/mailman/listinfo/lake/.¶
Source for this draft and an issue tracker can be found at https://github.com/EricssonResearch/ace-ake-authz.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 January 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
For constrained IoT deployments [RFC7228] 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 [I-D.ietf-lake-reqs]). This document describes a procedure for augmenting the lightweight authenticated Diffie-Hellman key exchange EDHOC [I-D.ietf-lake-edhoc] with third party-assisted authorization.¶
The procedure involves a device, a domain authenticator, and an enrollment server. The device and domain authenticator perform mutual authentication and authorization, assisted by the enrollment server which provides relevant authorization information to the device (a "voucher") and to the authenticator. The high-level model is similiar to BRSKI [RFC8995].¶
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., [RFC9031]), but it can be applied to authorize other target interactions.¶
The enrollment server may represent the manufacturer of the device, or some other party with information about the device from which a trust anchor has been pre-provisioned into the device. The (domain) authenticator may represent the service provider or some other party controlling access to the network in which the device is enrolling.¶
The protocol assumes that authentication between device and authenticator is performed with EDHOC [I-D.ietf-lake-edhoc], and defines the integration of a lightweight authorization procedure using the External Authorization Data (EAD) fields defined in EDHOC.¶
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Readers are expected to have an understanding of CBOR [RFC8949] and EDHOC [I-D.ietf-lake-edhoc]. Appendix C.1 of [I-D.ietf-lake-edhoc] contains some basic info about CBOR.¶
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 conveying authorization information. The voucher has a similar role as in [RFC8366] but should be considerably more compact. The domain authenticator, in turn, authenticates the device and authorizes its enrollment into the domain.¶
The procedure is assisted by a (non-constrained) enrollment server (W) located in a non-constrained network behind the domain authenticator, e.g. on the Internet, providing information to the device (the voucher) 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 [I-D.ietf-lake-edhoc] and by shifting message overhead to the non-constrained side of the network. See illustration in Figure 1.¶
Note the cardinality of the involved parties. It is expected that the authenticator needs to handle a large unspecified number of devices, but for a given device type or manufacturer it is expected that one or a few nodes host enrollment servers.¶
The protocol is based on the following pre-existing relations between the device (U), the domain authenticator (V) and the enrollment server (W), see Figure 2.¶
Each of the three parties have protected communication with the other two during the protocol.¶
To authenticate to V, the device (U) runs EDHOC in the role of Initiator with authentication credential CRED_U, for example, an X.509 certificate or a CBOR Web Token (CWT, [RFC8392]). CRED_U may, for example, be carried in ID_CRED_I of EDHOC message_3 or be provisioned to V over a non-constrained network, see bottom of Figure 3.¶
U also needs to identify itself to W, this device identifier is denoted by ID_U. The purpose of ID_U is for W to be able to determine if the device with this identifier is authorized to enroll with V. ID_U may be a reference to CRED_U, like ID_CRED_I in EDHOC (see Section 3.5.2 of [I-D.ietf-lake-edhoc]), or a device identifier from a different name space, such as EUI-64 identifiers.¶
U is also provisioned with information about W:¶
To authenticate to U, the domain authenticator (V) runs EDHOC in the role of Responder with an authentication credential CRED_V, which is a CWT Claims Set [RFC8392] containing a public key of V, see Section 4.5.2.1. This proves to U the possession of the private key corresponding to the public key of CRED_V. CRED_V typically needs to be transported to U in EDHOC (using ID_CRED_R = CRED_V, see Section 3.5.2 of [I-D.ietf-lake-edhoc]) since there is no previous relation between U and V.¶
V and W need to establish a secure (confidentiality and integrity protected) connection for the Voucher Request/Response protocol. Furthermore, W needs access the same credential CRED_V as V used with U, and V needs to prove to W the possession of the private key corresponding to the public key of CRED_V. It is RECOMMENDED that V authenticates to W using the same credential CRED_V as with U.¶
Note that both TLS 1.3 and EDHOC may be run between V and W during this setup procedure. For example, W may authenticate to V using TLS 1.3 with server certificates signed by a CA trusted by V, and then V may run EDHOC using CRED_V over the secure TLS connection to W, see Figure 3.¶
Note also that the secure connection between V and W may be long lived and reused for multiple voucher requests/responses.¶
Other details of proof-of-possession related to CRED_V and transport of CRED_V are out of scope of this document.¶
The enrollment server (W) is assumed to have the private DH key corresponding to G_W, which is used to establish secure communication with the device (see Section 4.4). W provides to U the authorization decision for enrollment with V in the form of a voucher (see Section 4.4.2). Authorization policies are out of scope for this document.¶
Authentication credentials and communication security with V is described in Section 3.2. To calculate the voucher, W needs access to message_1 and CRED_V as used in the EDHOC session between U and V, see Section 4.4.2.¶
W needs to be available during the execution of the protocol between U and V.¶
The protocol consist of three security sessions going on in parallel:¶
Figure 3 provides an overview of the message flow detailed in this section. An outline of EDHOC is given in Section 3 of [I-D.ietf-lake-edhoc].¶
The protocol illustrated in Figure 3 reuses several components of EDHOC:¶
SUITES_I includes the cipher suite for EDHOC selected by U, and also defines the algorithms used between U and W (see Section 3.6 of [I-D.ietf-lake-edhoc]):¶
The protocol also reuses the EDHOC-Extract and EDHOC-Expand key derivation from EDHOC (see Section 4 of [I-D.ietf-lake-edhoc]).¶
The intermediate pseudo-random key PRK is derived using EDHOC-Extract():¶
PRK = EDHOC-Extract(salt, IKM)¶
The output keying material OKM is derived from PRK using EDHOC-Expand(), which is defined in terms of the EDHOC hash algorithm of the selected cipher suite, see Section 4.2 of [I-D.ietf-lake-edhoc]:¶
info = ( info_label : int, context : bstr, length : uint, )¶
V may act statelessly with respect to U: the state of the EDHOC session started by U may be dropped at V until authorization from W is received. Once V has received EDHOC message_1 from U and extracted LOC_W from EAD_1, message_1 is forwarded unmodified to W in the form of a Voucher Request. V encapsulates the internal state that it needs to later respond to U, and sends that to W together with EDHOC message_1. This state typically contains U's IP address and port number, together with any other implementation-specific parameter needed by V to respond to U. At this point, V can drop the EDHOC session that was initiated by U.¶
V MUST encrypt and integrity protect the encapsulated state using a uniformly-distributed (pseudo-)random key, known only to itself. How V serializes and encrypts its internal state is out of scope of this specification. For example, V may use the existing CBOR and COSE libraries.¶
Editor's note: Consider to include an example of serialized internal state.¶
W sends to V the voucher together with echoed message_1, as received from U, and V's internal state. This allows V to act as a simple message relay until it has obtained the authorization from W to enroll U. The reception of a successful Voucher Response at V from W implies the authorization for V to enroll U. At this point, V can initialize a new EDHOC session with U, based on the message and the state retrieved from the Voucher Response from W.¶
The protocol between U and W is carried between U and V in message_1 and message_2 (Section 4.5), and between V and W in the Voucher Request/Response (Section 4.6). The data is protected between the endpoints using secret keys derived from a Diffie-Hellman shared secret (see Section 4.2) as further detailed in this section.¶
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:¶
Voucher_Info = bstr .cbor Voucher_Info_Seq¶
Voucher_Info_Seq = (
LOC_W: tstr,
ENC_ID: bstr
)
¶
where¶
ENC_ID is 'ciphertext' of COSE_Encrypt0 (Section 5.2 of [RFC9052]) computed from the following:¶
plaintext = (
ID_U: bstr,
)
¶
external_aad = (
SS: int,
)
¶
where¶
Editor's note: Add more context to external_aad.¶
The derivation of K_1 = EDHOC-Expand(PRK, info, length) uses the following input to the info struct (see Section 4.2):¶
The derivation of IV_1 = EDHOC-Expand(PRK, info, length) uses the following input to the info struct (see Section 4.2):¶
The voucher is an assertion to U that W has authorized V. The voucher is essentially a message authentication code which binds the authentication credential of V, CRED_V, to message_1 of EDHOC.¶
The external authorization data EAD_2 contains an EAD item with ead_label = TBD1 and ead_value = Voucher, which is a CBOR byte string:¶
Voucher = bstr .cbor EDHOC-Expand(PRK, info, length)¶
The voucher is calculated with the following input to the info struct (see Section 4.2):¶
where context is a CBOR byte string wrapping of the following CBOR sequence:¶
voucher_input = (
H(message_1): bstr,
CRED_V: bstr,
)
¶
where¶
This section describes the processing in U and V, which include the EDHOC protocol, see Figure 3. Normal EDHOC processing is omitted here.¶
U composes EDHOC message_1 using authentication method, identifiers, etc. according to an agreed application profile, see Section 3.9 of [I-D.ietf-lake-edhoc]. The selected cipher suite, in this document denoted SS, applies also to the interaction with W as detailed in Section 4.2, in particular, with respect to the Diffie Hellman key agreement algorithm used between U and 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 Section 4.4.¶
The device sends EDHOC message_1 with EAD item (-TBD1, Voucher_Info) included in EAD_1, where Voucher_Info is specified in Section 4.4. The negative sign indicates that the EAD item is critical, see Section 3.8 of [I-D.ietf-lake-edhoc].¶
V receives EDHOC message_1 from U and processes it as specified in Section 5.2.3 of [I-D.ietf-lake-edhoc], 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 abort the EDHOC session, see Section 3.8 of [I-D.ietf-lake-edhoc]. Otherwise, the ead_label = TBD1, triggers the voucher request to W as described in Section 4.6. The exchange between V and W needs to be completed successfully for the EDHOC session to be continued.¶
V receives the voucher response from W as described in Section 4.6.¶
V sends EDHOC message_2 to U with the critical EAD item (-TBD1, Voucher) included in EAD_2, where the Voucher is specified in Section 4.4.¶
CRED_V is a CWT Claims Set [RFC8392] containing the public authentication key of V encoded as a COSE_Key in the 'cnf' claim, see Section 3.5.2 of [I-D.ietf-lake-edhoc].¶
ID_CRED_R contains the CWT Claims Set with 'kccs' as COSE header_map, see Section 9.6 of [I-D.ietf-lake-edhoc].¶
U receives EDHOC message_2 from V and processes it as specified in Section 5.3.2 of [I-D.ietf-lake-edhoc], 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 abort the EDHOC session, see Section 3.8 of [I-D.ietf-lake-edhoc]. Otherwise U MUST verify the Voucher by performing the same calculation as in Section 4.4.2 using H(message_1) and CRED_V 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 abort the EDHOC session.¶
If all verifications are passed, then U sends EDHOC message_3.¶
EDHOC message_3 may be combined with an OSCORE request, see [I-D.ietf-core-oscore-edhoc].¶
V performs the normal EDHOC verifications of message_3. V may retrieve CRED_U from a Credential Database, after having learnt ID_CRED_I from U.¶
It is assumed that V and W have set up a secure connection, W has accessed the authentication credential CRED_V to be used in the EDHOC session between V and with U, and that W has verified that V is in possession of the private key corresponding to CRED_V, see Section 3.2 and Section 3.3. V and W run the Voucher Request/Response protocol over the secure connection.¶
V sends the voucher request to W. The Voucher Request SHALL be a CBOR array as defined below:¶
Voucher_Request = [
message_1: bstr,
? opaque_state: bstr
]
¶
where¶
W receives and parses the voucher request received over the secure connection with V. The voucher request essentially contains EDHOC message_1 as sent by U to V. W SHALL NOT process message_1 as if it was an EDHOC message intended for W.¶
W extracts from message_1:¶
W verifies and decrypts ENC_ID using the relevant algorithms of the selected cipher suite SS (see Section 4.2), and obtains ID_U.¶
W calculates the hash of message_1 H(message_1), and associates this session identifier to the device identifier ID_U. If H(message_1) is not unique among session identifiers associated to this device identifier of U, the EDHOC session SHALL be aborted.¶
W uses ID_U to look up the associated authorization policies for U and enforces them. This is out of scope for the specification.¶
W retrieves CRED_V associated to the secure connection with V, and constructs the the Voucher for the device with identifier ID_U (see Section 4.4.2).¶
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:¶
Voucher_Response = [
message_1: bstr,
Voucher: bstr,
? opaque_state: bstr
]
¶
where¶
V receives the voucher response from W over the secure connection. If present, V decrypts and verifies opaque_state as received from W. If that verification fails then EDHOC is aborted. If the voucher response is successfully received from W, then V responds to U with EDHOC message_2 as described in Section 4.5.2.1.¶
The interaction between V and W is enabled through a RESTful interface exposed by W. This RESTful interface MAY be implemented using either HTTP or CoAP. 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 MUST perform a TLS handshake with W and use HTTP. If the authentication credential CRED_V can be used in a TLS handshake, e.g. an X.509 certificate of a signature public key, then V SHOULD use it to authenticate to W as a client. If the authentication credential CRED_V cannot be used in a TLS handshake, e.g. if the public key is a static Diffie-Hellman key, then V SHOULD first perform a TLS handshake with W using available compatible keys. V MUST then perform an EDHOC session over the TLS connection proving to W the possession of the private key corresponding to CRED_V. Performing the EDHOC session is only necessary if V did not authenticate with CRED_V in the TLS handshake with W.¶
Editor's note: Clarify that performing TLS handshake is not necessary for each device request; if there already is a TLS connection between V and W that should be reused. Similar considerations for 5.2 and 5.3.¶
In case the scheme indicates "coaps", V SHOULD perform a DTLS handshake with W and access the resources defined in Section 5.4 using CoAP. The normative requirements in Section 5.1 on performing the DTLS handshake and EDHOC session remain the same, except that TLS is replaced with DTLS.¶
In case the scheme indicates "coap", V SHOULD perform an EDHOC session with W, as specified in Appendix A of [I-D.ietf-lake-edhoc] and access the resources defined in Section 5.4 using OSCORE and CoAP. The authentication credential in this EDHOC session MUST be CRED_V.¶
The URIs defined below are valid for both HTTP and CoAP. W MUST support the use of the path-prefix "/.well-known/", as defined in [RFC8615], and the registered name "lake-authz". A valid URI in case of HTTP thus begins with¶
In case of CoAP with DTLS:¶
In case of EDHOC and OSCORE:¶
Each operation specified in the following is indicated by a path-suffix.¶
To request a voucher, V MUST issue a request:¶
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 Section 4.6.2.¶
V requests the public key certificate of U from W through the "/certrequest" path-suffix. To request U's authentication credential, V MUST issue a request:¶
In case of a successful lookup of the authentication credential at W, W MUST issue 200 OK response with payload containing the serialized CRED_U.¶
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 [I-D.ietf-lake-edhoc] apply with modifications discussed here.¶
EDHOC provides identity protection of the Initiator, here the device. The encryption of the device identifier ID_U in the first message should consider potential information leaking from the length of 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_U from ID_CRED_I, or this credential lookup function may be separate from the authorization function of W, see Figure 3. 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 reveals U's identity, CRED_U could be sent in Voucher Response.¶
As noted in Section 8.2 of [I-D.ietf-lake-edhoc] 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 enrollment server.¶
The private ephemeral key is thus used in the device for calculations of key material relating to both the authenticator and the enrollment 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 device identifier of U (ID_U), and produce the encryption of ID_U which is included in Voucher_Info in EAD_1.¶
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 Section 4.5.1 and Section 4.5.2, respectively, of this document.¶
| Label | Value Type | Description |
|---|---|---|
| TBD1 | bstr | Voucher related information |
IANA has registered the following entry in "The Well-Known URI Registry", using the template from [RFC8615]:¶
This document allocates a well-known name under the .arpa name space according to the rules given in [RFC3172] and [RFC6761]. 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.¶
IANA has added the media types "application/lake-authz-voucherrequest+cbor" to the "Media Types" registry.¶
Additional information:¶
IANA has added the media type "application/lake-authz-voucherrequest+cbor" to the "CoAP Content-Formats" registry under the registry group "Constrained RESTful Environments (CoRE) Parameters".¶
| Media Type | Encoding | ID | Reference |
|---|---|---|---|
| application/lake-authz-voucherrequest+cbor | - | TBD2 | [[this document]] |
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).¶
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 [IEEE802.15.4], 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 [RFC9031]. 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 [RFC9031]). Join Proxy does not participate in the protocol and acts as a transparent router between the device and the domain authenticator. For simplicity, Figure 4 illustrates the case when the device and the domain authenticator are a single hop away and can communicate directly.¶
Once the device has discovered the network it wants to join, it constructs the EDHOC message_1, as described in Section 4.5. The device SHALL map the message to a CoAP request:¶
The domain authenticator receives message_1 and processes it as described in Section 4.5. The message triggers the exchange with the enrollment server, as described in Section 4.6. If the exchange between V and W completes successfully, the domain authenticator prepares EDHOC message_2, as described in Section 4.5. The authenticator SHALL map the message to a CoAP response:¶
The device receives EDHOC message_2 and processes it as described in Section 4.5}. 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 [I-D.ietf-core-oscore-edhoc]. EDHOC message_3 is prepared as described in Section 4.5. The OSCORE-protected payload is the CoJP Join Request object specified in Section 8.4.1 of [RFC9031]. OSCORE protection leverages the OSCORE Security Context derived from the EDHOC session, as specified in Appendix A of [I-D.ietf-lake-edhoc]. To that end, [I-D.ietf-core-oscore-edhoc] 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:¶
Note that the OSCORE Sender IDs are derived from the connection identifiers of the EDHOC session. This is in contrast with [RFC9031] 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 session, 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 [RFC9031] JRC obtains the device identity from the execution of the authorization protocol.¶
Flight 4 is the OSCORE response carrying CoJP response message. The message is processed as specified in Section 8.4.2 of [RFC9031].¶