--- 1/draft-ietf-ace-oauth-authz-17.txt 2019-01-17 07:13:28.986444543 -0800 +++ 2/draft-ietf-ace-oauth-authz-18.txt 2019-01-17 07:13:29.130448049 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft RISE Intended status: Standards Track G. Selander -Expires: May 30, 2019 Ericsson +Expires: July 21, 2019 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - November 26, 2018 + January 17, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-17 + draft-ietf-ace-oauth-authz-18 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,43 +34,43 @@ 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 May 30, 2019. + This Internet-Draft will expire on July 21, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 19 @@ -85,77 +85,79 @@ 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 . . . . . . . . . . . . . . . . . . . . 34 - 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 34 - 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 35 + 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 . . . . . . . . . . . . . . . 37 - 6.2. Minimal security requirements for communication . 37 - 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 38 + 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 . . 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 . . . . . . . . . . . 41 + 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 42 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 42 - 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 43 + 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 44 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 44 - 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 44 - 8.9. Token Endpoint CBOR Mappings Registry . . . . . . . . . . 44 - 8.10. OAuth Introspection Response Parameter Registration . . . 45 - 8.11. Introspection Endpoint CBOR Mappings Registry . . . . . . 45 - 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 46 + 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 . . . . . . . . . . . . . . . . 47 - 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 48 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 49 - 10.2. Informative References . . . . . . . . . . . . . . . . . 51 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 53 - Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 57 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 59 + 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 . . . . . . . . . . . . . . . . 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 -15 to -16 . . . . . . . . . . . . . . . . . . . 69 - F.2. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 69 - F.3. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 69 - F.4. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 70 - F.5. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 70 - F.6. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 70 - F.7. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 70 - F.8. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 70 - F.9. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 71 - F.10. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 71 - F.11. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 71 - F.12. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 71 - F.13. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 72 - F.14. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 72 - F.15. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 72 - F.16. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 73 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 + 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 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. @@ -938,20 +940,21 @@ [I-D.ietf-core-object-security] is used to provide object-security, therefore the Content-Format is "application/oscore" wrapping the "application/ace+cbor" type content. Also note that in this example 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 ) Decrypted payload: { "grant_type" : "client_credentials", "client_id" : "myclient", "req_cnf" : { @@ -1284,20 +1287,21 @@ For example, Figure 13 shows a RS calling the token introspection endpoint at the AS to query about an OAuth 2.0 proof-of-possession token. Note that object security based on OSCORE [I-D.ietf-core-object-security] is assumed in this example, therefore the Content-Format is "application/oscore". Figure 14 shows the decoded payload. Header: POST (Code=0.02) Uri-Host: "as.example.com" Uri-Path: "introspect" + OSCORE: 0x09, 0x05, 0x25 Content-Format: "application/oscore" Payload: ... COSE content ... Figure 13: Example introspection request. { "token" : b64'7gj0dXJQ43U', "token_type_hint" : "pop" } @@ -1319,21 +1323,21 @@ 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 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. Note that this example contains the "cnf" - parameter defined in [I-D.ietf-ace-oauth-params]/. + parameter defined in [I-D.ietf-ace-oauth-params]. Header: Created Code=2.01) Content-Format: "application/ace+cbor" Payload: { "active" : true, "scope" : "read", "profile" : "coap_dtls", "cnf" : { "COSE_Key" : { @@ -1411,23 +1415,23 @@ \-------------------+----------+-------------------------/ Figure 16: CBOR Mappings to Token Introspection Parameters. 5.8. The Access Token This framework RECOMMENDS the use of CBOR web token (CWT) as specified in [RFC8392]. In order to facilitate offline processing of access tokens, this - draft uses the "cnf" claim from + document uses the "cnf" claim from [I-D.ietf-ace-cwt-proof-of-possession] and specifies the "scope" - claim for both JSON and CBOR web tokens. + claim for JWT- and CWT-encoded tokens. The "scope" claim explicitly encodes the scope of a given access token. This claim follows the same encoding rules as defined in Section 3.3 of [RFC6749], but in addition implementers MAY use byte strings as scope values, to achieve compact encoding of large scope elements. The meaning of a specific scope value is application specific and expected to be known to the RS running that application. If the AS needs to convey a hint to the RS about which profile it should use to communicate with the client, the AS MAY include a @@ -1446,32 +1450,28 @@ framework MAY define other methods for token transport. The method consists of an authz-info endpoint, implemented by the RS. A client using this method MUST make a POST request to the authz-info endpoint at the RS with the access token in the payload. The RS receiving the token MUST verify the validity of the token. If the token is valid, the RS MUST respond to the POST request with 2.01 (Created). Section Section 5.8.1.1 outlines how an RS MUST proceed to verify the validity of an access token. - If the access token is a CWT and is sent via CoAP, the content format - "application/cwt" MUST be used. If a token is sent via HTTP the - equivalent media type "application/cwt" MUST be used. - The RS MUST be prepared to store at least one access token for future use. This is a difference to how access tokens are handled in OAuth 2.0, where the access token is typically sent along with each request, and therefore not stored at the RS. This specification RECOMMENDS that an RS stores only one token per proof-of-possession key, meaning that an additional token linked to - the same key will overwrite any exiting token at the RS. + the same key will overwrite any existing token at the RS. If the payload sent to the authz-info endpoint does not parse to a token, the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request). 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. @@ -1486,68 +1486,92 @@ A RS MAY use introspection on a token received through the authz-info endpoint, e.g. if the token is an opaque reference. Some transport protocols may provide a way to indicate that the RS is busy and the client should retry after an interval; this type of status update would be appropriate while the RS is waiting for an introspection response. 5.8.1.1. Verifying an Access Token When an RS receives an access token, it MUST verify it before storing - it. The verification is based on the claims of the token and its - cryptographic wrapper (if any), so the RS needs to retrieve those - claims. If the claims cannot be retrieved the RS MUST discard the - token and in case of an interaction via the authz-info endpoint, - return an error message with a response code equivalent to the CoAP - code 4.00 (Bad Request). + it. The details of token verification depends on various aspects, + including the token encoding, the type of token, the security + protection applied to the token, and the claims. The token encoding + matters since the security wrapper differs between the token + encodings. For example, a CWT token uses COSE while a JWT token uses + JOSE. The type of token also has an influence on the verification + procedure since tokens may be self-contained whereby token + verification may happen locally at the RS while a token-by-reference + requires further interaction with the authorization server, for + example using token introspection, to obtain the claims associated + with the token reference. Self-contained token MUST, at a minimum, + be integrity protected but they MAY also be encrypted. - Since the cryptographic wrapper of the token (e.g. a COSE message) - could include encryption, it needs to be verified first, based on - shared cryptographic material with recognized AS. If this - verification fails, the RS MUST discard the token and if this was an - interaction with authz-info it MUST respond with a response code - equivalent to the CoAP code 4.01 (Unauthorized). + For self-contained tokens the RS MUST process the security protection + of the token first, as specified by the respective token format. For + CWT the description can be found in [RFC8392] and for JWT the + relevant specification is [RFC7519]. This MUST include a + verification that security protection (and thus the token) was + generated by an AS that has the right to issue access tokens for this + RS. - The following claims MUST be checked if present, and errors returned - when a check fails, in the order of priority of this list: + In case the token is communicated by reference the RS needs to obtain + the claims first. When the RS uses token introspection the relevant + specification is [RFC7662] with CoAP transport specified in + Section 5.7. + + Errors may happen during this initial processing stage: + + o If token or claim verification fails, the RS MUST discard the + token and, if this was an interaction with authz-info, return an + error message with a response code equivalent to the CoAP code + 4.01 (Unauthorized). + o If the claims cannot be obtained the RS MUST discard the token + and, in case of an interaction via the authz-info endpoint, return + an error message with a response code equivalent to the CoAP code + 4.00 (Bad Request). + + Next, the RS MUST verify claims, if present, contained in the access + token. Errors are returned when claim checks fail, in the order of + priority of this list: iss The issuer claim must identify an AS that has the authority to issue access tokens for the receiving RS. If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). - exp The expiration date must be in the future. Note that this has - to be verified again at access time. If that is not the case the - RS MUST respond with a response code equivalent to the CoAP code - 4.01 (Unauthorized). - + exp The expiration date must be in the future. If that is not the + case the RS MUST respond with a response code equivalent to the + CoAP code 4.01 (Unauthorized). Note that the RS has to terminate + access rights to the protected resources at the time when the + tokens expire. aud The audience claim must refer to an audience that the RS identifies with. If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.03 (Forbidden). scope The RS must recognize value of the scope claim. If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request). The RS MAY provide - additional information in the error response, in order to clarify - what went wrong. + additional information in the error response, to clarify what went + wrong. If the access token contains any other claims that the RS cannot process the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request). The RS MAY provide additional detail in the error response to clarify which claim couldn't be processed. Note that the Subject (sub) claim cannot always be verified when the - token is submitted to the RS, since the client may not have + 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], in order to provide additional detail to - the client. + Section 3.1 of [RFC6750], to provide additional details to the + client. 5.8.1.2. Protecting the Authzorization 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). @@ -2153,20 +2177,28 @@ 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 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 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 specified in [RFC6838]. Type name: application @@ -2249,21 +2281,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-00 (work in progress), September 2018. + params-01 (work in progress), November 2018. [IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", . [IANA.JsonWebTokenClaims] IANA, "JSON Web Token Claims", . @@ -2770,20 +2803,22 @@ o The audiences that the RS identifies with. o The key types (e.g., pre-shared symmetric key, raw public key, key length, other key parameters) that the client or RS supports. o The types of access tokens the RS supports (e.g., CWT). o If the RS supports CWTs, the COSE parameters for the crypto wrapper (e.g., algorithm, key-wrap algorithm, key-length). o The expiration time for access tokens issued to this RS (unless the RS accepts a default time chosen by the AS). o The symmetric key shared between client or RS and AS (if any). o The raw public key of the client or RS (if any). + o Whether the RS has synchronized time (and thus is able to use the + 'exp' claim) or not. Appendix E. Deployment Examples There is a large variety of IoT deployments, as is indicated in Appendix A, and this section highlights a few common variants. This section is not normative but illustrates how the framework can be applied. For each of the deployment variants, there are a number of possible security setups between clients, resource servers and authorization @@ -3077,21 +3114,20 @@ (cnf) parameter that allows the RS to verify the client's proof of possession in step F. After receiving message E, the RS responds to the client's POST in step C with the CoAP response code 2.01 (Created). Resource Client Server | | C: +-------->| Header: POST (T=CON, Code=0.02) | POST | Uri-Path:"authz-info" - | | Content-Format: "application/ace+cbor" | | Payload: b64'VGVzdCB0b2tlbg==' | | | | Authorization | | Server | | | | D: +--------->| Header: POST (Code=0.02) | | POST | Uri-Path: "introspect" | | | Content-Format: "application/ace+cbor" | | | Payload: | | | @@ -3148,90 +3184,122 @@ 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 -15 to -16 +F.1. 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 + + 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. + 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 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 +F.4. 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.3. Version -13 to -14 +F.5. 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.4. Version -12 to -13 +F.6. Version -12 to -13 o Changed "Resource Information" to "Access Information" to avoid confusion. o Clarified section about AS discovery. o Editorial changes -F.5. Version -11 to -12 +F.7. 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.6. Version -10 to -11 +F.8. Version -10 to -11 o Fixed some CBOR data type errors. o Updated boilerplate text -F.7. Version -09 to -10 +F.9. 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.8. Version -08 to -09 +F.10. 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.9. Version -07 to -08 +F.11. 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. @@ -3245,40 +3314,39 @@ 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.10. Version -06 to -07 +F.12. Version -06 to -07 o Various clarifications added. o Fixed erroneous author email. -F.11. Version -05 to -06 +F.13. 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.12. Version -04 to -05 +F.14. 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 @@ -3277,64 +3345,63 @@ 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.13. Version -03 to -04 +F.15. 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.14. Version -02 to -03 +F.16. 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.15. Version -01 to -02 +F.17. 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.16. Version -00 to -01 +F.18. 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