Skip to main content

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
Additional resources Mailing list discussion
Stream WG state In WG Last Call
Revised I-D Needed - Issue raised by WGLC
Associated WG milestone
Feb 2021
Submit DTLS Profile for ACE to the IESG for publication as a proposed standard
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]