Lightweight Authorization for Authenticated Key Exchange.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Readers are expected to have some 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.¶

3.1. Device

The device is pre-provisioned with an identity ID_U 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. ID_U may be a reference or pointer to the certificate.¶

The device is also provisioned with information about its authorization server:¶

• At least one static public DH key of the authorization server (G_W) used to ensure secure communication with the device (see Section 4.3).¶
• Location information about the authorization server (LOC_W), e.g. its domain name. This information may be available in the device certificate Cert_PK_U.¶

3.2. Domain Authenticator

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 LOC_W is expected to be sufficient. The communication between domain authenticator and authorization server 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.¶

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 corresponding to PK_V.¶

3.3. Authorization Server

The authorization server has the private DH key corresponding to G_W, which is used to secure the communication with the device (see Section 4.3).¶

Authentication credentials and communication security used with the domain authenticator is out of scope, except for the need to verify the possession of the private key of PK_V as specified in Section 3.2.¶

The authorization server provides to the device the authorization decision for enrollment with the domain authenticator in the form of a voucher. The authorization server provides information to the domain authenticator about the device, such as the device's certificate Cert_PK_U.¶

The authorization server needs to be available during the execution of the protocol.¶

4.1. Overview

Three security sessions are going on in parallel:¶

1. EDHOC [I-D.ietf-lake-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.¶

Figure 2 provides an overview of the message flow detailed in this section. Only selected message fields of EDHOC are shown, for more details see Section 3.1 of [I-D.ietf-lake-edhoc].¶

U                                    V                              W
|                                    |                              |
|        SUITES_I, G_X, EAD_1        |                              |
+----------------------------------->|                              |
|          EDHOC message_1           |   SS, G_X, ENC_ID, ?PoP_V    |
|                                    +----------------------------->|
|                                    |    Voucher Request (VREQ)    |
|                                    |                              |
|                                    |    G_X, CERT_PK_U, Voucher   |
|                                    |<-----------------------------+
|                                    |    Voucher Response (VRES)   |
|   ID_CRED_R, Sig_or_MAC_2, EAD_2   |                              |
|<-----------------------------------+                              |
|          EDHOC message_2           |                              |
|                                    |                              |
|       ID_CRED_I, Sig_or_MAC_3      |                              |
+----------------------------------->|                              |
|          EDHOC message_3           |                              |

where
EAD_1 = (L, Voucher_Info)
Voucher_Info = [LOC_W, ENC_ID]
EAD_2 = (L, Voucher)
Voucher = MAC(V_TYPE, SS, G_X, ID_U, PK_V)

4.2. Reuse of EDHOC

The protocol illustrated in Figure 2 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, as ephemeral key and nonce.¶

• 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 [I-D.ietf-lake-edhoc]):¶

  • 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 of message_1 and message_2, respectively, for which dedicated content is defined in this document.¶
• ID_CRED_I and ID_CRED_R are used to identify the public authentication keys of U and V. In this protocol ID_CRED_I can be empty since V obtains the certificate of U from W, whereas ID_CRED_R contains the public authentication key of V.¶
• Signature_or_MAC_2 and Signature_or_MAC_3 (abbreviated in Figure 2), 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 protocol also reuses the Extract and Expand key derivation from EDHOC (Section 4 of [I-D.ietf-lake-edhoc]).¶

• 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 [I-D.ietf-cose-rfc8152bis-algs].¶

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 [I-D.ietf-lake-edhoc]:¶

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

  where¶

info = (
   transcript_hash : bstr,
   label : tstr,
   context : bstr,
   length : uint,
)

4.3. Device <-> Authorization Server

The protocol between device and authorization server (U and W in Figure 2) is carried out via the authenticator (V) with certain data protected between the endpoints using the equivalent of a hybrid encryption scheme (see, e.g., [I-D.irtf-cfrg-hpke]). The device uses the public DH key of the authorization server G_W together with the private DH key corresponding to ephemeral key G_X in EDHOC message_1, and vice versa for the authorization server. The endpoints calculate a shared secret G_XW (see Section 4.2), which is used to derive secret keys to protect data between U and W, as detailed in this section.¶

The data exchanged betweeen U and W is carried between U and V in EAD_1 and EAD_2 (Section 4.4), and between V and W in Voucher Request/Response (Section 4.5).¶

Voucher_Info = (
    LOC_W:      tstr,
    ENC_ID:     bstr
)

