--- 1/draft-ietf-ace-dtls-authorize-12.txt 2020-09-08 04:13:43.318397737 -0700 +++ 2/draft-ietf-ace-dtls-authorize-13.txt 2020-09-08 04:13:43.378399257 -0700 @@ -1,24 +1,24 @@ ACE Working Group S. Gerdes Internet-Draft O. Bergmann Intended status: Standards Track C. Bormann -Expires: January 7, 2021 Universitaet Bremen TZI +Expires: March 12, 2021 Universitaet Bremen TZI G. Selander Ericsson AB L. Seitz Combitech - July 06, 2020 + September 08, 2020 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) - draft-ietf-ace-dtls-authorize-12 + draft-ietf-ace-dtls-authorize-13 Abstract This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe @@ -32,21 +32,21 @@ 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 January 7, 2021. + This Internet-Draft will expire on March 12, 2021. Copyright Notice 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 @@ -57,37 +57,39 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Communication Between the Client and the Authorization Server . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6 - 3.2.1. DTLS Channel Setup Between Client and Resource Server 9 + 3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 7 + 3.2.1. Access Token Retrieval from the Authorization Server 7 + 3.2.2. DTLS Channel Setup Between Client and Resource Server 9 3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10 - 3.3.1. DTLS Channel Setup Between Client and Resource Server 14 + 3.3.1. Access Token Retrieval from the Authorization Server 10 + 3.3.2. DTLS Channel Setup Between Client and Resource Server 14 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16 - 4. Dynamic Update of Authorization Information . . . . . . . . . 17 + 4. Dynamic Update of Authorization Information . . . . . . . . . 18 5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19 6. Secure Communication with an Authorization Server . . . . . . 19 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21 - 7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 21 + 7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 22 7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22 - 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This specification defines a profile of the ACE framework [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to communicate. The client obtains an access token, bound to a key (the proof-of-possession key), from an authorization server to prove its @@ -200,21 +201,21 @@ used by the client to establish a new DTLS session with the resource server. When the client intends to use an asymmetric proof-of- possession key in the DTLS handshake with the resource server, the client MUST upload the access token to the authz-info resource, i.e. the authz-info endpoint, on the resource server before starting the DTLS handshake, as described in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric proof-of-possession key in the DTLS handshake, the procedure as above MAY be used, or alternatively, the access token MAY instead be transferred in the DTLS ClientKeyExchange message (see - Section 3.3.1). In any case, DTLS MUST be used in a mode that + Section 3.3.2). In any case, DTLS MUST be used in a mode that provides replay protection. Figure 2 depicts the common protocol flow for the DTLS profile after the client has retrieved the access token from the authorization server, AS. C RS AS | [--- Access Token ------>] | | | | | | <== DTLS channel setup ==> | | @@ -274,32 +275,35 @@ association between the client and the authorization server is bootstrapped is not part of this document. The client and the authorization server must ensure the confidentiality, integrity and authenticity of all exchanged messages within the ACE protocol. Section 6 specifies how communication with the authorization server is secured. 3.2. RawPublicKey Mode - When the client and the resource server use RawPublicKey - authentication, the procedure is as follows: After the client and the - authorization server mutually authenticated each other and validated - each other's authorization, the client sends a token request to the - authorization server's token endpoint. The client MUST add a - "req_cnf" object carrying either its raw public key or a unique - identifier for a public key that it has previously made known to the - authorization server. It is RECOMMENDED that the client uses DTLS - with the same keying material to secure the communication with the - authorization server, proving possession of the key as part of the - token request. Other mechanisms for proving possession of the key - may be defined in the future. + When the client uses RawPublicKey authentication, the procedure is as + described in the following. + +3.2.1. Access Token Retrieval from the Authorization Server + + After the client and the authorization server mutually authenticated + each other and validated each other's authorization, the client sends + a token request to the authorization server's token endpoint. The + client MUST add a "req_cnf" object carrying either its raw public key + or a unique identifier for a public key that it has previously made + known to the authorization server. It is RECOMMENDED that the client + uses DTLS with the same keying material to secure the communication + with the authorization server, proving possession of the key as part + of the token request. Other mechanisms for proving possession of the + key may be defined in the future. An example access token request from the client to the authorization server is depicted in Figure 3. POST coaps://as.example.com/token Content-Format: application/ace+cbor Payload: { grant_type : client_credentials, req_aud : "tempSensor4711", @@ -371,21 +374,21 @@ kty : EC2, crv : P-256, x : h'd7cc072de2205bdc1537...', y : h'f95e1d4b851a2cc80fff...' } } } Figure 4: Access Token Response Example for RPK Mode -3.2.1. DTLS Channel Setup Between Client and Resource Server +3.2.2. DTLS Channel Setup Between Client and Resource Server Before the client initiates the DTLS handshake with the resource server, the client MUST send a "POST" request containing the obtained access token to the authz-info resource hosted by the resource server. After the client receives a confirmation that the resource server has accepted the access token, it SHOULD proceed to establish a new DTLS channel with the resource server. The client MUST use its correct public key in the DTLS handshake. If the authorization server has specified a "cnf" field in the access token response, the client MUST use this key. Otherwise, the client MUST use the public @@ -410,36 +413,43 @@ authorization server. The access token is constructed by the authorization server such that the resource server can associate the access token with the Client's public key. The "cnf" claim MUST contain either the client's RPK or, if the key is already known by the resource server (e.g., from previous communication), a reference to this key. If the authorization server has no certain knowledge that the Client's key is already known to the resource server, the Client's public key MUST be included in the access token's "cnf" parameter. If CBOR web tokens [RFC8392] are used (as recommended in [I-D.ietf-ace-oauth-authz]), keys MUST be encoded as specified in - [RFC8747]. + [RFC8747]. A resource server MUST have the capacity to store one + access token for every proof-of-possession key of every authorized + client. The raw public key used in the DTLS handshake with the client MUST belong to the resource server. If the resource server has several raw public keys, it needs to determine which key to use. The authorization server can help with this decision by including a "cnf" parameter in the access token that is associated with this communication. In this case, the resource server MUST use the information from the "cnf" field to select the proper keying material. Thus, the handshake only finishes if the client and the resource server are able to use their respective keying material. 3.3. PreSharedKey Mode + When the client uses pre-shared key authentication, the procedure is + as described in the following. + +3.3.1. Access Token Retrieval from the Authorization Server + To retrieve an access token for the resource that the client wants to access, the client MAY include a "cnf" object carrying an identifier for a symmetric key in its access token request to the authorization server. This identifier can be used by the authorization server to determine the shared secret to construct the proof-of-possession token. The authorization server MUST check if the identifier refers to a symmetric key that was previously generated by the authorization server as a shared secret for the communication between this client and the resource server. If no such symmetric key was found, the authorization server MUST generate a new symmetric key that is @@ -568,22 +578,22 @@ identifier which MUST be unique among all key identifiers used by the authorization server for this resource server. The authorization server then uses the key derivation key shared with the resource server to derive the symmetric key as specified below. Instead of providing the keying material in the access token, the authorization server includes the key identifier in the "kid" parameter, see Figure 7. This key identifier enables the resource server to calculate the symmetric key used for the communication with the client using the key derivation key and a KDF to be defined by the application, for example HKDF-SHA-256. The key identifier picked by - the authorization server needs to be unique for each access token - where a unique symmetric key is required. + the authorization server MUST be unique for each access token where a + unique symmetric key is required. In this example, HKDF consists of the composition of the HKDF-Extract and HKDF-Expand steps [RFC5869]. The symmetric key is derived from the key identifier, the key derivation key and other data: OKM = HKDF(salt, IKM, info, L), where: o OKM, the output keying material, is the derived symmetric key @@ -613,28 +623,28 @@ transferred from the authorization server to the resource server. All CBOR data types are encoded in CBOR using preferred serialization and deterministic encoding as specified in Section 4 of [I-D.ietf-cbor-7049bis]. This implies in particular that the "type" and "L" components use the minimum length encoding. The content of the "access_token" field is treated as opaque data for the purpose of key derivation. Use of a unique (per resource server) "kid" and the use of a key - derivation IKM that is unique per authorization server/resource + derivation IKM that MUST be unique per authorization server/resource server pair as specified above will ensure that the derived key is not shared across multiple clients. However, to additionally provide variation in the derived key across different tokens used by the same client, it is additionally RECOMMENDED to include the "iat" claim and either the "exp" or "exi" claims in the access token. -3.3.1. DTLS Channel Setup Between Client and Resource Server +3.3.2. DTLS Channel Setup Between Client and Resource Server When a client receives an access token response from an authorization server, the client MUST check if the access token response is bound to a certain previously sent access token request, as the request may specify the resource server with which the client wants to communicate. The client checks if the payload of the access token response contains an "access_token" parameter and a "cnf" parameter. With this information the client can initiate the establishment of a new @@ -693,28 +703,28 @@ If the contents of the "psk_identity" do not yield sufficient information to select a valid access token for the requesting client, the resource server aborts the DTLS handshake with an "illegal_parameter" alert. When the resource server receives an access token, it MUST check if the access token is still valid, if the resource server is the intended destination (i.e., the audience of the token), and if the token was issued by an authorized authorization server. This - specification assumes that the access token is a PoP token as - described in [I-D.ietf-ace-oauth-authz] unless specifically stated - otherwise. Therefore, the access token is bound to a symmetric PoP - key that is used as shared secret between the client and the resource - server. The resource server may use token introspection [RFC7662] on - the access token to retrieve more information about the specific - token. The use of introspection is out of scope for this - specification. + specification implements access tokens as proof-of-possession tokens. + Therefore, the access token is bound to a symmetric PoP key that is + used as shared secret between the client and the resource server. A + resource server MUST have the capacity to store one access token for + every proof-of-possession key of every authorized client. The + resource server may use token introspection [RFC7662] on the access + token to retrieve more information about the specific token. The use + of introspection is out of scope for this specification. While the client can retrieve the shared secret from the contents of the "cnf" parameter in the AS-to-Client response, the resource server uses the information contained in the "cnf" claim of the access token to determine the actual secret when no explicit "kid" was provided in the "psk_identity" field. If key derivation is used, the resource server uses the "COSE_KDF_Context" information as described above. 3.4. Resource Access @@ -722,24 +732,26 @@ or Section 3.3, respectively, the client is authorized to access resources covered by the access token it has uploaded to the authz- info resource hosted by the resource server. With the successful establishment of the DTLS channel, the client and the resource server have proven that they can use their respective keying material. An access token that is bound to the client's keying material is associated with the channel. According to Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one access token for each client. New access tokens issued by the - authorization server are supposed to replace previously issued access - tokens for the respective client. The resource server therefore must - have a common understanding with the authorization server how access - tokens are ordered. + authorization server replace previously issued access tokens for the + respective client. The resource server therefore must have a common + understanding with the authorization server how access tokens are + ordered. The authorization server may, e.g., specify a "cti" claim + for the access token (see Section 5.8.3 of + [I-D.ietf-ace-oauth-authz]) to employ a strict order. Any request that the resource server receives on a DTLS channel that is tied to an access token via its keying material MUST be checked against the authorization rules that can be determined with the access token. The resource server MUST check for every request if the access token is still valid. If the token has expired, the resource server MUST remove it. Incoming CoAP requests that are not authorized with respect to any access token that is associated with the client MUST be rejected by the resource server with 4.01 response. The response SHOULD include AS Request Creation Hints as @@ -929,31 +941,34 @@ provide similar forward-secrecy properties to using ephemeral Diffie- Hellman (DHE) key exchange mechanisms. For longer-lived access tokens, DHE ciphersuites should be used. Constrained devices that use DTLS [RFC6347] are inherently vulnerable to Denial of Service (DoS) attacks as the handshake protocol requires creation of internal state within the device. This is specifically of concern where an adversary is able to intercept the initial cookie exchange and interject forged messages with a valid cookie to continue with the handshake. A similar issue exists with the - unprotected authorization information endpoint where the resource - server needs to keep valid access tokens until their expiry. - Adversaries can fill up the constrained resource server's internal + unprotected authorization information endpoint when the resource + server needs to keep valid access tokens for a long time. + Adversaries could fill up the constrained resource server's internal storage for a very long time with interjected or otherwise retrieved - valid access tokens. The protection of access tokens that are stored - in the authorization information endpoint depends on the keying - material that is used between the authorization server and the - resource server: The resource server must ensure that it processes - only access tokens that are (encrypted and) integrity-protected by an - authorization server that is authorized to provide access tokens for - the resource server. + valid access tokens. To mitigate against this, the resource server + should set a time boundary until an access token that has not been + used until then will be deleted. + + The protection of access tokens that are stored in the authorization + information endpoint depends on the keying material that is used + between the authorization server and the resource server: The + resource server must ensure that it processes only access tokens that + are (encrypted and) integrity-protected by an authorization server + that is authorized to provide access tokens for the resource server. 7.1. Reuse of Existing Sessions To avoid the overhead of a repeated DTLS handshake, [RFC7925] recommends session resumption [RFC5077] to reuse session state from an earlier DTLS association and thus requires client side implementation. In this specification, the DTLS session is subject to the authorization rules denoted by the access token that was used for the initial setup of the DTLS association. Enabling session resumption would require the server to transfer the authorization