--- 1/draft-ietf-ace-oauth-authz-45.txt 2021-11-09 00:13:33.496701616 -0800 +++ 2/draft-ietf-ace-oauth-authz-46.txt 2021-11-09 00:13:33.656705619 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft Combitech Intended status: Standards Track G. Selander -Expires: 2 March 2022 Ericsson +Expires: 12 May 2022 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - 29 August 2021 + 8 November 2021 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-45 + draft-ietf-ace-oauth-authz-46 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 2 March 2022. + This Internet-Draft will expire on 12 May 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -834,21 +834,21 @@ } Figure 3: AS Request Creation Hints payload example In the example above, the response parameter "AS" points the receiver of this message to the URI "coaps://as.example.com/token" to request access tokens. The RS sending this response uses an internal clock that is not synchronized with the clock of the AS. Therefore, it can not reliably verify the expiration time of access tokens it receives. To ensure a certain level of access token freshness nevertheless, the - RS has included a "cnonce" parameter (see Section 5.3.1) in the + RS has included a cnonce parameter (see Section 5.3.1) in the response. (The hex-sequence of the cnonce parameter is encoded in CBOR-based notation in this example.) Figure 4 illustrates the mandatory to use binary encoding of the message payload shown in Figure 3. a4 # map(4) 01 # unsigned(1) (=AS) 78 1c # text(28) 636f6170733a2f2f61732e657861 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" @@ -1351,23 +1351,23 @@ 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 if CBOR is not used, in the access token request. 5.8.4.4. Client-Nonce This parameter MUST be sent from the client to the AS, if it previously received a "cnonce" parameter in the "AS Request Creation Hints" Section 5.3. The parameter is encoded as a byte string for - CBOR-based interactions, and as a string (Base64 encoded binary) if - CBOR is not used. It MUST copy the value from the cnonce parameter - in the "AS Request Creation Hints". + CBOR-based interactions, and as a string (base64url without padding + encoded binary [RFC4648]) if CBOR is not used. It MUST copy the + value from the cnonce parameter in the "AS Request Creation Hints". 5.8.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.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]. @@ -1489,26 +1489,30 @@ ace_profile OPTIONAL. This indicates the profile that the RS MUST use with the client. See Section 5.8.4.3 for more details on the formatting of this parameter. If this parameter is absent, the AS assumes that the RS implicitly knows which profile to use towards the client. cnonce OPTIONAL. A client-nonce provided to the AS by the client. The RS MUST verify that this corresponds to the client-nonce previously provided to the client in the "AS Request Creation - Hints". See Section 5.3 and Section 5.8.4.4. + Hints". See Section 5.3 and Section 5.8.4.4. Its value is a byte + string when encoded in CBOR and the base64url encoding of this + byte string without padding when encoded in JSON [RFC4648]. cti OPTIONAL. The "cti" claim associated to this access token. This parameter has the same meaning and processing rules as the "jti" parameter defined in section 3.1.2 of [RFC7662] except that - the value is a byte string. + its value is a byte string when encoded in CBOR and the base64url + encoding of this byte string without padding when encoded in JSON + [RFC4648]. exi OPTIONAL. The "expires-in" claim associated to this access token. See Section 5.10.3. 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" @@ -2339,39 +2343,39 @@ 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. 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: - * Value: "ace.ai" + * Value: ace.ai * Description: ACE-OAuth authz-info endpoint resource. * Reference: [this document] 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]. - * Error name: "unsupported_pop_key" + * Error name: unsupported_pop_key * Error usage location: token error response * Related protocol extension: [this document] * Change Controller: IETF * Specification document(s): Section 5.8.3 of [this document] - * Error name: "incompatible_ace_profiles" + * Error name: incompatible_ace_profiles * Error usage location: token error response * Related protocol extension: [this document] * Change Controller: IETF * Specification document(s): Section 5.8.3 of [this document] 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 @@ -2412,21 +2416,21 @@ 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.6. OAuth Access Token Types This section registers the following new token type in the "OAuth Access Token Types" registry [IANA.OAuthAccessTokenTypes]. - * Type name: "PoP" + * Type name: PoP * Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see section 3.1 of [RFC8747] and section 3.1 of [I-D.ietf-ace-oauth-params]. * HTTP Authentication Scheme(s): N/A * Change Controller: IETF * Specification document(s): [this document] 8.7. OAuth Access Token Type CBOR Mappings This specification established the IANA "OAuth Access Token Type CBOR @@ -2441,26 +2445,26 @@ 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.7.1. Initial Registry Contents - * Name: "Bearer" + * Name: Bearer * Value: 1 * Reference: [this document] * Original Specification: [RFC6749] - * Name: "PoP" + * Name: PoP * Value: 2 * Reference: [this document] * Original Specification: [this document] 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, @@ -2483,21 +2487,21 @@ profile abbreviation, if one exists. This registry will be initially empty and will be populated by the registrations from the ACE framework profiles. 8.9. OAuth Parameter Registration This specification registers the following parameter in the "OAuth Parameters" registry [IANA.OAuthParameters]: - * Name: "ace_profile" + * Name: ace_profile * Parameter Usage Location: token response * Change Controller: IETF * Reference: Section 5.8.2 and Section 5.8.4.3 of [this document] 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. @@ -2519,39 +2523,39 @@ 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.11. OAuth Introspection Response Parameter Registration This specification registers the following parameters in the OAuth Token Introspection Response registry [IANA.TokenIntrospectionResponse]. - * Name: "ace_profile" + * Name: ace_profile * Description: The ACE profile used between client and RS. * Change Controller: IETF * Reference: Section 5.9.2 of [this document] - * Name: "cnonce" + * Name: cnonce * Description: "client-nonce". A nonce previously provided to the AS by the RS via the client. Used to verify token freshness when the RS cannot synchronize its clock with the AS. * Change Controller: IETF * Reference: Section 5.9.2 of [this document] - * Name: "cti" + * Name: cti * Description: "CWT ID". The identifier of a CWT as defined in [RFC8392]. * Change Controller: IETF * Reference: Section 5.9.2 of [this document] - * Name: "exi" + * Name: exi * 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. * Change Controller: IETF * Reference: Section 5.9.2 of [this document] 8.12. OAuth Token Introspection Response CBOR Mappings Registry This specification establishes the IANA "OAuth Token Introspection @@ -2580,73 +2584,73 @@ Note that the mappings of parameters corresponding to claim names intentionally coincide with the CWT claim name mappings from [RFC8392]. 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]: - * Claim Name: "ace_profile" + * Claim Name: ace_profile * Claim Description: The ACE profile a token is supposed to be used with. * Change Controller: IETF * Reference: Section 5.10 of [this document] - * Claim Name: "cnonce" + * Claim Name: cnonce * Claim Description: "client-nonce". A nonce previously provided to the AS by the RS via the client. Used to verify token freshness when the RS cannot synchronize its clock with the AS. * Change Controller: IETF * Reference: Section 5.10 of [this document] - * Claim Name: "exi" + * Claim Name: exi * 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. * Change Controller: IETF * Reference: Section 5.10.3 of [this document] 8.14. CBOR Web Token Claims This specification registers the following new claims in the "CBOR Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. - * Claim Name: "ace_profile" + * Claim Name: ace_profile * Claim Description: The ACE profile a token is supposed to be used with. * JWT Claim Name: ace_profile * Claim Key: TBD (suggested: 38) * Claim Value Type(s): integer * Change Controller: IETF * Specification Document(s): Section 5.10 of [this document] - * Claim Name: "cnonce" + * Claim Name: cnonce * Claim Description: The client-nonce sent to the AS by the RS via the client. * JWT Claim Name: cnonce * Claim Key: TBD (suggested: 39) * Claim Value Type(s): byte string * Change Controller: IETF * Specification Document(s): Section 5.10 of [this document] - * Claim Name: "exi" + * Claim Name: exi * Claim Description: The expiration time of a token measured from when it was received at the RS in seconds. * JWT Claim Name: exi * Claim Key: TBD (suggested: 40) * Claim Value Type(s): integer * Change Controller: IETF * Specification Document(s): Section 5.10.3 of [this document] - * Claim Name: "scope" + * Claim Name: scope * Claim Description: The scope of an access token as defined in [RFC6749]. * JWT Claim Name: scope * Claim Key: TBD (suggested: 9) * Claim Value Type(s): byte string or text string * Change Controller: IETF * Specification Document(s): Section 4.2 of [RFC8693] 8.15. Media Type Registrations @@ -2776,23 +2780,23 @@ 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-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", Work in Progress, - Internet-Draft, draft-ietf-ace-oauth-params-15, 6 May - 2021, . + Internet-Draft, draft-ietf-ace-oauth-params-16, 7 + September 2021, . [IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", . [IANA.CoreParameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", . @@ -2824,20 +2828,24 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + . + [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,