plaintext = (
    ID_U:            bstr,
  ? ID_V:            bstr,
 )

external_aad = (
    SS:              int,
 )

voucher_input = (
    V_TYPE:        int,
    SS:            int,
    G_X:           bstr,
    ID_U:          bstr,
    PK_V:          bstr,
)

4.4. Device <-> Authenticator

The device and authenticator run the EDHOC protocol authenticated with their public keys (PK_U and PK_V), see Figure 2. Normal EDHOC processing is omitted here.¶

ID_CRED_I =
{
  4 : h''
}

4.5. Authenticator <-> Authorization Server

The authenticator and authorization server are assumed to have, or to be able to, set up a secure connection, for example TLS 1.3 authenticated with certificates. The authenticator is assumed to authenticate with the public key PK_V, see Section 3.2.¶

This secure connection protects the Voucher Request/Response Protocol (see protocol between V and W in Figure 2).¶

The ephemeral public key G_X sent in EDHOC message_1 from device to authenticator serves as challenge/response nonce for the Voucher Request/Response Protocol, and binds together instances of the two protocols.¶

Voucher_Request = [
    SS:              int,
    G_X:             bstr,
    ENC_ID:          bstr,
  ? PoP_V:           bstr,
]

Voucher_Response = [
    G_X:            bstr,
    CERT_PK_U:      bstr,
    Voucher:        bstr
]

5.1. Protocol Overview

  RS (U)                             C (V)                 AS (W)
   |          EDHOC message_1        |                     |
   |  AD1=AS Request Creation Hints  |                     |
   |-------------------------------->|     POST /token     |
   |                                 |-------------------->|
   |                                 |                     |
   |                                 | Access Token +      |
   |          EDHOC message_2        |  Access Information |
   |          AD2=Access Token       |<--------------------|
   |<--------------------------------|                     |
   |          EDHOC message_3        |                     |
   |-------------------------------->|                     |

1. RS proactively sends the AS Request Creation Hints message to C to signal the information on where C can reach the AS.¶
2. RS piggybacks the AS Request Creation Hints message using Auxiliary Data of EDHOC message_1.¶
3. Before continuing the EDHOC exchange, based on the AS Request Creation Hints information, C sends a POST request to the token endpoint at the AS requesting the access token.¶
4. 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.¶
5. C presents this token to RS in EAD_2.¶
6. RS verifies the token based on the possession of the shared secret with the AS and authenticates C.¶

5.2. AS Request Creation Hints

Parameters that can appear in the AS Request Creation Hints message are specified in Section 5.3 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: SS, the selected cipher suite; ENC_ID, the AEAD encrypted blob containing identities. The "cnonce" parameter MUST be implied to G_X, i.e. the ephemeral public key of the RS in the underlying EDHOC 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 EAD_1.¶

An example EAD_1 value in CBOR diagnostic notation is shown below:¶

EAD_1:
{
    "AS" : "coaps://as.example.com/token",
    "audience": << h'73',h'737570657273...' >>
}

5.3. Client-to-AS Request

The protocol that provides the secure connection between C and the AS is out-of-scope. This can, for example, be TLS 1.3. What is important is that the two peers are mutually authenticated, and that the secure connection 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.8.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 EDHOC exchange.¶

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...'
    }

5.4. AS-to-Client Response

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 EDHOC exchange. 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.¶

The AS-to-Client responsE MUST contain:¶

• ace_profileparameter set to "edhoc-authz"¶
• token_type parameter set to "Bearer"¶
• access_token as specified in Section 4.3.2¶
• rsp_ad = bstr .cbor cert_gx¶

cert_gx = (
    CERT_PK_U:        bstr,
    G_X:              bstr
)

where:¶

• CERT_PK_U is the RS's certificate, as discussed in Section 4.5.2. To be able to retrieve this certificate, the AS first needs to decrypt the audience value and obtain the RS's identity.¶
• G_X is the ephemeral key generated by RS in EDHOC message_1.¶

An example AS response to C is shown below:¶

    2.01 Created
    Content-Format: application/ace+cbor
    Max-Age: 3600
    Payload:
    {
        "ace_profile" : "edhoc-authz",
        "token_type" : "Bearer",
        "access_token" : h'666F726571756172746572...',
        "rsp_ad" : h'61726973746F64656D6F637261746963616C...'
    }