--- 1/draft-ietf-ace-oauth-authz-18.txt 2019-01-31 05:13:14.626068964 -0800 +++ 2/draft-ietf-ace-oauth-authz-19.txt 2019-01-31 05:13:14.770072482 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft RISE Intended status: Standards Track G. Selander -Expires: July 21, 2019 Ericsson +Expires: August 4, 2019 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - January 17, 2019 + January 31, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-18 + draft-ietf-ace-oauth-authz-19 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 CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are @@ -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 http://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 July 21, 2019. + This Internet-Draft will expire on August 4, 2019. Copyright Notice Copyright (c) 2019 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,106 +58,108 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 + 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. Discovering Authorization Servers . . . . . . . . . . . . 15 - 5.1.1. Unauthorized Resource Request Message . . . . . . . . 15 - 5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16 - 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17 - 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18 - 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18 + 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 + 5.1.1. Unauthorized Resource Request Message . . . . . . . . 16 + 5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 16 + 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 18 + 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 19 + 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 19 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 19 - 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19 + 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 20 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 20 - 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 22 - 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 24 - 5.6.4. Request and Response Parameters . . . . . . . . . . . 25 - 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 25 - 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 26 - 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 26 - 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27 - 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 27 - 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 28 - 5.7.2. Introspection Response . . . . . . . . . . . . . . . 29 - 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30 - 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31 - 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31 - 5.8.1. The Authorization Information Endpoint . . . . . . . 32 - 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 33 - 5.8.1.2. Protecting the Authzorization Information - Endpoint . . . . . . . . . . . . . . . . . . . . 35 - 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 35 - 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 36 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 6.1. Unprotected AS Information . . . . . . . . . . . . . . . 38 - 6.2. Minimal security requirements for communication . 38 - 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 39 - 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 39 - 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 39 - 6.6. Denial of service against or with Introspection . . 40 - 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 - 8.1. Authorization Server Information . . . . . . . . . . . . 41 - 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 42 - 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 42 - 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 43 - 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 43 - 8.6. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 43 - 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 44 - 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 44 - 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 45 - 8.9. Token Endpoint CBOR Mappings Registry . . . . . . . . . . 45 - 8.10. OAuth Introspection Response Parameter Registration . . . 46 - 8.11. Introspection Endpoint CBOR Mappings Registry . . . . . . 46 - 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 47 - 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 47 - 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 48 - 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 49 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 - 10.2. Informative References . . . . . . . . . . . . . . . . . 52 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 54 - Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 58 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 60 - Appendix D. Assumptions on AS knowledge about C and RS . . . . . 60 - Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 61 - E.1. Local Token Validation . . . . . . . . . . . . . . . . . 61 - E.2. Introspection Aided Token Validation . . . . . . . . . . 65 - Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 69 - F.1. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 69 - F.2. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 69 - F.3. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 70 - F.4. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 70 - F.5. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 70 - F.6. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 70 - F.7. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 70 - F.8. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 71 - F.9. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 71 - F.10. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 71 - F.11. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 71 - F.12. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 72 - F.13. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 72 - F.14. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 72 - F.15. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 72 - F.16. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 73 - F.17. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 73 - F.18. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 73 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 + 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 23 + 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 25 + 5.6.4. Request and Response Parameters . . . . . . . . . . . 26 + 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 26 + 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 27 + 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 27 + 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 28 + 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 28 + 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 29 + 5.7.2. Introspection Response . . . . . . . . . . . . . . . 30 + 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 31 + 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 32 + 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 32 + 5.8.1. The Authorization Information Endpoint . . . . . . . 33 + 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 34 + 5.8.1.2. Protecting the Authorization Information + Endpoint . . . . . . . . . . . . . . . . . . . . 36 + 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 36 + 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 37 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 39 + 6.2. Minimal security requirements for communication . 39 + 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 40 + 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 40 + 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 40 + 6.6. Denial of service against or with Introspection . . 41 + 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 + 8.1. ACE Authorization Server Request Creation Hints . . . . . 42 + 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 43 + 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 43 + 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 44 + 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 44 + 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 44 + 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 45 + 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 45 + 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 46 + 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 46 + 8.10. OAuth Introspection Response Parameter Registration . . . 47 + 8.11. OAuth Token Introspection Response CBOR Mappings Registry 47 + 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 48 + 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 48 + 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 49 + 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 50 + 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 50 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 + 10.2. Informative References . . . . . . . . . . . . . . . . . 53 + Appendix A. Design Justification . . . . . . . . . . . . . . . . 56 + Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 59 + Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 62 + Appendix D. Assumptions on AS knowledge about C and RS . . . . . 62 + Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 63 + E.1. Local Token Validation . . . . . . . . . . . . . . . . . 63 + E.2. Introspection Aided Token Validation . . . . . . . . . . 67 + Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 71 + F.1. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 71 + F.2. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 71 + F.3. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 72 + F.4. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 72 + F.5. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 72 + F.6. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 72 + F.7. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 73 + F.8. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 73 + F.9. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 73 + F.10. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 73 + F.11. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 73 + F.12. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 74 + F.13. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 74 + F.14. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 74 + F.15. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 74 + F.16. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 75 + F.17. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 75 + F.18. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 75 + F.19. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 76 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 1. Introduction Authorization is the process for granting approval to an entity to access a 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. @@ -225,20 +227,24 @@ The specifications in this document is called the "framework" or "ACE framework". When referring to "profiles of this framework" it refers to additional specifications that define the use of this specification with concrete transport, and communication security protocols (e.g., CoAP over DTLS). We use the term "Access Information" for parameters other than the access token provided to the client by the AS to enable it to access the RS (e.g. public key of the RS, profile supported by RS). + We use the term "Authorization Information" to denote all + information, including the claims of relevant access tokens, that an + RS uses to determine whether an access request should be granted. + 3. Overview This specification defines the ACE framework for authorization in the Internet of Things environment. It consists of a set of building blocks. The basic block is the OAuth 2.0 [RFC6749] framework, which enjoys widespread deployment. Many IoT devices can support OAuth 2.0 without any additional extensions, but for certain constrained settings additional profiling is needed. @@ -253,21 +259,21 @@ A third building block is CBOR [RFC7049], for encodings where JSON [RFC8259] is not sufficiently compact. CBOR is a binary encoding designed for small code and message size, which may be used for encoding of self contained tokens, and also for encoding payload transferred in protocol messages. A fourth building block is the compact CBOR-based secure message format COSE [RFC8152], which enables application layer security as an alternative or complement to transport layer security (DTLS [RFC6347] - or TLS [RFC5246]). COSE is used to secure self-contained tokens such + or TLS [RFC8446]). COSE is used to secure self-contained tokens such as proof-of-possession (PoP) tokens, which is an extension to the OAuth 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 [I-D.ietf-core-object-security]. With the building blocks listed above, solutions satisfying various IoT device and network constraints are possible. A list of constraints is described in detail in RFC 7228 [RFC7228] and a description of how the building blocks mentioned above relate to the various constraints can be found in Appendix A. @@ -326,21 +332,24 @@ the resource owner). Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (B) in Figure 1). A refresh token in OAuth 2.0 is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with - authorization servers and are never sent to resource servers. + authorization servers and are never sent to resource servers. In + this framework, refresh tokens are encoded in binary instead of + strings, if used. + Proof of Possession Tokens: An access token may be bound to a cryptographic key, which is then used by an RS to authenticate requests from a client. Such tokens are called proof-of-possession access tokens (or PoP access tokens). The proof-of-possession (PoP) security concept assumes that the AS acts as a trusted third party that binds keys to access tokens. These so called PoP keys are then used by the client to demonstrate the possession of the secret to the RS when accessing @@ -430,23 +440,23 @@ While HTTP uses headers and query strings to convey additional information about a request, CoAP encodes such information into header parameters called 'options'. CoAP supports application-layer fragmentation of the CoAP payloads through blockwise transfers [RFC7959]. However, blockwise transfer does not increase the size limits of CoAP options, therefore data encoded in options has to be kept small. Transport layer security for CoAP can be provided by DTLS or TLS - [RFC6347][RFC5246][RFC8446] [I-D.ietf-tls-dtls13]. CoAP defines a - number of proxy operations that require transport layer security to - be terminated at the proxy. One approach for protecting CoAP + [RFC6347][RFC8446] [I-D.ietf-tls-dtls13]. CoAP defines a number of + proxy operations that require transport layer security to be + terminated at the proxy. One approach for protecting CoAP communication end-to-end through proxies, and also to support security for CoAP over a different transport in a uniform way, is to provide security at the application layer using an object-based security mechanism such as COSE [RFC8152]. One application of COSE is OSCORE [I-D.ietf-core-object-security], which provides end-to-end confidentiality, integrity and replay protection, and a secure binding between CoAP request and response messages. In OSCORE, the CoAP messages are wrapped in COSE objects and sent using CoAP. @@ -713,87 +722,107 @@ resource. Note: These conditions ensure that RS can handle requests autonomously once access was granted and a secure channel has been established between C and RS. The authz-info endpoint MUST NOT be protected as specified above, in order to allow clients to upload access tokens to RS (cf. Section 5.8.1). Unauthorized Resource Request messages MUST be denied with a client error response. In this response, the Resource Server SHOULD provide - proper AS Information to enable the Client to request an access token - from RS's AS as described in Section 5.1.2. + proper AS Request Creation Hints to enable the Client to request an + access token from RS's AS as described in Section 5.1.2. The handling of all client requests (including unauthorized ones) by the RS is described in Section 5.8.2. -5.1.2. AS Information +5.1.2. AS Request Creation Hints - The AS Information is sent by RS as a response to an Unauthorized - Resource Request message (see Section 5.1.1) to point the sender of - the Unauthorized Resource Request message to RS's AS. The AS - information is a set of attributes containing an absolute URI (see - Section 4.3 of [RFC3986]) that specifies the AS in charge of RS. + The AS Request Creation Hints message is sent by RS as a response to + an Unauthorized Resource Request message (see Section 5.1.1) to help + the sender of the Unauthorized Resource Request message in acquiring + a valid access token. The AS Request Creation Hints message is CBOR + map, with a MANDATORY element "AS" specifying an absolute URI (see + Section 4.3 of [RFC3986]) that identifies the AS in charge of RS. - The message MAY also contain a nonce generated by RS to ensure - freshness in case that the RS and AS do not have synchronized clocks. + The message can also contain the following OPTIONAL parameters: - Figure 2 summarizes the parameters that may be part of the AS - Information. + o A "req_aud" element containing a suggested audience that the + client should request towards the AS. + o A "kid" element containing the key identifier of a key used in an + existing security association between the client and the RS. The + RS expects the client to request an access token bound to this + key, in order to avoid having to re-establish the security + association. + o A "nonce" element containing a nonce generated by RS to ensure + freshness in case that the RS and AS do not have synchronized + clocks. + o A "scope" element containing the suggested scope that the client + should request towards the AS. - /-------+----------+-------------\ + Figure 2 summarizes the parameters that may be part of the AS Request + Creation Hints. + + /-----------+----------+---------------------\ | Name | CBOR Key | Value Type | - |-------+----------+-------------| + |-----------+----------+---------------------| | AS | 0 | text string | + | req_aud | 3 | text string | + | kid | 4 | byte string | | nonce | 5 | byte string | - \-------+----------+-------------/ + | scope | 9 | text or byte string | + \-----------+----------+---------------------/ - Figure 2: AS Information parameters + Figure 2: AS Request Creation Hints Note that the schema part of the AS parameter may need to be adapted to the security protocol that is used between the client and the AS. Thus the example AS value "coap://as.example.com/token" might need to be transformed to "coaps://as.example.com/token". It is assumed that the client can determine the correct schema part on its own depending on the way it communicates with the AS. - Figure 3 shows an example for an AS Information message payload using - CBOR [RFC7049] diagnostic notation, using the parameter names instead - of the CBOR keys for better human readability. + Figure 3 shows an example for an AS Request Creation Hints message + payload using CBOR [RFC7049] diagnostic notation, using the parameter + names instead of the CBOR keys for better human readability. 4.01 Unauthorized Content-Format: application/ace+cbor {AS: "coaps://as.example.com/token", - nonce: h'e0a156bb3f'} + req_aud: "coaps://rs.example.com", + nonce: h'e0a156bb3f', + scope: "rTempC" + } - Figure 3: AS Information payload example + Figure 3: AS Request Creation Hints payload example In this example, the attribute AS points the receiver of this message to the URI "coaps://as.example.com/token" to request access - permissions. The originator of the AS Information payload (i.e., RS) - uses a local clock that is loosely synchronized with a time scale - common between RS and AS (e.g., wall clock time). Therefore, it has - included a parameter "nonce" for replay attack prevention. + permissions. The originator of the AS Request Creation Hints payload + (i.e., RS) uses a local clock that is loosely synchronized with a + time scale common between RS and AS (e.g., wall clock time). + Therefore, it has included a parameter "nonce" for replay attack + prevention. Figure 4 illustrates the mandatory to use binary encoding of the message payload shown in Figure 3. a2 # map(2) 00 # unsigned(0) (=AS) 78 1c # text(28) 636f6170733a2f2f61732e657861 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 05 # unsigned(5) (=nonce) 45 # bytes(5) e0a156bb3f - Figure 4: AS Information example encoded in CBOR + Figure 4: AS Request Creation Hints example encoded in CBOR 5.2. Authorization Grants To request an access token, the client obtains authorization from the resource owner or uses its client credentials as grant. The authorization is expressed in the form of an authorization grant. The OAuth framework [RFC6749] defines four grant types. The grant types can be split up into two groups, those granted on behalf of the resource owner (password, authorization code, implicit) and those for @@ -943,21 +972,21 @@ the audience is implicitly known by both client and AS. Furthermore note that this example uses the "req_cnf" parameter from [I-D.ietf-ace-oauth-params]. Header: POST (Code=0.02) Uri-Host: "as.example.com" Uri-Path: "token" OSCORE: 0x19, 0x05, 0x05, 0x44, 0x61, 0x6c, 0x65, 0x6b Content-Format: "application/oscore" Payload: - 0x44025d1 ... (full payload ommitted for brevity) ... 68b3825e + 0x44025d1 ... (full payload omitted for brevity) ... 68b3825e ) Decrypted payload: { "grant_type" : "client_credentials", "client_id" : "myclient", "req_cnf" : { "COSE_Key" : { "kty" : "EC", "kid" : h'11', @@ -1559,38 +1588,37 @@ Note that the Subject (sub) claim cannot always be verified when the token is submitted to the RS since the client may not have authenticated yet. Also note that a counter for the expires_in (exi) claim MUST be initialized when the RS first verifies this token. When sending error responses, the RS MAY use the error codes from Section 3.1 of [RFC6750], to provide additional details to the client. -5.8.1.2. Protecting the Authzorization Information Endpoint +5.8.1.2. Protecting the Authorization Information Endpoint As this framework can be used in RESTful environments, it is important to make sure that attackers cannot perform unauthorized requests on the auth-info endpoints, other than submitting access tokens. Specifically it SHOULD NOT be possible to perform GET, DELETE or PUT on the authz-info endpoint and on it's children (if any). The POST method SHOULD NOT be allowed on children of the authz-info endpoint. The RS SHOULD implement rate limiting measures to mitigate attacks aiming to overload the processing capacity of the RS by repeatedly submitting tokens. For CoAP-based communication the RS could use the - mechanisms from [I-D.ietf-core-too-many-reqs] to indicate that it is - overloaded. + mechanisms from [RFC8516] to indicate that it is overloaded. 5.8.2. Client Requests to the RS If an RS receives a request from a client, and the target resource requires authorization, the RS MUST first verify that it has an access token that authorizes this request, and that the client has performed the proof-of-possession for that token. The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access @@ -1669,20 +1697,27 @@ digest (MAC) or an Authenticated Encryption with Associated Data (AEAD) algorithm. Consequently, the token integrity protection MUST be applied to prevent the token from being modified, particularly since it contains a reference to the symmetric key or the asymmetric key. If the access token contains the symmetric key, this symmetric key MUST be encrypted by the authorization server so that only the resource server can decrypt it. Note that using an AEAD algorithm is preferable over using a MAC unless the message needs to be publicly readable. + If the token is intended for multiple recipients (i.e. an audience + that is a group), integrity protection of the token with a symmetric + key is not sufficient, since any of the recipients could modify the + token undetected by the other recipients. Therefore a token with a + multi-recipient audience MUST be protected with an asymmetric + signature. + It is important for the authorization server to include the identity of the intended recipient (the audience), typically a single resource server (or a list of resource servers), in the token. Using a single shared secret with multiple resource servers to simplify key management is NOT RECOMMENDED since the benefit from using the proof- of-possession concept is significantly reduced. The authorization server MUST offer confidentiality protection for any interactions with the client. This step is extremely important since the client may obtain the proof-of-possession key from the @@ -1706,29 +1741,29 @@ If clients are capable of doing so, they should frequently request fresh access tokens, as this allows the AS to keep the lifetime of the tokens short. This allows the AS to use shorter proof-of- possession key sizes, which translate to a performance benefit for the client and for the resource server. Shorter keys also lead to shorter messages (particularly with asymmetric keying material). When authorization servers bind symmetric keys to access tokens, they SHOULD scope these access tokens to a specific permission. -6.1. Unprotected AS Information +6.1. Unprotected AS Request Creation Hints Initially, no secure channel exists to protect the communication - between C and RS. Thus, C cannot determine if the AS information - contained in an unprotected response from RS to an unauthorized - request (see Section 5.1.2) is authentic. It is therefore advisable - to provide C with a (possibly hard-coded) list of trustworthy - authorization servers. AS information responses referring to a URI - not listed there would be ignored. + between C and RS. Thus, C cannot determine if the AS Request + Creation Hints contained in an unprotected response from RS to an + unauthorized request (see Section 5.1.2) are authentic. It is + therefore advisable to provide C with a (possibly hard-coded) list of + trustworthy authorization servers. AS Request Creation Hints + referring to a URI not listed there would be ignored. 6.2. Minimal security requirements for communication This section summarizes the minimal requirements for the communication security of the different protocol interactions. C-AS All communication between the client and the Authorization Server MUST be encrypted, integrity and replay protected. Furthermore responses from the AS to the client MUST be bound to the client's request to avoid attacks where the attacker swaps the @@ -1766,25 +1802,25 @@ or received a symmetric proof-of-possession key bound to the access token from the AS. The RS must have learned either the client's public key or a shared symmetric key from the claims in the token or an introspection request. Since ACE does not provide profile negotiation between C and RS, the client MUST have learned what profile the RS supports (e.g. from the AS or pre-configured) and initiate the communication accordingly. 6.3. Use of Nonces for Replay Protection - The RS may add a nonce to the AS Information message sent as a - response to an unauthorized request to ensure freshness of an Access - Token subsequently presented to RS. While a time-stamp of some - granularity would be sufficient to protect against replay attacks, - using randomized nonce is preferred to prevent disclosure of + The RS may add a nonce to the AS Request Creation Hints message sent + as a response to an unauthorized request to ensure freshness of an + Access Token subsequently presented to RS. While a time-stamp of + some granularity would be sufficient to protect against replay + attacks, using randomized nonce is preferred to prevent disclosure of information about RS's internal clock characteristics. 6.4. 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. Ideally, profiles should be designed in a way that the security of system should not depend on the specific security mechanisms used in individual protocol @@ -1822,29 +1858,29 @@ 6.6. Denial of service against or with Introspection The optional introspection mechanism provided by OAuth and supported in the ACE framework allows for two types of attacks that need to be considered by implementers. First an attacker could perform a denial of service attack against the introspection endpoint at the AS in order to prevent validation of access tokens. To mitigate this attack, an RS that is configured to use introspection MUST NOT allow access based on a token for which - it couln't reach the introspection endpoint. + it couldn't reach the introspection endpoint. Second an attacker could use the fact that an RS performs introspection to perform a denial of service attack against that RS by repeatedly sending tokens to its authz-info endpoint that require an introspection call. RS can mitigate such attacks by implementing a rate limit on how many introspection requests they perform in a - given time intervall and rejecting incoming requests to authz-info - for a certain amount of time, when that rate limit has been reached. + given time interval and rejecting incoming requests to authz-info for + a certain amount of time, when that rate limit has been reached. 7. Privacy Considerations Implementers and users should be aware of the privacy implications of the different possible deployments of this framework. The AS is in a very central position and can potentially learn sensitive information about the clients requesting access tokens. If the client credentials grant is used, the AS can track what kind of access the client intends to perform. With other grants this can be @@ -1872,28 +1908,28 @@ Section 5.1.2) may disclose information about RS and/or its existing relationship with C. It is advisable to include as little information as possible in an unencrypted response. Means of encrypting communication between C and RS already exist, more detailed information may be included with an error response to provide C with sufficient information to react on that particular error. 8. IANA Considerations -8.1. Authorization Server Information +8.1. ACE Authorization Server Request Creation Hints This specification establishes the IANA "ACE Authorization Server - Information" registry. The registry has been created to use the - "Expert Review Required" registration procedure [RFC8126]. It should - be noted that, in addition to the expert review, some portions of the - registry require a specification, potentially a Standards Track RFC, - be supplied as well. + Request Creation Hints" registry. The registry has been created to + use the "Expert Review Required" registration procedure [RFC8126]. + It should be noted that, in addition to the expert review, some + portions of the registry require a specification, potentially a + Standards Track RFC, be supplied as well. The columns of the registry are: Name The name of the parameter CBOR Key CBOR map key for the parameter. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are @@ -1980,28 +2016,28 @@ 8.5. OAuth Access Token Types This section registers the following new token type in the "OAuth Access Token Types" registry [IANA.OAuthAccessTokenTypes]. o Name: "PoP" o Change Controller: IETF o Reference: [this document] -8.6. OAuth Token Type CBOR Mappings +8.6. OAuth Access Token Type CBOR Mappings - This specification established the IANA "Token Type CBOR Mappings" - registry. The registry has been created to use the "Expert Review - Required" registration procedure [RFC8126]. It should be noted that, - in addition to the expert review, some portions of the registry - require a specification, potentially a Standards Track RFC, be - supplied as well. + This specification established the IANA "OAuth Access Token Type CBOR + Mappings" registry. The registry has been created to use the "Expert + Review Required" registration procedure [RFC8126]. It should be + noted that, in addition to the expert review, some portions of the + registry require a specification, potentially a Standards Track RFC, + be supplied as well. The columns of this registry are: Name The name of token type as registered in the OAuth Access Token Types registry, e.g., "Bearer". CBOR Value CBOR abbreviation for this token type. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than @@ -2032,44 +2068,47 @@ addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this registry are: Name The name of the profile, to be used as value of the profile attribute. Description Text giving an overview of the profile and the context it is developed for. + CBOR Value CBOR abbreviation for this profile name. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. - Reference This contains a pointer to the public specification of the profile abbreviation, if one exists. + This registry will be initially empty and will be populated by the + registrations from the ACE framework profiles. + 8.8. OAuth Parameter Registration This specification registers the following parameter in the "OAuth Parameters" registry [IANA.OAuthParameters]: o Name: "profile" o Parameter Usage Location: token response o Change Controller: IESG o Reference: Section 5.6.4.3 of [this document] -8.9. Token Endpoint CBOR Mappings Registry +8.9. OAuth Parameters CBOR Mappings Registry - This specification establishes the IANA "Token Endpoint CBOR + This specification establishes the IANA "OAuth Parameters CBOR Mappings" registry. The registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this registry are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., "client_id". @@ -2097,28 +2136,28 @@ This specification registers the following parameter in the OAuth Token Introspection Response registry [IANA.TokenIntrospectionResponse]. o Name: "profile" o Description: The communication and communication security profile used between client and RS, as defined in ACE profiles. o Change Controller: IESG o Reference: Section 5.7.2 of [this document] -8.11. Introspection Endpoint CBOR Mappings Registry +8.11. OAuth Token Introspection Response CBOR Mappings Registry - This specification establishes the IANA "Introspection Endpoint CBOR - Mappings" registry. The registry has been created to use the "Expert - Review Required" registration procedure [RFC8126]. It should be - noted that, in addition to the expert review, some portions of the - registry require a specification, potentially a Standards Track RFC, - be supplied as well. + This specification establishes the IANA "OAuth Token Introspection + Response CBOR Mappings" registry. The registry has been created to + use the "Expert Review Required" registration procedure [RFC8126]. + It should be noted that, in addition to the expert review, some + portions of the registry require a specification, potentially a + Standards Track RFC, be supplied as well. The columns of this registry are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., "client_id". CBOR Key CBOR map key for this parameter. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than @@ -2163,38 +2202,39 @@ o Reference: Section 5.8.3 of [this document] 8.13. CBOR Web Token Claims This specification registers the following new claims in the "CBOR Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. o Claim Name: "scope" o Claim Description: The scope of an access token as defined in [RFC6749]. - o JWT Claim Name: N/A + o JWT Claim Name: scope o Claim Key: TBD (suggested: 9) o Claim Value Type(s): byte string or text string o Change Controller: IESG o Specification Document(s): Section 5.8 of [this document] o Claim Name: "profile" o Claim Description: The profile a token is supposed to be used with. - o JWT Claim Name: N/A + o JWT Claim Name: profile o Claim Key: TBD (suggested: 39) o Claim Value Type(s): integer o Change Controller: IESG o Specification Document(s): Section 5.8 of [this document] + o Claim Name: "exi" o Claim Description: The expiration time of a token measured from when it was received at the RS in seconds. - o JWT Claim Name: N/A + o JWT Claim Name: exi o Claim Key: TBD (suggested: 41) o Claim Value Type(s): integer o Change Controller: IESG o Specification Document(s): Section 5.8 of [this document] 8.14. Media Type Registrations This specification registers the 'application/ace+cbor' media type for messages of the protocols defined in this document carrying parameters encoded in CBOR. This registration follows the procedures @@ -2245,20 +2285,60 @@ Content-Formats" registry: Media Type: application/ace+cbor Encoding ID: 19 Reference: [this document] +8.16. Expert Review Instructions + + All of the IANA registries established in this document are defined + as expert review. This section gives some general guidelines for + what the experts should be looking for, but they are being designated + as experts for a reason, so they should be given substantial + latitude. + + Expert reviewers should take into consideration the following points: + + o Point squatting should be discouraged. Reviewers are encouraged + to get sufficient information for registration requests to ensure + that the usage is not going to duplicate one that is already + registered, and that the point is likely to be used in + deployments. The zones tagged as private use are intended for + testing purposes and closed environments; code points in other + ranges should not be assigned for testing. + o Specifications are required for the standards track range of point + assignment. Specifications should exist for specification + required ranges, but early assignment before a specification is + available is considered to be permissible. Specifications are + needed for the first-come, first-serve range if they are expected + to be used outside of closed environments in an interoperable way. + When specifications are not provided, the description provided + needs to have sufficient information to identify what the point is + being used for. + o Experts should take into account the expected usage of fields when + approving point assignment. The fact that there is a range for + standards track documents does not mean that a standards track + document cannot have points assigned outside of that range. The + length of the encoded value should be weighed against how many + code points of that length are left, the size of device it will be + used on, and the number of code points left that encode to that + size. + o Since a high degree of overlap is expected between these + registries and the contents of the OAuth parameters + [IANA.OAuthParameters] registries, experts should require new + registrations to maintain a reasonable level of alignment with + parameters from OAuth that have comparable functionality. + 9. Acknowledgments This document is a product of the ACE working group of the IETF. Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and UMA in IoT scenarios, Robert Taylor for his discussion input, and Malisa Vucinic for his input on the predecessors of this proposal. Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from where large parts of the security considerations where copied. @@ -2281,21 +2361,21 @@ [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- possession-05 (work in progress), November 2018. [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", draft-ietf-ace-oauth- - params-01 (work in progress), November 2018. + params-03 (work in progress), January 2019. [IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", . [IANA.JsonWebTokenClaims] IANA, "JSON Web Token Claims", . @@ -2374,54 +2454,44 @@ Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Key as OAuth client credentials", draft-erdtman-ace- rpcc-02 (work in progress), October 2017. [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", draft-ietf-core-object-security-15 (work in progress), August 2018. - [I-D.ietf-core-too-many-reqs] - Keranen, A., "Too Many Requests Response Code for the - Constrained Application Protocol", draft-ietf-core-too- - many-reqs-06 (work in progress), November 2018. - [I-D.ietf-oauth-device-flow] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Flow for Browserless and Input - Constrained Devices", draft-ietf-oauth-device-flow-13 - (work in progress), October 2018. + Constrained Devices", draft-ietf-oauth-device-flow-14 + (work in progress), January 2019. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-30 (work in progress), November 2018. [Margi10impact] Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, "Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds", Proceedings of the 19th International Conference on Computer Communications and Networks (ICCCN), 2010 August. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . - [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, - DOI 10.17487/RFC5246, August 2008, . - [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object @@ -2479,20 +2549,25 @@ [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . + [RFC8516] Keranen, A., ""Too Many Requests" + Response Code for the Constrained Application Protocol", + RFC 8516, DOI 10.17487/RFC8516, January 2019, + . + Appendix A. Design Justification This section provides further insight into the design decisions of the solution documented in this document. Section 3 lists several building blocks and briefly summarizes their importance. The justification for offering some of those building blocks, as opposed to using OAuth 2.0 as is, is given below. Common IoT constraints are: @@ -3184,29 +3258,46 @@ F: |<--------+ Header: 2.04 Changed | 2.04 | Payload: | | Figure 26: Resource request and response protected by OSCORE Appendix F. Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION. -F.1. Version -17 to -18 +F.1. Version -18 to -19 + + o Added definition of "Authorization Information". + o Explicitly state that ACE allows encoding refresh tokens in binary + format in addition to strings. + o Renamed "AS Information" to "AS Request Creation Hints" and added + the possibility to specify req_aud and scope as hints. + o Added the "kid" parameter to AS Request Creation Hints. + o Added security considerations about the integrity protection of + tokens with multi-RS audiences. + o Renamed IANA registries mapping OAuth parameters to reflect the + mapped registry. + o Added JWT claim names to CWT claim registrations. + o Added expert review instructions. + o Updated references to TLS from 1.2 to 1.3. + +F.2. Version -17 to -18 o Added OSCORE options in examples involving OSCORE. o Removed requirement for the client to send application/cwt, since the client has no way to know. + o Clarified verification of tokens by the RS. o Added exi claim CWT registration. -F.2. Version -16 to -17 +F.3. Version -16 to -17 o Added references to (D)TLS 1.3. o Added requirement that responses are bound to requests. o Specify that grant_type is OPTIONAL in C2AS requests (as opposed to REQUIRED in OAuth). o Replaced examples with hypothetical COSE profile with OSCORE. o Added requirement for content type application/ace+cbor in error responses for token and introspection requests and responses. o Reworked abbreviation space for claims, request and response parameters. @@ -3205,101 +3296,99 @@ o Added requirement that responses are bound to requests. o Specify that grant_type is OPTIONAL in C2AS requests (as opposed to REQUIRED in OAuth). o Replaced examples with hypothetical COSE profile with OSCORE. o Added requirement for content type application/ace+cbor in error responses for token and introspection requests and responses. o Reworked abbreviation space for claims, request and response parameters. o Added text that the RS may indicate that it is busy at the authz- info resource. - o Added section that specifies how the RS verifies an access token. o Added section on the protection of the authz-info endpoint. o Removed the expiration mechanism based on sequence numbers. o Added reference to RFC7662 security considerations. o Added considerations on minimal security requirements for communication. o Added security considerations on unprotected information sent to authz-info and in the error responses. -F.3. Version -15 to -16 +F.4. Version -15 to -16 o Added text the RS using RFC6750 error codes. o Defined an error code for incompatible token request parameters. o Removed references to the actors draft. o Fixed errors in examples. -F.4. Version -14 to -15 +F.5. Version -14 to -15 o Added text about refresh tokens. o Added text about protection of credentials. o Rephrased introspection so that other entities than RS can do it. o Editorial improvements. -F.5. Version -13 to -14 +F.6. Version -13 to -14 o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to [I-D.ietf-ace-oauth-params] o Introduced the "application/ace+cbor" Content-Type. o Added claim registrations from 'profile' and 'rs_cnf'. o Added note on schema part of AS Information Section 5.1.2 o Realigned the parameter abbreviations to push rarely used ones to the 2-byte encoding size of CBOR integers. -F.6. Version -12 to -13 +F.7. Version -12 to -13 o Changed "Resource Information" to "Access Information" to avoid confusion. o Clarified section about AS discovery. o Editorial changes -F.7. Version -11 to -12 +F.8. Version -11 to -12 o Moved the Request error handling to a section of its own. o Require the use of the abbreviation for profile identifiers. o Added rs_cnf parameter in the introspection response, to inform RS' with several RPKs on which key to use. o Allowed use of rs_cnf as claim in the access token in order to inform an RS with several RPKs on which key to use. - o Clarified that profiles must specify if/how error responses are protected. o Fixed label number range to align with COSE/CWT. o Clarified the requirements language in order to allow profiles to specify other payload formats than CBOR if they do not use CoAP. -F.8. Version -10 to -11 +F.9. Version -10 to -11 o Fixed some CBOR data type errors. o Updated boilerplate text -F.9. Version -09 to -10 +F.10. Version -09 to -10 o Removed CBOR major type numbers. o Removed the client token design. o Rephrased to clarify that other protocols than CoAP can be used. o Clarifications regarding the use of HTTP -F.10. Version -08 to -09 +F.11. Version -08 to -09 o Allowed scope to be byte strings. o Defined default names for endpoints. o Refactored the IANA section for briefness and consistency. o Refactored tables that define IANA registry contents for consistency. o Created IANA registry for CBOR mappings of error codes, grant types and Authorization Server Information. o Added references to other document sections defining IANA entries in the IANA section. -F.11. Version -07 to -08 +F.12. Version -07 to -08 o Moved AS discovery from the DTLS profile to the framework, see Section 5.1. o Made the use of CBOR mandatory. If you use JSON you can use vanilla OAuth. o Made it mandatory for profiles to specify C-AS security and RS-AS security (the latter only if introspection is supported). o Made the use of CBOR abbreviations mandatory. o Added text to clarify the use of token references as an alternative to CWTs. @@ -3314,39 +3402,40 @@ o Added text that clarifies that introspection is optional. o Made profile parameter optional since it can be implicit. o Clarified that CoAP is not mandatory and other protocols can be used. o Clarified the design justification for specific features of the framework in appendix A. o Clarified appendix E.2. o Removed specification of the "cnf" claim for CBOR/COSE, and replaced with references to [I-D.ietf-ace-cwt-proof-of-possession] -F.12. Version -06 to -07 +F.13. Version -06 to -07 o Various clarifications added. o Fixed erroneous author email. -F.13. Version -05 to -06 +F.14. Version -05 to -06 o Moved sections that define the ACE framework into a subsection of the framework Section 5. o Split section on client credentials and grant into two separate sections, Section 5.2, and Section 5.3. o Added Section 5.4 on AS authentication. o Added Section 5.5 on the Authorization endpoint. -F.14. Version -04 to -05 +F.15. Version -04 to -05 o Added RFC 2119 language to the specification of the required behavior of profile specifications. o Added Section 5.3 on the relation to the OAuth2 grant types. + o Added CBOR abbreviations for error and the error codes defined in OAuth2. o Added clarification about token expiration and long-running requests in Section 5.8.3 o Added security considerations about tokens with symmetric pop keys valid for more than one RS. o Added privacy considerations section. o Added IANA registry mapping the confirmation types from RFC 7800 to equivalent COSE types. o Added appendix D, describing assumptions about what the AS knows @@ -3345,63 +3434,64 @@ o Added clarification about token expiration and long-running requests in Section 5.8.3 o Added security considerations about tokens with symmetric pop keys valid for more than one RS. o Added privacy considerations section. o Added IANA registry mapping the confirmation types from RFC 7800 to equivalent COSE types. o Added appendix D, describing assumptions about what the AS knows about the client and the RS. -F.15. Version -03 to -04 +F.16. Version -03 to -04 o Added a description of the terms "framework" and "profiles" as used in this document. o Clarified protection of access tokens in section 3.1. o Clarified uses of the "cnf" parameter in section 6.4.5. o Clarified intended use of Client Token in section 7.4. -F.16. Version -02 to -03 +F.17. Version -02 to -03 o Removed references to draft-ietf-oauth-pop-key-distribution since the status of this draft is unclear. o Copied and adapted security considerations from draft-ietf-oauth- pop-key-distribution. o Renamed "client information" to "RS information" since it is information about the RS. o Clarified the requirements on profiles of this framework. o Clarified the token endpoint protocol and removed negotiation of "profile" and "alg" (section 6). o Renumbered the abbreviations for claims and parameters to get a consistent numbering across different endpoints. o Clarified the introspection endpoint. o Renamed token, introspection and authz-info to "endpoint" instead of "resource" to mirror the OAuth 2.0 terminology. o Updated the examples in the appendices. -F.17. Version -01 to -02 +F.18. Version -01 to -02 o Restructured to remove communication security parts. These shall now be defined in profiles. o Restructured section 5 to create new sections on the OAuth endpoints token, introspection and authz-info. o Pulled in material from draft-ietf-oauth-pop-key-distribution in order to define proof-of-possession key distribution. o Introduced the "cnf" parameter as defined in RFC7800 to reference or transport keys used for proof of possession. + o Introduced the "client-token" to transport client information from the AS to the client via the RS in conjunction with introspection. o Expanded the IANA section to define parameters for token request, introspection and CWT claims. o Moved deployment scenarios to the appendix as examples. -F.18. Version -00 to -01 +F.19. Version -00 to -01 o Changed 5.1. from "Communication Security Protocol" to "Client Information". o Major rewrite of 5.1 to clarify the information exchanged between C and AS in the PoP access token request profile for IoT. * Allow the client to indicate preferences for the communication security protocol. * Defined the term "Client Information" for the additional information returned to the client in addition to the access