Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
draft-ietf-ace-dtls-authorize-05
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9202.
|
|
---|---|---|---|
Authors | Stefanie Gerdes , Olaf Bergmann , Carsten Bormann , Göran Selander , Ludwig Seitz | ||
Last updated | 2019-01-28 (Latest revision 2018-10-08) | ||
Replaces | draft-gerdes-ace-dtls-authorize | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-12)
by Paul Kyzivat
Ready w/issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | In WG Last Call | |
Associated WG milestone |
|
||
Document shepherd | Jim Schaad | ||
IESG | IESG state | Became RFC 9202 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | Jim Schaad <ietf@augustcellars.com> |
draft-ietf-ace-dtls-authorize-05
#x27;s keying material is associated with the channel. Any request that the resource server receives on this channel MUST be checked against these authorization rules. RS MUST check for every request if the access token is still valid. 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 as described in Section 5.1.1 of draft-ietf-ace-oauth-authz [24]. The resource server SHOULD treat 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. 3. The request is destined for the resource server. 4. The resource URI specified in the request is covered by the authorization information. 5. The request method is an authorized action on the resource with respect to the authorization information. Incoming CoAP requests received on a secure DTLS channel that are not thus authorized MUST be rejected according to Section 5.8.2 of draft- ietf-ace-oauth-authz [25] Gerdes, et al. Expires April 11, 2019 [Page 12] Internet-Draft CoAP-DTLS October 2018 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 cannot always know a priori if an Authorized Resource Request will succeed. If the client repeatedly gets error responses containing AS Information (cf. Section 5.1.2 of draft-ietf-ace- oauth-authz [26]) 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. 4. Dynamic Update of Authorization Information The client can update the authorization information stored at the resource server at any time without changing an established DTLS session. To do so, the Client requests a new access token from the authorization server for the intended action on the respective resource and uploads this access token to the authz-info resource on the resource server. Figure 7 depicts the message flow where the C requests a new access token after a security association between the client and the resource server has been established using this protocol. If the client wants to update the authorization information, the token request MUST specify the key identifier of the existing DTLS channel between the client and the resource server in the "kid" parameter of the Client-to-AS request. The authorization server MUST verify that the specified "kid" denotes a valid verifier for a proof-of- possession token that has previously been issued to the requesting client. Otherwise, the Client-to-AS request MUST be declined with the error code "unsupported_pop_key" as defined in Section 5.6.3 of draft-ietf-ace-oauth-authz [27]. When the authorization server issues a new access token to update existing authorization information, it MUST include the specified "kid" parameter in this access token. A resource server MUST associate the updated authorization information with any existing DTLS session that is identified by this key identifier. Note: By associating the access tokens with the identifier of an existing DTLS session, the authorization information can be updated without changing the cryptographic keys for the DTLS communication between the client and the resource server, i.e. an existing session can be used with updated permissions. Gerdes, et al. Expires April 11, 2019 [Page 13] Internet-Draft CoAP-DTLS October 2018 C RS AS | <===== DTLS channel =====> | | | + Access Token | | | | | | --- Token Request ----------------------------> | | | | | <---------------------------- New Access Token - | | + Access Information | | | | | --- Update /authz-info --> | | | New Access Token | | | | | | == Authorized Request ===> | | | | | | <=== Protected Resource == | | Figure 7: Overview of Dynamic Update Operation 5. Token Expiration DTLS sessions that have been established in accordance with this profile are always tied to a specific set of access tokens. As these tokens may become invalid at any time (either because the token has expired or the responsible authorization server has revoked the token), the session may become useless at some point. A resource server therefore MUST terminate existing DTLS sessions after the last valid access token for this session has been deleted. As specified in Section 5.8.3 of draft-ietf-ace-oauth-authz [28], the resource server MUST notify the client with an error response with code 4.01 (Unauthorized) for any long running request before terminating the session. Table 1 updates Figure 2 in Section 5.1.2 of draft-ietf-ace-oauth- authz [29] with the new "kid" parameter in accordance with [RFC8152]. +----------------+----------+-----------------+ | Parameter name | CBOR Key | Major Type | +----------------+----------+-----------------+ | kid | 4 | 2 (byte string) | +----------------+----------+-----------------+ Table 1: Updated AS Information parameters Gerdes, et al. Expires April 11, 2019 [Page 14] Internet-Draft CoAP-DTLS October 2018 6. 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 and privacy considerations from section 6 and section 7 also apply to this profile. 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. [I-D.tiloca-tls-dos-handshake] specifies a TLS extension to prevent this type of attack which is applicable especially for constrained environments where the authorization server can act as trust anchor. The use of multiple access tokens for a single client increases the strain on the resource server as it must consider every access token and calculate the actual permissions of the client. Also, tokens may contradict each other which may lead the server to enforce wrong permissions. If one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection. Developers should avoid using multiple access tokens for a client. 7. Privacy Considerations 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 the 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. Also, unprotected requests to the resource server may reveal information about the client, e.g., which resources the client attempts to request or the data that the client wants to provide to the resource server. The client should not send confidential data in an unprotected request. Note that some information might still leak after DTLS session is established, due to observable message sizes, the source, and the destination addresses. Gerdes, et al. Expires April 11, 2019 [Page 15] Internet-Draft CoAP-DTLS October 2018 8. IANA Considerations The following registrations are done for the ACE OAuth Profile Registry following the procedure specified in [I-D.ietf-ace-oauth-authz]. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. Profile name: coap_dtls Profile Description: Profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. Profile ID: 1 Change Controller: IESG Reference: [RFC-XXXX] 9. References 9.1. Normative References [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 (work in progress), October 2018. [I-D.tiloca-tls-dos-handshake] Tiloca, M., Seitz, L., Hoeve, M., and O. Bergmann, "Extension for protecting (D)TLS handshakes against Denial of Service", draft-tiloca-tls-dos-handshake-02 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <https://www.rfc-editor.org/info/rfc4279>. Gerdes, et al. Expires April 11, 2019 [Page 16] Internet-Draft CoAP-DTLS October 2018 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [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, <https://www.rfc-editor.org/info/rfc7925>. [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 9.2. Informative References [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <https://www.rfc-editor.org/info/rfc6655>. [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, <https://www.rfc-editor.org/info/rfc7250>. [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, <https://www.rfc-editor.org/info/rfc7251>. [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>. Gerdes, et al. Expires April 11, 2019 [Page 17] Internet-Draft CoAP-DTLS October 2018 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>. [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/info/rfc8392>. [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>. 9.3. URIs [1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.8.1 [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz [3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz [4] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz [5] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.1.2 [6] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz [7] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.3 [8] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.8.1 [9] https://tools.ietf.org/html/rfc7252#section-9 [10] https://tools.ietf.org/html/rfc7250 [11] https://tools.ietf.org/html/rfc7252 [12] https://tools.ietf.org/html/rfc7748 [13] https://tools.ietf.org/html/rfc7252 [14] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz Gerdes, et al. Expires April 11, 2019 [Page 18] Internet-Draft CoAP-DTLS October 2018 [15] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz [16] https://tools.ietf.org/html/rfc8152#section-11 [17] https://tools.ietf.org/html/rfc8152#section-11.2 [18] https://tools.ietf.org/html/rfc6749#section-5.2 [19] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz#section- 5.7.3 [20] https://tools.ietf.org/html/rfc4279#section-2 [21] https://tools.ietf.org/html/rfc7925#section-4.2 [22] https://tools.ietf.org/html/rfc7252 [23] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz [24] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.1.1 [25] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.8.2 [26] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.1.2 [27] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.6.3 [28] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.8.3 [29] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 16#section-5.1.2 Authors' Addresses Stefanie Gerdes Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63906 Email: gerdes@tzi.org Gerdes, et al. Expires April 11, 2019 [Page 19] Internet-Draft CoAP-DTLS October 2018 Olaf Bergmann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63904 Email: bergmann@tzi.org Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Goeran Selander Ericsson AB Email: goran.selander@ericsson.com Ludwig Seitz RISE SICS Scheelevaegen 17 Lund 223 70 Sweden Email: ludwig.seitz@ri.se Gerdes, et al. Expires April 11, 2019 [Page 20]