| Internet-Draft | Lightweight Authorization for AKE. | March 2020 |
| Selander, et al. | Expires 10 September 2020 | [Page] |
This document describes a procedure for augmenting an authenticated Diffie-Hellman key exchange with third party assisted authorization targeting constrained IoT deployments (RFC 7228).¶
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 10 September 2020.¶
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
For constrained IoT deployments [RFC7228] the overhead 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 lightweight procedure for augmenting an authenticated Diffie-Hellman key exchange 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 the authenticator.¶
The protocol specified in this document optimizes the 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 the authentication protocol leading to reduced message sizes on constrained links.¶
The specification assumes a lightweight AKE protocol [I-D.ietf-lake-reqs] between device and authenticator, and defines the integration of a lightweight authorization procedure. This enables a secure target interaction in few message exchanges. In this document we consider the target interaction to be "enrollment", for example certificate enrollment (such as [I-D.ietf-ace-coap-est]) or joining a network for the first time (e.g. [I-D.ietf-6tisch-minimal-security]), but it can be applied to authorize other target interactions.¶
This protocol is applicable to a wide variety of settings, and can be mapped to different authorization architectures. This document specifies a profile of the ACE framework [I-D.ietf-ace-oauth-authz]. Other settings such as EAP [RFC3748] are out of scope for this specification.¶
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.¶
The (potentially constrained) device wants to enroll into a domain over a constrained link. The device authenticates and enforces authorization of the (non-constrained) domain authenticator with the help of a voucher, and makes the enrollment request. The domain authenticator authenticates the device and authorizes its enrollment. Authentication between device and domain authenticator is made with a lightweight authenticated Diffie-Hellman key exchange protocol (LAKE, [I-D.ietf-lake-reqs]). The procedure is assisted by a (non-constrained) authorization server located in a non-constrained network behind the domain authenticator providing information to the device and to the domain authenticator.¶
The objective of this document is to specify such a protocol which is lightweight over the constrained link and reuses elements of the LAKE. See illustration in Figure 1.¶
Voucher
LAKE Info
+----------+ | | +---------------+ Voucher +---------------+
| | | | | | Request | |
| Device |--|----o-->| Domain |---------->| Authorization |
| |<-|---o----| Authenticator |<----------| Server |
| (U) |--|---|--->| (V) | Voucher | (W) |
| | | | | Response | |
+----------+ | +---------------+ +---------------+
Voucher
The device is pre-provisioned with an identity ID and asymmetric key credentials: a private key, a public key (PK_U), and optionally a public key certificate Cert(PK_U), issued by a trusted third party such as e.g. the device manufacturer, used to authenticate to the domain authenticator. The ID may be a reference or pointer to the certificate.¶
The device is also provisioned with information about its authorization server:¶
The domain authenticator has a private key and a corresponding public key PK_V used to authenticate to the device.¶
The domain authenticator needs to be able to locate the authorization server of the device for which the LOC_W is expected to be sufficient. The communication between domain authenticator and authorization server is mutually authenticated and protected. Authentication credentials and communication security used with the domain authenticator is out of scope, except for as specified below in this section.¶
The domain authenticator may in principle use differents credentials for authenticating to the authorization server and to the device, for which PK_V is used. However, the domain authenticator MUST prove possession of private key of PK_V to the authorization server since the authorization server is asserting (by means of the voucher to the device) that this credential belongs to the domain authenticator.¶
In this version of the draft it is assumed that the domain authenticator authenticates to the authorization server with PK_V using some authentication protocol providing proof of possession of the private key, for example TLS 1.3 [RFC8446]. A future version of this draft may specify explicit proof of possession of the private key of PK_V in the voucher request, e.g., by including a signature of the voucher request with the private key of PK_V.¶
We assume a Diffie-Hellman key exchange protocol complying with the LAKE requirements [I-D.ietf-lake-reqs]. Specifically we assume for the LAKE:¶
Three security sessions are going on in parallel (see Figure 2):¶
The content of the LAKE messages (see Section 3.4) is highlighted with brackets in the figure below (Figure 2) using the notation of EDHOC [I-D.selander-lake-edhoc]. The content includes:¶
We study each security session in turn, starting with the last.¶
U V W | (G_X) | | | AD1=(LOC_W, CC, AEAD(K_1; ID_U)) | | +----------------------------------->| | | LAKE message 1 |G_X, PK_V, CC, AEAD(K_1; ID_U)| | +----------------------------->| | | Voucher Request (VREQ) | | | | | | CERT_PK_U, Voucher | | |<-----------------------------+ | (ID_CRED_V, Sig(V;)) | Voucher Response (VRES) | | AD2=Voucher | | |<-----------------------------------+ | | LAKE message 2 | | | | | | (Sig(U;)) | | +----------------------------------->| | | LAKE message 3 | | where Voucher = AEAD(K_2; V_TYPE, PK_V, G_X, ID_U)
The communication between device and authorization server is carried out via the authenticator protected between the endpoints (protocol between U and W in Figure 2) using an ECIES hybrid encryption scheme (see [I-D.irtf-cfrg-hpke]): The device uses the private key corresponding to its ephemeral DH key G_X generated for LAKE message 1 (see Section 4.2) together with the static public DH key of the authorization server G_W to generate a shared secret G_XW. The shared secret is used to derive AEAD encryption keys to protect data between device and authorization server. The data is carried in AD1 and AD2 (between device and authenticator) and in Voucher Request/Response (between authenticator and authorization server).¶
TODO: Reference relevant ECIES scheme in [I-D.irtf-cfrg-hpke].¶
TODO: Define derivation of encryption keys (K_1, K_2) and nonces (N_1, N_2) for the both directions¶
AD1 SHALL be the following CBOR sequence containing voucher information:¶
AD1 = (
LOC_W: tstr,
CC: bstr,
CIPHERTEXT_RQ: bstr
)
¶
where¶
'CIPHERTEXT_RQ' is 'ciphertext' of COSE_Encrypt0 (Section 5.2-5.3 of [RFC8152]) computed from the following:¶
plaintext = (
ID: bstr
)
¶
external_aad = (
CC: bstr
)
¶
where¶
AD2 SHALL be the Voucher, defined in the next section.¶
AD2 = (
Voucher: bstr
)
¶
The Voucher is essentially a Message Authentication Code binding the identity of the authenticator to the first message sent from the device in the LAKE protocol.¶
More specifically 'Voucher' is the 'ciphertext' of COSE_Encrypt0 (Section 5.2 of [RFC8152]) computed from the following:¶
external_aad = bstr .cbor external_aad_array¶
external_aad_array = [
voucher_type: int,
PK_V: bstr,
G_X: bstr,
CC: bstr,
ID: bstr
]
¶
where¶
PK_V is a COSE_Key containing the public authentication key of the authenticator. The public key must be an Elliptic Curve Diffie-Hellman key, COSE key type 'kty' = 'EC2' or 'OKP'.¶
All parameters, except 'voucher-type', are as received in the voucher request (see Section 4.3).¶
TODO: Consider making the voucher a CBOR Map to indicate type of voucher, to indicate the feature (cf. Section 4.3)¶
The device and authenticator run the LAKE protocol authenticated with public keys (PK_U and PK_V) of the device and the authenticator, see protocol between U and V in Figure 2. The normal processing of the LAKE is omitted here.¶
The device selects a cipher suite with an ECDH curve satisfying the static public DH key G_W of the authorization server. As part of the normal LAKE processing, the device generates the ephemeral public key G_X to be sent in LAKE message 1. A new G_X MUST be generated for each execution of the protocol. The ephemeral key G_X is reused in the ECIES scheme, see Section 4.1.¶
The device sends LAKE message 1 with AD1 as specified in Section 4.1.¶
The authenticator receives LAKE message 1 from the device, which triggers the exchange of voucher related data with the authorization server as described in Section 4.3.¶
The authenticator sends LAKE message 2 to the device with the voucher (see Section 4.1) in AD2. The public key PK_V is encoded in the way public keys are encoded in the LAKE protocol.¶
The device MUST verify the Voucher using its ephemeral key G_X sent in message 1 and PK_V received in message 2. If the Voucher does not verify, the device MUST discontinue the protocol.¶
The device sends message 3. AD3 depends on the kind of enrollment the device is requesting. It may e.g. be a CBOR encoded Certificate Signing Request, see [I-D.raza-ace-cbor-certificates].¶
The authenticator MUST NOT verify the signature Sig(U;) (see Figure 2) in LAKE message 3 with the PK_U included in message 3. Instead, the signature MUST be verified with the public key included in Cert(PK_U) (see Section 4.3.2) received from the authorization server. This way, the authenticator can make sure that message 3 is signed by the right entity trusted by the authorization server.¶
The authenticator and authorization server are assumed to have secure communication, for example TLS 1.3 authenticated with certificates, protecting the Voucher Request/Response Protocol (see protocol between V and W in Figure 2).¶
The authenticator sends the voucher request to the authorization server. The Voucher_Request SHALL be a CBOR array as defined below:¶
Voucher_Request = [
PK_V: bstr,
G_X: bstr,
CC: bstr,
CIPHERTEXT_RQ: bstr
]
¶
where the parameters are defined in Section 4.1.¶
The authorization server decrypts the identity of the device and looks up its certificate, Cert(PK_U). The authorization server sends the voucher response to the authenticator. The Voucher_Response SHALL be a CBOR array as defined below:¶
Voucher_Response = [
CERT_PK_U: bstr,
Voucher: bstr
]
¶
where¶
TODO: The voucher response may contain a "Voucher-info" field as an alternative to make the Voucher a CBOR Map (see Section 4.1)¶
This section defines the profile of the ACE framework (see Appendix C of [I-D.ietf-ace-oauth-authz]).¶
U plays the role of the ACE Resource Server (RS). V plays the role of the ACE Client (C). W plays the role of the ACE Authorization Server (AS).¶
C and RS use the Auxiliary Data in the LAKE protocol to communicate. C and RS use the LAKE protocol to protect their communication. LAKE also provides mutual authentication of C and RS, assisted by the AS.¶
RS C AS | LAKE Message 1 | | | AD1=AS Request Creation Hints | | |-------------------------------->| POST /token | | |-------------------->| | | | | | Access Token + | | LAKE Message 2 | Access Information | | AD2=Access Token |<--------------------| |<--------------------------------| | | LAKE Message 3 | | |-------------------------------->| |
RS proactively sends the AS Request Creation Hints message to C to signal the information on where C can reach the AS. RS piggybacks the AS Request Creation Hints message using Auxiliary Data of the LAKE message 1. Before continuing the LAKE handshake, based on the AS Request Creation Hints information, C sends a POST request to the token endpoint at the AS requesting the access token. The AS issues an assertion to C that is cryptographically protected based on the secret shared between the AS and RS. In this profile, the assertion is encoded as a Bearer Token. C presents this token to RS in the Auxiliary Data of the LAKE message 2. RS verifies the token based on the possession of the shared secret with the AS and authenticates C.¶
Parameters that can appear in the AS Request Creation Hints message are specified in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. RS MUST use the "AS" parameter to transport LOC_W, i.e. an absolute URI where C can reach the AS. RS MUST use the "audience" parameter to transport the CBOR sequence consisting of two elements: CC, the crypto context; CIPHERTEXT_RQ, the authenticated encrypted identity of the RS. The "cnonce" parameter MUST be implied to G^X, i.e. the ephemeral public key of the RS in the underlying LAKE exchange. The "cnonce" parameter is not carried in the AS Request Creation Hints message for byte saving reasons. AS Request Creation Hints MUST be carried within Auxiliary Data of the LAKE message 1 (AD1).¶
An example AD1 value in CBOR diagnostic notation is shown below:¶
AD1:
{
"AS" : "coaps://as.example.com/token",
"audience": << h'73',h'737570657273...' >>
}
¶
The protocol that provides the secure channel between C and the AS is out-of-scope. This can, for example, be TLS or DTLS. What is important is that the two peers are mutually authenticated, and that the secure channel provides message integrity, confidentiality and freshness. It is also necessary for the AS to be able to extract the public key of C used in the underlying security handshake.¶
C sends the POST request to the token endpoint at the AS following Section 5.6.1. of [I-D.ietf-ace-oauth-authz]. C MUST set the "audience" parameter to the value received in AS Request Creation Hints. C MUST set the "cnonce" parameter to G^X, the ephemeral public key of RS in the LAKE handshake.¶
An example exchange using CoAP and CBOR diagnostic notation is shown below:¶
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: "application/ace+cbor"
Payload:
{
"audience" : << h'73',h'737570657273...' >>
"cnonce" : h'756E73686172...'
}
¶
Given successful authorization of C at the AS, the AS responds by issuing a Bearer token and retrieves the certificate of RS on behalf of C. The access token and the certificate are passed back to C, who uses it to complete the LAKE handshake. This document extends the ACE framework by registering a new Access Information parameter:¶
rsp_ad: OPTIONAL. Carries additional information from the AS to C associated with the access token.¶
When responding to C, the AS MUST set the "ace_profile" parameter to "lake". The AS MUST set the "token_type" parameter to "Bearer". The access token MUST be formatted as specified in Section 4.1.1. The AS MUST set the "rsp_ad" parameter to the certificate of RS. To be able to do so, AS first needs to decrypt the audience value, and based on it retrieve the corresponding RS certificate.¶
An example AS response to C is shown below:¶
2.01 Created
Content-Format: application/ace+cbor
Max-Age: 3600
Payload:
{
"ace_profile" : "lake",
"token_type" : "Bearer",
"access_token" : h'666F726571756172746572...',
"rsp_ad" : h'61726973746F64656D6F637261746963616C...'
}
¶
TODO: Identity protection of device¶
TODO: Use of G_X as ephemeral key between device and authenticator, and between device and authorization server¶
TODO: Remote attestation¶
TODO: CC registry¶
TODO: Voucher type registry¶
TODO: register rsp_ad ACE parameter¶