--- 1/draft-ietf-ace-oauth-authz-33.txt 2020-06-23 00:13:09.810900521 -0700 +++ 2/draft-ietf-ace-oauth-authz-34.txt 2020-06-23 00:13:09.978904787 -0700 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft Combitech Intended status: Standards Track G. Selander -Expires: August 10, 2020 Ericsson +Expires: December 25, 2020 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - February 7, 2020 + June 23, 2020 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-33 + draft-ietf-ace-oauth-authz-34 Abstract This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 10, 2020. + This Internet-Draft will expire on December 25, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -105,48 +105,48 @@ 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44 6.5. Minimal security requirements for communication . 45 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48 6.10. Denial of service against or with Introspection . . 48 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8.1. ACE Authorization Server Request Creation Hints . . . . . 50 - 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 51 - 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 - 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51 - 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 - 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 - 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 52 - 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53 - 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 53 - 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 53 - 8.10. OAuth Introspection Response Parameter Registration . . . 54 - 8.11. OAuth Token Introspection Response CBOR Mappings Registry 54 - 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 - 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 - 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56 - 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 - 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 58 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 + 8.2. CoRE Resource Type registry . . . . . . . . . . . . . . . 51 + 8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51 + 8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 + 8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52 + 8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 + 8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 + 8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53 + 8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53 + 8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54 + 8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54 + 8.11. OAuth Introspection Response Parameter Registration . . . 54 + 8.12. OAuth Token Introspection Response CBOR Mappings Registry 55 + 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 + 8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 + 8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57 + 8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58 + 8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . 62 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 + Appendix A. Design Justification . . . . . . . . . . . . . . . . 65 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 + Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 - Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71 + Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 72 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72 E.2. Introspection Aided Token Validation . . . . . . . . . . 76 - Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81 F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81 F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82 F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 82 F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 82 @@ -663,25 +664,24 @@ common key infrastructure, so the AS provisions credentials or associated information to allow mutual authentication between client and RS. The resulting security association between client and RS may then also be used to bind these credentials to the access tokens the client uses. Proof-of-Possession The ACE framework, by default, implements proof-of-possession for access tokens, i.e., that the token holder can prove being a holder of the key bound to the token. The binding is provided by - the "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession] indicating - what key is used for proof-of-possession. If a client needs to - submit a new access token, e.g., to obtain additional access - rights, they can request that the AS binds this token to the same - key as the previous one. + the "cnf" claim [RFC8747] indicating what key is used for proof- + of-possession. If a client needs to submit a new access token, + e.g., to obtain additional access rights, they can request that + the AS binds this token to the same key as the previous one. ACE Profiles The client or RS may be limited in the encodings or protocols it supports. To support a variety of different deployment settings, specific interactions between client and RS are defined in an ACE profile. In ACE framework the AS is expected to manage the matching of compatible profile choices between a client and an RS. The AS informs the client of the selected profile using the "ace_profile" parameter in the token response. @@ -707,21 +707,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, it is REQUIRED to 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 at the outermost encoding layer MUST use the media format 'application/ ace+cbor'. If CoAP is used for communication, the Content-Format - MUST be abbreviated with the ID: 19 (see Section 8.15). + MUST be abbreviated with the ID: 19 (see Section 8.16). The OAuth 2.0 AS uses a JSON structure in the payload of its responses both to client and RS. If CoAP is used, it is REQUIRED to use 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 RS, C MAY send an initial Unauthorized Resource Request message to @@ -1283,21 +1283,21 @@ 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 - The abbreviations specified in the registry defined in Section 8.4 + The abbreviations specified in the registry defined in Section 8.5 MUST be used in CBOR encodings instead of the string values defined in [RFC6749], if CBOR payloads are used. /--------------------+------------+------------------------\ | Name | CBOR Value | Original Specification | |--------------------+------------+------------------------| | password | 0 | [RFC6749] | | authorization_code | 1 | [RFC6749] | | client_credentials | 2 | [RFC6749] | | refresh_token | 3 | [RFC6749] | @@ -1310,41 +1310,41 @@ The "token_type" parameter, defined in section 5.1 of [RFC6749], allows the AS to indicate to the client which type of access token it is receiving (e.g., a bearer token). This document registers the new value "PoP" for the OAuth Access Token Types registry, specifying a proof-of-possession token. How the proof-of-possession by the client to the RS is performed MUST be specified by the profiles. The values in the "token_type" parameter MUST use the CBOR - abbreviations defined in the registry specified by Section 8.6, if a + abbreviations defined in the registry specified by Section 8.7, if a CBOR encoding is used. In this framework the "pop" value for the "token_type" parameter is the default. The AS may, however, provide a different value. 5.6.4.3. Profile Profiles of this framework MUST define the communication protocol and the communication security protocol between the client and the RS. The security protocol MUST provide encryption, integrity and replay protection. It MUST also provide a binding between requests and responses. Furthermore profiles MUST define a list of allowed proof- of-possession methods, if they support proof-of-possession tokens. A profile MUST specify an identifier that MUST be used to uniquely identify itself in the "ace_profile" parameter. The textual representation of the profile identifier is intended for human readability and for JSON-based interactions, it MUST NOT be used for CBOR-based interactions. Profiles MUST register their identifier in - the registry defined in Section 8.7. + the registry defined in Section 8.8. Profiles MAY define additional parameters for both the token request and the Access Information in the access token response in order to support negotiation or signaling of profile specific parameters. Clients that want the AS to provide them with the "ace_profile" parameter in the access token response can indicate that by sending a ace_profile parameter with a null value (for CBOR-based interactions) or an empty string (for JSON based interactions) in the access token request. @@ -1355,21 +1355,21 @@ previously received a "cnonce" parameter in the AS Request Creation Hints Section 5.1.2. The parameter is encoded as a byte string for CBOR-based interactions, and as a string (Base64 encoded binary) for JSON-based interactions. It MUST copy the value from the cnonce parameter in the AS Request Creation Hints. 5.6.5. Mapping Parameters to CBOR If CBOR encoding is used, all OAuth parameters in access token requests and responses MUST be mapped to CBOR types as specified in - the registry defined by Section 8.9, using the given integer + the registry defined by Section 8.10, using the given integer abbreviation for the map keys. Note that we have aligned the abbreviations corresponding to claims with the abbreviations defined in [RFC8392]. Note also that abbreviations from -24 to 23 have a 1 byte encoding size in CBOR. We have thus chosen to assign abbreviations in that range to parameters we expect to be used most frequently in constrained scenarios. @@ -1536,33 +1536,33 @@ o If the requesting entity does not have the right to perform this introspection request, the AS MUST respond with a response code equivalent to the CoAP code 4.03 (Forbidden). In this case no payload is returned. o The parameters "error", "error_description" and "error_uri" MUST be abbreviated using the codes specified in Figure 12. o The error codes MUST be abbreviated using the codes specified in - the registry defined by Section 8.3. + the registry defined by Section 8.4. Note that a properly formed and authorized query for an inactive or otherwise invalid token does not warrant an error response by this specification. In these cases, the authorization server MUST instead respond with an introspection response with the "active" field set to "false". 5.7.4. Mapping Introspection parameters to CBOR If CBOR is used, the introspection request and response parameters MUST be mapped to CBOR types as specified in the registry defined by - Section 8.11, using the given integer abbreviation for the map key. + Section 8.12, using the given integer abbreviation for the map key. Note that we have aligned abbreviations that correspond to a claim with the abbreviations defined in [RFC8392] and the abbreviations of parameters with the same name from Section 5.6.5. /-------------------+----------+-------------------------\ | Parameter name | CBOR Key | Value Type | |-------------------+----------+-------------------------| | iss | 1 | text string | | sub | 2 | text string | @@ -1590,28 +1590,27 @@ \-------------------+----------+-------------------------/ 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 - document uses the "cnf" claim from - [I-D.ietf-ace-cwt-proof-of-possession] and the "scope" claim from - [RFC8693] for JWT- and CWT-encoded tokens. In addition to string - encoding specified for the "scope" claim, a binary encoding MAY be - used. The syntax of such an encoding is explicitly not specified - here and left to profiles or applications, specifically note that a - binary encoded scope does not necessarily use the space character - '0x20' to delimit scope-tokens. + document uses the "cnf" claim from [RFC8747] and the "scope" claim + from [RFC8693] for JWT- and CWT-encoded tokens. In addition to + string encoding specified for the "scope" claim, a binary encoding + MAY be used. The syntax of such an encoding is explicitly not + specified here and left to profiles or applications, specifically + note that a binary encoded scope does not necessarily use the space + character '0x20' to delimit scope-tokens. 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 an "ace_profile" claim in the access token, with the same syntax and semantics as defined in Section 5.6.4.3. If the client submitted a client-nonce parameter in the access token request Section 5.6.4.4, the AS MUST include the value of this parameter in the "cnonce" claim specified here. The "cnonce" claim uses binary encoding. @@ -2273,21 +2272,21 @@ information as possible in an unencrypted response. If 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 This document creates several registries with a registration policy of "Expert Review"; guidelines to the experts are given in - Section 8.16. + Section 8.17. 8.1. ACE Authorization Server Request Creation Hints This specification establishes the IANA "ACE Authorization Server Request Creation Hints" registry. The registry has been created to use the "Expert Review" 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. @@ -2305,58 +2304,71 @@ Value Type The CBOR data types allowable for the values of this parameter. Reference This contains a pointer to the public specification of the request creation hint 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 Extensions Error Registration +8.2. CoRE Resource Type registry + + IANA is requested to register a new Resource Type (rt=) Link Target + Attribute in the "Resource Type (rt=) Link Target Attribute Values" + subregistry under the "Constrained RESTful Environments (CoRE) + Parameters" [IANA.CoreParameters] registry: + + rt="ace.ai". This resource type describes an ACE-OAuth authz-info + endpoint resource. + + Specific ACE-OAuth profiles can use this common resource type for + defining their profile-specific discovery processes. + +8.3. OAuth Extensions Error Registration This specification registers the following error values in the OAuth Extensions Error registry [IANA.OAuthExtensionsErrorRegistry]. o Error name: "unsupported_pop_key" o Error usage location: token error response o Related protocol extension: [this document] o Change Controller: IESG o Specification document(s): Section 5.6.3 of [this document] o Error name: "incompatible_ace_profiles" o Error usage location: token error response o Related protocol extension: [this document] o Change Controller: IESG o Specification document(s): Section 5.6.3 of [this document] -8.3. OAuth Error Code CBOR Mappings Registry +8.4. 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" registration procedure [RFC8126], except for the value range designated for private use. 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. Integer values less than -65536 are marked as "Private Use", all other values use the registration policy "Expert Review" [RFC8126]. Reference This contains a pointer to the public specification of the error code 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.4. OAuth Grant Type CBOR Mappings +8.5. OAuth Grant Type CBOR Mappings This specification establishes the IANA "OAuth Grant Type CBOR Mappings" registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126], except for the value range designated for private use. The columns of this registry are: Name The name of the grant type as specified in Section 1.3 of [RFC6749]. @@ -2365,33 +2376,33 @@ less than -65536 are marked as "Private Use", all other values use the registration policy "Expert Review" [RFC8126]. 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.5. OAuth Access Token Types +8.6. OAuth Access Token Types This section registers the following new token type in the "OAuth Access Token Types" registry [IANA.OAuthAccessTokenTypes]. o Type name: "PoP" o Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see section 3.3 of [I-D.ietf-ace-oauth-params]. o HTTP Authentication Scheme(s): N/A o Change Controller: IETF o Specification document(s): [this document] -8.6. OAuth Access Token Type CBOR Mappings +8.7. OAuth Access Token Type CBOR Mappings This specification established the IANA "OAuth Access Token Type CBOR Mappings" registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126], except for the value range designated for private use. The columns of this registry are: Name The name of token type as registered in the OAuth Access Token Types registry, e.g., "Bearer". @@ -2388,40 +2399,42 @@ This specification established the IANA "OAuth Access Token Type CBOR Mappings" registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126], except for the value range designated for private use. 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. Integer values less than -65536 are marked as "Private Use", all other values use the registration policy "Expert Review" [RFC8126]. 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 OAuth token type, if one exists. -8.6.1. Initial Registry Contents +8.7.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.7. ACE Profile Registry +8.8. ACE Profile Registry This specification establishes the IANA "ACE Profile" registry. The registry has been created to use the "Expert Review" 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 @@ -2434,31 +2447,31 @@ 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 +8.9. OAuth Parameter Registration This specification registers the following parameter in the "OAuth Parameters" registry [IANA.OAuthParameters]: o Name: "ace_profile" o Parameter Usage Location: token response o Change Controller: IESG o Reference: Section 5.6.2 and Section 5.6.4.3 of [this document] -8.9. OAuth Parameters CBOR Mappings Registry +8.10. OAuth Parameters CBOR Mappings Registry This specification establishes the IANA "OAuth Parameters CBOR Mappings" registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126], except for the value range designated for private use. The columns of this registry are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., "client_id". @@ -2466,21 +2479,21 @@ -65536 are marked as "Private Use", all other values use the registration policy "Expert Review" [RFC8126]. Value Type The allowable CBOR data types for values of this parameter. Reference This contains a pointer to the public specification of the OAuth parameter 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. -8.10. OAuth Introspection Response Parameter Registration +8.11. OAuth Introspection Response Parameter Registration This specification registers the following parameters in the OAuth Token Introspection Response registry [IANA.TokenIntrospectionResponse]. o Name: "ace_profile" o Description: The ACE profile used between client and RS. o Change Controller: IESG o Reference: Section 5.7.2 of [this document] @@ -2492,21 +2505,21 @@ o Reference: Section 5.7.2 of [this document] o Name: "exi" o Description: "Expires in". Lifetime of the token in seconds from the time the RS first sees it. Used to implement a weaker from of token expiration for devices that cannot synchronize their internal clocks. o Change Controller: IESG o Reference: Section 5.7.2 of [this document] -8.11. OAuth Token Introspection Response CBOR Mappings Registry +8.12. OAuth Token Introspection Response CBOR Mappings Registry This specification establishes the IANA "OAuth Token Introspection Response CBOR Mappings" registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126], except for the value range designated for private use. The columns of this registry are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., "client_id". @@ -2518,21 +2531,21 @@ Reference This contains a pointer to the public specification of the introspection response parameter 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. Note that the mappings of parameters corresponding to claim names intentionally coincide with the CWT claim name mappings from [RFC8392]. -8.12. JSON Web Token Claims +8.13. 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: "ace_profile" o Claim Description: The ACE profile a token is supposed to be used with. o Change Controller: IESG o Reference: Section 5.8 of [this document] @@ -2545,21 +2557,21 @@ o Reference: Section 5.8 of [this document] o Claim Name: "exi" o Claim Description: "Expires in". Lifetime of the token in seconds from the time the RS first sees it. Used to implement a weaker from of token expiration for devices that cannot synchronize their internal clocks. o Change Controller: IESG o Reference: Section 5.8.3 of [this document] -8.13. CBOR Web Token Claims +8.14. CBOR Web Token Claims This specification registers the following new claims in the "CBOR Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. o Claim Name: "ace_profile" o Claim Description: The ACE profile a token is supposed to be used with. o JWT Claim Name: ace_profile o Claim Key: TBD (suggested: 38) o Claim Value Type(s): integer @@ -2581,26 +2593,26 @@ o JWT Claim Name: exi o Claim Key: TBD (suggested: 40) o Claim Value Type(s): integer o Change Controller: IESG o Specification Document(s): Section 5.8.3 of [this document] o Claim Name: "scope" o Claim Description: The scope of an access token as defined in [RFC6749]. o JWT Claim Name: scope - o Claim Key: TBD (suggested: 9) + o Claim Key: TBD (suggested: 42) o Claim Value Type(s): byte string or text string o Change Controller: IESG o Specification Document(s): Section 4.2 of [RFC8693] -8.14. Media Type Registrations +8.15. 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 Subtype name: ace+cbor @@ -2626,37 +2638,36 @@ Additional information: N/A Person & email address to contact for further information: Intended usage: COMMON Restrictions on usage: none Author: Ludwig Seitz - Change controller: IESG -8.15. CoAP Content-Format Registry +8.16. CoAP Content-Format Registry This specification registers the following entry to the "CoAP Content-Formats" registry: Media Type: application/ace+cbor Encoding: - ID: TBD (suggested: 19) Reference: [this document] -8.16. Expert Review Instructions +8.17. Expert Review Instructions All of the IANA registries established in this document are defined to use a registration policy of 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 @@ -2702,45 +2713,47 @@ contributing their work on AS discovery from draft-gerdes-ace-dcaf- authorize (see Section 5.1). Thanks to Jim Schaad and Mike Jones for their comprehensive reviews. Thanks to Benjamin Kaduk for his input on various questions related to this work. Thanks to Cigdem Sengul for some very useful review comments. + Thanks to Carsten Bormann for contributing the text for the CoRE + Resource Type registry. + Ludwig Seitz and Goeran Selander worked on this document as part of the CelticPlus project CyberWI, with funding from Vinnova. Ludwig Seitz was also received further funding for this work by Vinnova in the context of the CelticNext project Critisec. 10. References 10.1. Normative References - [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-11 (work in progress), October 2019. - [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", draft-ietf-ace-oauth- - params-11 (work in progress), January 2020. + params-13 (work in progress), April 2020. [IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", . + [IANA.CoreParameters] + IANA, "Constrained RESTful Environments (CoRE) + Parameters", . + [IANA.JsonWebTokenClaims] IANA, "JSON Web Token Claims", . [IANA.OAuthAccessTokenTypes] IANA, "OAuth Access Token Types", . [IANA.OAuthExtensionsErrorRegistry] @@ -2827,42 +2840,47 @@ [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . + [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. + Tschofenig, "Proof-of-Possession Key Semantics for CBOR + Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March + 2020, . + 10.2. Informative References [BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1", Section 4.4, January 2019, . [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-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", draft-ietf-quic-transport-25 (work - in progress), January 2020. + and Secure Transport", draft-ietf-quic-transport-29 (work + in progress), June 2020. [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-34 (work in progress), - November 2019. + 1.3", draft-ietf-tls-dtls13-38 (work in progress), May + 2020. [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), August 2010. [MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT @@ -3071,29 +3089,28 @@ This framework defines the name "Access Information" for data concerning the RS that the AS returns to the client in an access token response (see Section 5.6.2). This aims at enabling scenarios where a powerful client, supporting multiple profiles, needs to interact with an RS for which it does not know the supported profiles and the raw public key. Proof-of-Possession: This framework makes use of proof-of-possession tokens, using the - "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession]. A request - parameter "cnf" and a Response parameter "cnf", both having a - value space semantically and syntactically identical to the "cnf" - claim, are defined for the token endpoint, to allow requesting and - stating confirmation keys. This aims at making token theft - harder. Token theft is specifically relevant in constrained use - cases, as communication often passes through middle-boxes, which - could be able to steal bearer tokens and use them to gain - unauthorized access. + "cnf" claim [RFC8747]. A request parameter "cnf" and a Response + parameter "cnf", both having a value space semantically and + syntactically identical to the "cnf" claim, are defined for the + token endpoint, to allow requesting and stating confirmation keys. + This aims at making token theft harder. Token theft is + specifically relevant in constrained use cases, as communication + often passes through middle-boxes, which could be able to steal + bearer tokens and use them to gain unauthorized access. Authz-Info endpoint: This framework introduces a new way of providing access tokens to an RS by exposing a authz-info endpoint, to which access tokens can be POSTed. This aims at reducing the size of the request message and the code complexity at the RS. The size of the request message is problematic, since many constrained protocols have severe message size limitations at the physical layer (e.g., in the order of 100 bytes). This means that larger packets get @@ -3846,21 +3862,21 @@ o Added privacy considerations about leakage through unprotected AS discovery. 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] + replaced with references to [RFC8747] F.16. Version -06 to -07 o Various clarifications added. o Fixed erroneous author email. F.17. Version -05 to -06 o Moved sections that define the ACE framework into a subsection of the framework Section 5.