--- 1/draft-ietf-ace-oauth-authz-15.txt 2018-10-02 02:13:08.995538423 -0700 +++ 2/draft-ietf-ace-oauth-authz-16.txt 2018-10-02 02:13:09.127541617 -0700 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft RISE Intended status: Standards Track G. Selander -Expires: March 31, 2019 Ericsson +Expires: April 5, 2019 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - September 27, 2018 + October 2, 2018 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-15 + draft-ietf-ace-oauth-authz-16 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 March 31, 2019. + This Internet-Draft will expire on April 5, 2019. Copyright Notice Copyright (c) 2018 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 @@ -57,98 +57,100 @@ include Simplified BSD License text as described in Section 4.e of 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 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.5. The Authorization Endpoint . . . . . . . . . . . . . . . 18 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 28 - 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 29 + 5.7.2. Introspection Response . . . . . . . . . . . . . . . 29 + 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 30 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31 - 5.8.1. The Authorization Information Endpoint . . . . . . . 31 - 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 32 + 5.8.1. The Authorization Information Endpoint . . . . . . . 32 + 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 33 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6.1. Unprotected AS Information . . . . . . . . . . . . . . . 35 - 6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 35 - 6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 35 + 6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 36 + 6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 36 6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 36 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8.1. Authorization Server Information . . . . . . . . . . . . 37 - 8.2. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 37 - 8.3. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 38 - 8.4. OAuth Access Token Types . . . . . . . . . . . . . . . . 38 - 8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 39 - 8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39 - 8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 39 - 8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 40 - 8.8. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 40 - 8.9. OAuth Introspection Response Parameter Registration . . . 41 - 8.10. Introspection Endpoint CBOR Mappings Registry . . . . . . 41 - 8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42 - 8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42 - 8.13. Media Type Registrations . . . . . . . . . . . . . . . . 43 - 8.14. CoAP Content-Format Registry . . . . . . . . . . . . . . 44 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 - 10.2. Informative References . . . . . . . . . . . . . . . . . 46 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 49 - Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 52 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 54 - Appendix D. Assumptions on AS knowledge about C and RS . . . . . 55 - Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 55 - E.1. Local Token Validation . . . . . . . . . . . . . . . . . 56 - E.2. Introspection Aided Token Validation . . . . . . . . . . 60 - Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 64 - F.1. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 64 - F.2. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 64 - F.3. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 65 - F.4. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 65 - F.5. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 65 - F.6. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 65 - F.7. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 65 - F.8. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 66 - F.9. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 66 - F.10. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 66 - F.11. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 66 - F.12. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 67 - F.13. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 67 - F.14. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 67 - F.15. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 68 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 + 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 38 + 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 38 + 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 39 + 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 39 + 8.6. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 39 + 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 40 + 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 40 + 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 41 + 8.9. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 41 + 8.10. OAuth Introspection Response Parameter Registration . . . 42 + 8.11. Introspection Endpoint CBOR Mappings Registry . . . . . . 42 + 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42 + 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 43 + 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 44 + 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 45 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 + 10.2. Informative References . . . . . . . . . . . . . . . . . 47 + Appendix A. Design Justification . . . . . . . . . . . . . . . . 50 + Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 53 + Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 55 + Appendix D. Assumptions on AS knowledge about C and RS . . . . . 56 + Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 56 + E.1. Local Token Validation . . . . . . . . . . . . . . . . . 57 + E.2. Introspection Aided Token Validation . . . . . . . . . . 61 + Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 65 + F.1. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 65 + F.2. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 65 + F.3. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 65 + F.4. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 66 + F.5. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 66 + F.6. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 66 + F.7. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 66 + F.8. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 66 + F.9. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 67 + F.10. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 67 + F.11. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 67 + F.12. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 67 + F.13. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 68 + F.14. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 68 + F.15. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 68 + F.16. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 69 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 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. @@ -196,36 +198,30 @@ capitals, as shown here. Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from [RFC4949]. Since exchanges in this specification are described as RESTful protocol interactions, HTTP [RFC7231] offers useful terminology. Terminology for entities in the architecture is defined in OAuth 2.0 - [RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource - server (RS), and authorization server (AS). + [RFC6749] such as client (C), resource server (RS), and authorization + server (AS). Note that the term "endpoint" is used here following its OAuth definition, which is to denote resources such as token and introspection at the AS and authz-info at the RS (see Section 5.8.1 for a definition of the authz-info endpoint). The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol" is not used in this specification. - Since this specification focuses on the problem of access control to - resources, the actors has been simplified by assuming that the client - authorization server (CAS) functionality is not stand-alone but - subsumed by either the authorization server or the client (see - Section 2.2 in [I-D.ietf-ace-actors]). - 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). @@ -665,21 +662,21 @@ endpoints at the AS is assumed to be via HTTP and may use Uri-query parameters. When profiles of this framework use CoAP instead, this framework REQUIRES the use of the following alternative instead of Uri-query parameters: The sender (client or RS) encodes the parameters of its request as a CBOR map and submits that map as the payload of the POST request. Profiles that use CBOR encoding of protocol message parameters MUST use the media format 'application/ ace+cbor', unless the protocol message is wrapped in another Content- Format (e.g. object security). If CoAP is used for communication, the Content-Format MUST be abbreviated with the ID: 19 (see - Section 8.14. + Section 8.15. The OAuth 2.0 AS uses a JSON structure in the payload of its responses both to client and RS. If CoAP is used, this framework REQUIRES the use of CBOR [RFC7049] instead of JSON. Depending on the profile, the CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper. 5.1. Discovering Authorization Servers In order to determine the AS in charge of a resource hosted at the @@ -881,23 +878,24 @@ integer abbreviations and the binary CBOR encoding, if the CBOR encoding is used. 5.6.1. Client-to-AS Request The client sends a POST request to the token endpoint at the AS. The profile MUST specify how the communication is protected. The content of the request consists of the parameters specified in Section 4 of the OAuth 2.0 specification [RFC6749]. - In addition to these parameters the parameters from - [I-D.ietf-ace-oauth-params] can be used for requesting an access - token from a token endpoint. + In addition to these parameters, a client MUST be able to use the + parameters from [I-D.ietf-ace-oauth-params] in an access token + request to the token endpoint and the AS MUST be able to process + these additional parameters. If CBOR is used then this parameter MUST be encoded as a CBOR map. The "scope" parameter can be formatted as specified in [RFC6749] and additionally as a byte array, in order to allow compact encoding of complex scopes. When HTTP is used as a transport then the client makes a request to the token endpoint by sending the parameters using the "application/ x-www-form-urlencoded" format with a character encoding of UTF-8 in the HTTP request entity-body, as defined in RFC 6749. @@ -910,48 +908,49 @@ notation, without abbreviations for better readability. Header: POST (Code=0.02) Uri-Host: "as.example.com" Uri-Path: "token" Content-Format: "application/ace+cbor" Payload: { "grant_type" : "client_credentials", "client_id" : "myclient", - "aud" : "tempSensor4711" + "req_aud" : "tempSensor4711" } Figure 5: Example request for an access token bound to a symmetric key. Figure 6 shows a request for a token with an asymmetric proof-of- possession key. Note that in this example COSE is used to provide object-security, therefore the Content-Format is "application/cose" - wrapping the "application/ace+cbor" type content. + wrapping the "application/ace+cbor" type content. Also note that in + this example the audience is implicitly known by both client and AS. Header: POST (Code=0.02) Uri-Host: "as.example.com" Uri-Path: "token" Content-Format: "application/cose" Payload: 16( # COSE_ENCRYPTED [ h'a1010a', # protected header: {"alg" : "AES-CCM-16-64-128"} {5 : b64'ifUvZaHFgJM7UmGnjA'}, # unprotected header, IV b64'WXThuZo6TMCaZZqi6ef/8WHTjOdGk8kNzaIhIQ' # ciphertext ] ) Decrypted payload: { "grant_type" : "client_credentials", "client_id" : "myclient", - "cnf" : { + "req_cnf" : { "COSE_Key" : { "kty" : "EC", "kid" : h'11', "crv" : "P-256", "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' } } } @@ -964,23 +963,23 @@ Header: POST (Code=0.02) Uri-Host: "as.example.com" Uri-Path: "token" Content-Format: "application/ace+cbor" Payload: { "grant_type" : "client_credentials", "client_id" : "myclient", "client_secret" : "mysecret234", - "aud" : "valve424", + "req_aud" : "valve424", "scope" : "read", - "cnf" : { + "req_cnf" : { "kid" : b64'6kg0dXJM13U' } } Figure 7: Example request for an access token bound to a key reference. Refresh tokens are typically not stored as securely as proof-of- possession keys in requesting clients. Proof-of-possession based refresh token requests MUST NOT request different proof-of-possession @@ -1015,22 +1014,23 @@ towards the RS. See Section 5.6.4.3 for the formatting of this parameter. If this parameter is absent, the AS assumes that the client implicitly knows which profile to use towards the RS. token_type: This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]. By default implementations of this framework SHOULD assume that the token_type is "pop". If a specific use case requires another token_type (e.g., "Bearer") to be used then this parameter is REQUIRED. - Furthermore [I-D.ietf-ace-oauth-params] defines further parameters - the AS can use when responding to a request to the token endpoint. + Furthermore [I-D.ietf-ace-oauth-params] defines additional parameters + that the AS MUST be able to use when responding to a request to the + token endpoint. Figure 8 summarizes the parameters that may be part of the Access Information. This does not include the additional parameters specified in [I-D.ietf-ace-oauth-params]. /-------------------+-------------------------------\ | Parameter name | Specified in | |-------------------+-------------------------------| | access_token | RFC 6749 | | token_type | RFC 6749 | @@ -1093,30 +1093,38 @@ /------------------------+-------------\ | Name | CBOR Values | |------------------------+-------------| | invalid_request | 1 | | invalid_client | 2 | | invalid_grant | 3 | | unauthorized_client | 4 | | unsupported_grant_type | 5 | | invalid_scope | 6 | | unsupported_pop_key | 7 | + | incompatible_profiles | 8 | \------------------------+-------------/ Figure 10: CBOR abbreviations for common error codes In addition to the error responses defined in OAuth 2.0, the - following behavior MUST be implemented by the AS: If the client - submits an asymmetric key in the token request that the RS cannot - process, the AS MUST reject that request with a response code - equivalent to the CoAP code 4.00 (Bad Request) including the error - code "unsupported_pop_key" defined in Figure 10. + following behavior MUST be implemented by the AS: + + o If the client submits an asymmetric key in the token request that + the RS cannot process, the AS MUST reject that request with a + response code equivalent to the CoAP code 4.00 (Bad Request) + including the error code "unsupported_pop_key" defined in + Figure 10. + o If the client and the RS it has requested an access token for do + not share a common profile, the AS MUST reject that request with a + response code equivalent to the CoAP code 4.00 (Bad Request) + including the error code "incompatible_profiles" defined in + Figure 10. 5.6.4. Request and Response Parameters This section provides more detail about the new parameters that can be used in access token requests and responses, as well as abbreviations for more compact encoding of existing parameters and common parameter values. 5.6.4.1. Grant Type @@ -1282,22 +1290,22 @@ In a successful response, the AS encodes the response parameters in a map including with the same required and optional parameters as in Section 2.2 of RFC 7662 [RFC7662] with the following addition: profile OPTIONAL. This indicates the profile that the RS MUST use with the client. See Section 5.6.4.3 for more details on the formatting of this parameter. Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that - the AS can use when responding to a request to the introspection - endpoint. + the AS MUST be able to use when responding to a request to the + introspection endpoint. For example, Figure 15 shows an AS response to the introspection request in Figure 13. Header: Created Code=2.01) Content-Format: "application/ace+cbor" Payload: { "active" : true, "scope" : "read", @@ -1430,20 +1438,23 @@ respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). If the token is valid but the audience of the token does not match the RS, the RS MUST respond with a response code equivalent to the CoAP code 4.03 (Forbidden). If the token is valid but is associated to claims that the RS cannot process (e.g., an unknown scope) the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request). In the latter case the RS MAY provide additional information in the error response, in order to clarify what went wrong. + The RS MAY use the error codes from section 3.1 of [RFC6750] when + giving error responses, in order to provide additional detail. + The RS MAY make an introspection request to validate the token before responding to the POST request to the authz-info endpoint. Profiles MUST specify whether the authz-info endpoint is protected, including whether error responses from this endpoint are protected. Note that since the token contains information that allow the client and the RS to establish a security context in the first place, mutual authentication may not be possible at this point. The default name of this endpoint in an url-path is '/authz-info', @@ -1516,22 +1527,21 @@ If a token that authorizes a long running request such as a CoAP Observe [RFC7641] expires, the RS MUST send an error response with the response code equivalent to the CoAP code 4.01 (Unauthorized) to the client and then terminate processing the long running request. 6. Security Considerations Security considerations applicable to authentication and authorization in RESTful environments provided in OAuth 2.0 [RFC6749] - apply to this work, as well as the security considerations from - [I-D.ietf-ace-actors]. Furthermore [RFC6819] provides additional + apply to this work. Furthermore [RFC6819] provides additional security considerations for OAuth which apply to IoT deployments as well. A large range of threats can be mitigated by protecting the contents of the access token by using a digital signature or a keyed message 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 @@ -1656,21 +1666,21 @@ 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 - This section establishes the IANA "ACE Authorization Server + 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. The columns of the registry are: Name The name of the parameter CBOR Key CBOR map key for the parameter. Different ranges of values @@ -1675,43 +1685,60 @@ 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 marked as Private Use. Value Type The CBOR data types allowable for the values of this parameter. + Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 2. The Reference column for all of these entries will be this document. -8.2. OAuth Error Code CBOR Mappings Registry +8.2. OAuth Extensions Error Registration - This section establish the IANA "OAuth Error Code 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 registers the follwoing error values in the OAuth + Extensions Error registry defined in [RFC6749]. + + o Error name: "unsupported_pop_key" + o Error usage location: AS token endpoint error response + o Related protocol extension: The ACE framework [this document] + o Change Controller: IESG + o Specification doucment(s): Section 5.6.3 of [this document] + + o Error name: "incompatible_profiles" + o Error usage location: AS token endpoint error response + o Related protocol extension: The ACE framework [this document] + o Change Controller: IESG + o Specification doucment(s): Section 5.6.3 of [this document] + +8.3. OAuth Error Code CBOR Mappings Registry + + This specification establishes the IANA "OAuth Error Code 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 the registry are: Name The OAuth Error Code name, refers to the name in Section 5.2. of [RFC6749], e.g., "invalid_request". CBOR Value CBOR abbreviation for this error code. 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 grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 10. The Reference column for all of these entries will be this document. @@ -1708,97 +1735,97 @@ 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 grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 10. The Reference column for all of these entries will be this document. -8.3. OAuth Grant Type CBOR Mappings +8.4. OAuth Grant Type CBOR Mappings - This section establishes the IANA "OAuth Grant 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 establishes the IANA "OAuth Grant 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 the grant type as specified in Section 1.3 of [RFC6749]. CBOR Value CBOR abbreviation for this grant 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 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 grant type abbreviation, if one exists. Original Specification This contains a pointer to the public specification of the grant type, if one exists. This registry will be initially populated by the values in Figure 11. The Reference column for all of these entries will be this document. -8.4. OAuth Access Token Types +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.5. OAuth Token Type CBOR Mappings +8.6. OAuth Token Type CBOR Mappings - This section eatables 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 "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 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 OAuth token type abbreviation, if one exists. Original Specification This contains a pointer to the public specification of the grant type, if one exists. -8.5.1. Initial Registry Contents +8.6.1. Initial Registry Contents o Name: "Bearer" o Value: 1 o Reference: [this document] o Original Specification: [RFC6749] o Name: "pop" o Value: 2 o Reference: [this document] o Original Specification: [this document] -8.6. ACE Profile Registry +8.7. ACE Profile Registry - This section establishes the IANA "ACE Profile" registry. The + This specification establishes the IANA "ACE Profile" 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 the profile, to be used as value of the profile attribute. @@ -1804,41 +1831,42 @@ 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. -8.7. OAuth Parameter Registration +8.8. OAuth Parameter Registration - This section registers the following parameter in the "OAuth + 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.8. OAuth CBOR Parameter Mappings Registry +8.9. OAuth CBOR Parameter Mappings Registry - This section establishes the IANA "Token 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 "Token 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. 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 @@ -1848,34 +1876,35 @@ parameter. Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 12. The Reference column for all of these entries will be this document. Note that these mappings intentionally coincide with the CWT claim name mappings from [RFC8392]. -8.9. OAuth Introspection Response Parameter Registration +8.10. OAuth Introspection Response Parameter Registration - This section registers the following parameter in the OAuth Token - Introspection Response registry [IANA.TokenIntrospectionResponse]. + 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.10. Introspection Endpoint CBOR Mappings Registry +8.11. Introspection Endpoint CBOR Mappings Registry - This section establishes the IANA "Introspection Endpoint CBOR + 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. The columns of this registry are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., "client_id". @@ -1887,21 +1916,21 @@ 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. Value Type The allowable CBOR data types for values of this parameter. Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 16. The Reference column for all of these entries will be this document. -8.11. JSON Web Token Claims +8.12. JSON Web Token Claims This specification registers the following new claims in the JSON Web Token (JWT) registry of JSON Web Token Claims [IANA.JsonWebTokenClaims]: o Claim Name: "scope" o Claim Description: The scope of an access token as defined in [RFC6749]. o Change Controller: IESG o Reference: Section 5.8 of [this document] @@ -1911,21 +1940,21 @@ with. o Change Controller: IESG o Reference: Section 5.8 of [this document] o Claim Name: "rs_cnf" o Claim Description: The public key the RS is supposed to use to authenticate to the client wielding this token. o Change Controller: IESG o Reference: Section 5.8 of [this document] -8.12. CBOR Web Token Claims +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 Claim Key: 12 o Claim Value Type(s): byte string or text string @@ -1943,24 +1972,24 @@ o Claim Name: "rs_cnf" o Claim Description: The public key the RS is supposed to use to authenticate to the client wielding this token. o JWT Claim Name: N/A o Claim Key: 17 o Claim Value Type(s): map o Change Controller: IESG o Specification Document(s): Section 5.8 of [this document] -8.13. Media Type Registrations +8.14. Media Type Registrations - This document registers the 'application/ace+cbor' media type for - messages of the protocols defined in this document carrying + 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 specified in [RFC6838]. Type name: application Subtype name: ace+cbor Required parameters: none Optional parameters: none @@ -1983,30 +2012,31 @@ Magic number(s): n/a File extension(s): .ace Macintosh file type code(s): n/a Person & email address to contact for further information: Ludwig Seitz Intended usage: COMMON + Restrictions on usage: None Author: Ludwig Seitz Change controller: IESG -8.14. CoAP Content-Format Registry +8.15. CoAP Content-Format Registry - This document registers the following entry to the "CoAP Content- - Formats" registry: + This specification registers the following entry to the "CoAP + Content-Formats" registry: Media Type: application/ace+cbor Encoding ID: 19 Reference: [this document] 9. Acknowledgments @@ -2075,20 +2105,29 @@ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + . + + [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization + Framework: Bearer Token Usage", RFC 6750, + DOI 10.17487/RFC6750, October 2012, . + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . @@ -2113,26 +2152,20 @@ "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . 10.2. Informative References [I-D.erdtman-ace-rpcc] 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-ace-actors] - Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An - architecture for authorization in constrained - environments", draft-ietf-ace-actors-06 (work in - progress), November 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-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-12 @@ -2152,24 +2185,20 @@ [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, . - [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", - RFC 6749, DOI 10.17487/RFC6749, October 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 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for @@ -2631,24 +2660,24 @@ | | Figure 17: Token Request and Response Using Client Credentials. The information contained in the Request-Payload and the Response- Payload is shown in Figure 18. Request-Payload : { "grant_type" : "client_credentials", - "aud" : "tempSensorInLivingRoom", + "req_aud" : "tempSensorInLivingRoom", "client_id" : "myclient", "client_secret" : "qwerty" - "cnf" : { + "req_cnf" : { "COSE_Key" : { "kid" : b64'1Bg8vub9tLe1gHMzV76e8', "kty" : "EC", "crv" : "P-256", "x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU', "y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0' } } } @@ -2921,83 +2950,90 @@ 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 -14 to -15 +F.1. 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.2. 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.2. Version -13 to -14 +F.3. 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.3. Version -12 to -13 +F.4. Version -12 to -13 o Changed "Resource Information" to "Access Information" to avoid confusion. o Clarified section about AS discovery. o Editorial changes -F.4. Version -11 to -12 +F.5. 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.5. Version -10 to -11 +F.6. Version -10 to -11 o Fixed some CBOR data type errors. o Updated boilerplate text -F.6. Version -09 to -10 +F.7. 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.7. Version -08 to -09 +F.8. Version -08 to -09 o Allowed scope to be byte arrays. 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.8. Version -07 to -08 +F.9. 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. @@ -3011,96 +3047,96 @@ 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.9. Version -06 to -07 +F.10. Version -06 to -07 o Various clarifications added. o Fixed erroneous author email. -F.10. Version -05 to -06 +F.11. 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.11. Version -04 to -05 +F.12. 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 about the client and the RS. -F.12. Version -03 to -04 +F.13. 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.13. Version -02 to -03 +F.14. 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.14. Version -01 to -02 +F.15. 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.15. Version -00 to -01 +F.16. 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