--- 1/draft-ietf-ace-dtls-authorize-10.txt 2020-06-18 06:13:10.145237145 -0700 +++ 2/draft-ietf-ace-dtls-authorize-11.txt 2020-06-18 06:13:10.201238567 -0700 @@ -1,24 +1,24 @@ ACE Working Group S. Gerdes Internet-Draft O. Bergmann Intended status: Standards Track C. Bormann -Expires: November 14, 2020 Universitaet Bremen TZI +Expires: December 20, 2020 Universitaet Bremen TZI G. Selander Ericsson AB L. Seitz Combitech - May 13, 2020 + June 18, 2020 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) - draft-ietf-ace-dtls-authorize-10 + draft-ietf-ace-dtls-authorize-11 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 November 14, 2020. + This Internet-Draft will expire on December 20, 2020. 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 @@ -61,35 +61,35 @@ 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.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10 3.3.1. DTLS Channel Setup Between Client and Resource Server 14 - 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 15 + 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16 4. Dynamic Update of Authorization Information . . . . . . . . . 17 5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 18 - 6. Secure Communication with an Authorization Server . . . . . . 18 + 6. Secure Communication with an Authorization Server . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 20 7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 21 7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 21 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 11.2. Informative References . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + 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 authorization to access protected resources hosted by the resource server. Also, the client and the resource server are provided by the @@ -269,22 +269,22 @@ by the resource owner (RO) concerning the client and the resource server that relate to this keying material. The client and the authorization server MUST use their respective keying material for all exchanged messages. How the security 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 Section 6 specifies how communication with the authorization - server is secured. + 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 @@ -408,33 +408,35 @@ 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. 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]. The resource server MUST use its own raw public key in - the DTLS handshake with the client. If the resource server has - several raw public keys, it must already know which key it is - supposed to use with this client. How this is achieved is not part - of this profile. + 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]. - The resource server MUST use the keying material that the - authorizations server has specified in the "cnf" parameter in the - access token for the DTLS handshake with the client. Thus, the - handshake only finishes if the client and the resource server are - able to use their respective keying material. + 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 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 @@ -455,24 +457,26 @@ detect unauthorized changes. If the token contains confidential data such as the symmetric key, the confidentiality of the token MUST also be protected. Depending on the requested token type and algorithm in the access token request, the authorization server adds access Information to the response that provides the client with sufficient information to setup a DTLS channel with the resource server. The authorization server adds a "cnf" parameter to the access information carrying a "COSE_Key" object that informs the client about the shared secret that is to be used between the client and the resource server. To convey the same secret to the resource server, the authorization - server either includes it directly in the access token by means of - the "cnf" claim or it provides sufficient information to enable the - resource server to derive the key from the access token using key - derivation. + server can include it directly in the access token by means of the + "cnf" claim or provide sufficient information to enable the resource + server to derive the shared secret from the access token. As an + alternative, the resource server MAY use token introspection to + retrieve the keying material for this access token directly from the + authorization server. An example access token request for an access token with a symmetric proof-of-possession key is illustrated in Figure 5. POST coaps://as.example.com/token Content-Format: application/ace+cbor Payload: { audience : "smokeSensor1807", } @@ -555,31 +559,31 @@ used to protect the communication between the authorization server and the resource server. Knowledge of the symmetric key shared with the client must not reveal any information about the key derivation key or other secret keys shared between the authorization server and resource server. In order to generate a new symmetric key to be used by client and resource server, the authorization server generates a new key identifier which MUST be unique among all key identifiers used by the - authorization 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. + 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. 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 @@ -599,25 +603,30 @@ ] where: o type is set to the constant text string "ACE-CoAP-DTLS-key- derivation", o L is the size of the symmetric key in bytes, o access_token is the decrypted access_token as transferred from the - authorization server to the resource server. + authorization server to the resource server. The decrypted access + token usually denotes a CWT claim set represented as CBOR map. - To ensure uniqueness of the derived shared secret, the authorization - server SHOULD generate a sufficiently random kid value and include - the claims "iat" and either "exp" or "exi" in the access token. + Use of a unique (per resource server) "kid" and the use of a key + derivation IKM that is 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 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 @@ -658,26 +667,35 @@ As an alternative to the access token upload, the client can provide the most recent access token in the "psk_identity" field of the ClientKeyExchange message. To do so, the client MUST treat the contents of the "access_token" field from the AS-to-Client response as opaque data as specified in Section 4.2 of [RFC7925] and not perform any re-coding. This allows the resource server to retrieve the shared secret directly from the "cnf" claim of the access token. If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST - process the contents of the "psk_identity" field as access token that - is stored with the authorization information endpoint, before - continuing the DTLS handshake. If the contents of the "psk_identity" - do not yield a valid access token for the requesting client, the - resource server aborts the DTLS handshake with an "illegal_parameter" - alert. + parse the contents of the "psk_identity" field as CBOR data structure + and process the contents as following: + + o If the data contains a "cnf" field with a "COSE_Key" structure + with a "kid", the resource server continues the DTLS handshake + with the stored key associated with this kid. + + o If the data comprises additional CWT information, this information + must be stored as access token for this DTLS association before + continuing with the DTLS handshake. + + 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 @@ -695,37 +713,37 @@ 3.4. Resource Access Once a DTLS channel has been established as described in Section 3.2 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. + 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. 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 MAY include AS Request Creation Hints as + response. The response SHOULD include AS Request Creation Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. The resource server MUST only accept an incoming CoAP request as authorized if the following holds: 1. The message was received on a secure channel that has been established using the procedure defined in this document. 2. The authorization information tied to the sending client is valid. @@ -745,24 +763,31 @@ 1. with response code 4.03 (Forbidden) when the resource URI specified in the request is not covered by the authorization information, and 2. with response code 4.05 (Method Not Allowed) when the resource URI specified in the request covered by the authorization information but not the requested action. The client MUST ascertain that its keying material is still valid before sending a request or processing a response. If the client - gets an error response containing AS Request Creation Hints (cf. - Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its - requests, it SHOULD request a new access token from the authorization - server in order to continue communication with the resource server. + recently has updated the access token (see Section 4), it must be + prepared that its request is still handled according to the previous + authorization rules as there is no strict ordering between access + token uploads and resource access messages. See also Section 7.2 for + a discussion of access token processing. + + If the client gets an error response containing AS Request Creation + Hints (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response + to its requests, it SHOULD request a new access token from the + authorization server in order to continue communication with the + resource server. Unauthorized requests that have been received over a DTLS session SHOULD be treated as non-fatal by the resource server, i.e., the DTLS session SHOULD be kept alive until the associated access token has expired. 4. Dynamic Update of Authorization Information Resource servers must only use a new access token to update the authorization information for a DTLS session if the keying material @@ -830,55 +855,57 @@ after the last access token associated with this association has expired. As specified in Section 5.8.3 of [I-D.ietf-ace-oauth-authz], the resource server MUST notify the client with an error response with code 4.01 (Unauthorized) for any long running request before terminating the association. 6. Secure Communication with an Authorization Server - As specified in the ACE framework (sections 5.6 and 5.7 of + As specified in the ACE framework (Sections 5.6 and 5.7 of [I-D.ietf-ace-oauth-authz]), the requesting entity (the resource server and/or the client) and the authorization server communicate via the token endpoint or introspection endpoint. The use of CoAP and DTLS for this communication is RECOMMENDED in this profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be used instead. How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the authorization server are established is out of scope for this profile. If other means of securing the communication with the authorization server are used, the communication security requirements from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable. 7. Security Considerations This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. As it follows this framework's general - approach, the general security considerations from section 6 of + approach, the general security considerations from Section 6 of [I-D.ietf-ace-oauth-authz] also apply to this profile. The authorization server must ascertain that the keying material for the client that it provides to the resource server actually is associated with this client. Malicious clients may hand over access tokens containing their own access permissions to other entities. This problem cannot be completely eliminated. Nevertheless, in RPK mode it should not be possible for clients to request access tokens - for arbitrary public keys, since that would allow the client to relay - tokens without the need to share its own credentials with others. - The authorization server therefore at some point needs to validate - that the client can actually use the private key corresponding to the - client's public key. + for arbitrary public keys: if the client can cause the authorization + server to issue a token for a public key without proving possession + of the corresponding private key, this allows for identity misbinding + attacks where the issued token is usable by an entity other than the + intended one. The authorization server therefore at some point needs + to validate that the client can actually use the private key + corresponding to the client's public key. When using pre-shared keys provisioned by the authorization server, the security level depends on the randomness of PSK, and the security of the TLS cipher suite and key exchange algorithm. As this specification targets at constrained environments, message payloads exchanged between the client and the resource server are expected to be small and rare. CoAP [RFC7252] mandates the implementation of cipher suites with abbreviated, 8-byte tags for message integrity protection. For consistency, this profile requires implementation of the same cipher suites. For application scenarios where the cost of @@ -976,21 +1003,21 @@ authorization server must have obtained a common understanding how this resource server is identified to ensure that the client obtains access token and keying material for the correct resource server. If the client is provided with a raw public key for the resource server, it must be ascertained to which resource server (which identifier and authorization information) the key is associated. All authorization information and keying material must be kept up to date. 8. Privacy Considerations - This privacy considerations from section 7 of the + This privacy considerations from Section 7 of the [I-D.ietf-ace-oauth-authz] apply also to this profile. An unprotected response to an unauthorized request may disclose information about the resource server and/or its existing relationship with the client. It is advisable to include as little information as possible in an unencrypted response. When a DTLS session between an authenticated client and the resource server already exists, more detailed information MAY be included with an error response to provide the client with sufficient information to react on that particular error. @@ -1069,20 +1095,25 @@ [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . + [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- + CCM Elliptic Curve Cryptography (ECC) Cipher Suites for + TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, + . + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . @@ -1116,25 +1147,20 @@ [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, . - [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- - CCM Elliptic Curve Cryptography (ECC) Cipher Suites for - TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, - . - [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032,