--- 1/draft-ietf-ace-oauth-authz-42.txt 2021-07-10 13:13:55.805525899 -0700 +++ 2/draft-ietf-ace-oauth-authz-43.txt 2021-07-10 13:13:55.961529827 -0700 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft Combitech Intended status: Standards Track G. Selander -Expires: December 10, 2021 Ericsson +Expires: January 11, 2022 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - June 8, 2021 + July 10, 2021 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-42 + draft-ietf-ace-oauth-authz-43 Abstract This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to @@ -34,21 +34,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 December 10, 2021. + This Internet-Draft will expire on January 11, 2022. Copyright Notice Copyright (c) 2021 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 @@ -101,54 +101,54 @@ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 43 6.2. Communication Security . . . . . . . . . . . . . . . . . 44 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 45 6.5. Minimal Security Requirements for Communication . 45 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 6.7. Combining Profiles . . . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.9. Identifying Audiences . . . . . . . . . . . . . . . . . . 48 - 6.10. Denial of Service Against or with Introspection . . 48 + 6.10. Denial of Service Against or with Introspection . . 49 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8.1. ACE Authorization Server Request Creation Hints . . . . . 50 8.2. CoRE Resource Type Registry . . . . . . . . . . . . . . . 51 8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51 8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52 8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 - 8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 + 8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 53 8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53 8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53 8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54 8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54 - 8.11. OAuth Introspection Response Parameter Registration . . . 54 + 8.11. OAuth Introspection Response Parameter Registration . . . 55 8.12. OAuth Token Introspection Response CBOR Mappings Registry 55 - 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 + 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 56 8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57 8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58 8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 59 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 60 10.2. Informative References . . . . . . . . . . . . . . . . . 62 Appendix A. Design Justification . . . . . . . . . . . . . . . . 65 - Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 + Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 69 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71 Appendix D. Assumptions on AS Knowledge about C and RS . . . . . 72 - Appendix E. Differences to OAuth 2.0 . . . . . . . . . . . . . . 72 + Appendix E. Differences to OAuth 2.0 . . . . . . . . . . . . . . 73 Appendix F. Deployment Examples . . . . . . . . . . . . . . . . 73 - F.1. Local Token Validation . . . . . . . . . . . . . . . . . 73 - F.2. Introspection Aided Token Validation . . . . . . . . . . 77 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 + F.1. Local Token Validation . . . . . . . . . . . . . . . . . 74 + F.2. Introspection Aided Token Validation . . . . . . . . . . 78 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 1. Introduction Authorization is the process for granting approval to an entity to access a generic resource [RFC4949]. The authorization task itself can best be described as granting access to a requesting client, for a resource hosted on a device, the resource server (RS). This exchange is mediated by one or multiple authorization servers (AS). Managing authorization for a large number of devices and users can be a complex task. @@ -257,21 +257,22 @@ [I-D.ietf-quic-transport]. Note that this document specifies protocol exchanges in terms of RESTful verbs such as GET and POST. Future profiles using protocols that do not support these verbs MUST specify how the corresponding protocol messages are transmitted instead. A third building block is the Concise Binary Object Representation (CBOR) [RFC8949], for encodings where JSON [RFC8259] is not sufficiently compact. CBOR is a binary encoding designed for small code and message size. Self-contained tokens and protocol message - payloads are encoded in CBOR when CoAP is used. + payloads are encoded in CBOR when CoAP is used. When CoAP is not + used, the use of CBOR remains RECOMMENDED. A fourth building block is CBOR Object Signing and Encryption (COSE) [RFC8152], which enables object-level layer security as an alternative or complement to transport layer security (DTLS [RFC6347] or TLS [RFC8446]). COSE is used to secure self-contained tokens such as proof-of-possession (PoP) tokens, which are an extension to the OAuth bearer tokens. The default token format is defined in CBOR Web Token (CWT) [RFC8392]. Application-layer security for CoAP using COSE can be provided with OSCORE [RFC8613]. @@ -2121,26 +2121,32 @@ lose the current values of counters tracking the "exi" claims of tokens it is storing. The first drawback is inherent to the deployment scenario and the "exi" solution. It can therefore not be mitigated without requiring the RS be online at times. The second drawback can be mitigated by regularly storing the value of "exi" counters to persistent memory. 6.7. Combining Profiles - There may be use cases were different profiles of this framework are - combined. For example, an MQTT-TLS profile is used between the - client and the RS in combination with a CoAP-DTLS profile for - interactions between the client and the AS. The security of a - profile MUST NOT depend on the assumption that the profile is used - for all the different types of interactions in this framework. + There may be use cases where different transport and security + protocols are allowed for the different interactions, and, if that is + not explicitly covered by an existing profile, it corresponds to + combining profiles into a new one. For example, a new profile could + specify that a previously-defined MQTT-TLS profile is used between + the client and the RS in combination with a previously-defined CoAP- + DTLS profile for interactions between the client and the AS. The new + profile that combines existing profiles MUST specify how the existing + profiles' security properties are achieved. Any profile therefore + MUST clearly specify its security requirements and MUST document if + its security depends on the combination of various protocol + interactions. 6.8. Unprotected Information Communication with the authz-info endpoint, as well as the various error responses defined in this framework, all potentially include sending information over an unprotected channel. These messages may leak information to an adversary, or may be manipulated by active attackers to induce incorrect behavior. For example error responses for requests to the Authorization Information endpoint can reveal information about an otherwise opaque access token to an adversary @@ -3362,25 +3371,26 @@ o Cardinality of "grant_type" parameter -- In client-to-AS requests using OAuth 2.0, the "grant_type" parameter is required (per [RFC6749]). In this framework, this parameter is optional. See Section 5.8.1. o Encoding of "scope" parameter -- In client-to-AS requests using OAuth 2.0, the "scope" parameter is string encoded (per [RFC6749]). In this framework, this parameter may also be encoded as a byte string. See Section 5.8.1. o Cardinality of "token_type" parameter -- in AS-to-client responses using OAuth 2.0, the token_type parameter is required (per - [RFC6749]). In this framework, this parameter is optional. See Section 5.8.2. - o Access token retention -- in OAuth 2.0, the access token is sent - with each request to the RS. In this framework, the RS must be + o Access token retention -- in OAuth 2.0, the access token may be + sent with every request to the RS. The exact use of access tokens + depends on the semantics of the application and the session + management concept it uses. In this framework, the RS must be able to store these tokens for later use. See Section 5.10.1. Appendix F. Deployment Examples There is a large variety of IoT deployments, as is indicated in Appendix A, and this section highlights a few common variants. This section is not normative but illustrates how the framework can be applied. For each of the deployment variants, there are a number of possible