--- 1/draft-ietf-ace-oauth-authz-30.txt 2020-01-18 09:13:18.010451655 -0800 +++ 2/draft-ietf-ace-oauth-authz-31.txt 2020-01-18 09:13:18.222457037 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft Combitech Intended status: Standards Track G. Selander -Expires: July 14, 2020 Ericsson +Expires: July 21, 2020 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - January 11, 2020 + January 18, 2020 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-30 + draft-ietf-ace-oauth-authz-31 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 July 14, 2020. + This Internet-Draft will expire on July 21, 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 @@ -94,21 +94,21 @@ 5.8.1. The Authorization Information Endpoint . . . . . . . 36 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37 5.8.1.2. Protecting the Authorization Information Endpoint . . . . . . . . . . . . . . . . . . . . 39 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42 6.2. Communication Security . . . . . . . . . . . . . . . . . 43 - 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43 + 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44 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 @@ -126,25 +126,25 @@ 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . 61 Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 - Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 + Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71 - E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72 + E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71 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 @@ -1002,22 +1002,22 @@ profile MUST specify how the communication is protected. The content of the request consists of the parameters specified in the relevant subsection of section 4 of the OAuth 2.0 specification [RFC6749], depending on the grant type, with the following exceptions and additions: o The parameter "grant_type" is OPTIONAL in the context of this framework (as opposed to REQUIRED in RFC6749). If that parameter is missing, the default value "client_credentials" is implied. - o The "audience" parameter from [I-D.ietf-oauth-token-exchange] is - OPTIONAL to request an access token bound to a specific audience. + o The "audience" parameter from [RFC8693] is OPTIONAL to request an + access token bound to a specific audience. o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if the RS provided a client-nonce in the "AS Request Creation Hints" message Section 5.1.2 o The "scope" parameter MAY be encoded as a byte string instead of the string encoding specified in section 3.3 of [RFC6749], in order allow compact encoding of complex scopes. The syntax of such a binary encoding is explicitly not specified here and left to profiles or applications, specifically note that a binary @@ -1592,26 +1592,26 @@ 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 - [I-D.ietf-oauth-token-exchange] 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. + [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. @@ -1844,21 +1844,34 @@ JSON number. o Processing this claim requires that the RS does the following: * For each token the RS receives, that contains an "exi" claim: Keep track of the time it received that token and revisit that list regularly to expunge expired tokens. * Keep track of the identifiers of tokens containing the "exi" claim that have expired (in order to avoid accepting them - again). + again). In order to avoid an unbounded memory usage growth, + this MUST be implemented in the following way when the "exi" + claim is used: + + + When creating the token, the AS MUST add a 'cti' claim ( or + 'jti' for JWTs) to the access token. The value of this + claim MUST be created as the binary representation of the + concatenation of the identifier of the RS with a sequence + number counting the tokens containing an 'exi' claim, issued + by this AS for the RS. + + + The RS MUST store the highest sequence number of an expired + token containing the "exi" claim that it has seen, and treat + tokens with lower sequence numbers as expired. 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. 5.8.4. Key Expiration The AS provides the client with key material that the RS uses. This can either be a common symmetric PoP-key, or an asymmetric key used @@ -2096,33 +2109,25 @@ predictable alternative. The "exi" approach has some drawbacks that need to be considered: A malicious client may hold back tokens with the "exi" claim in order to prolong their lifespan. If an RS loses state (e.g. due to an unscheduled reboot), it may loose the current values of counters tracking the "exi" claims of tokens it is storing. - The RS needs to keep state about expired tokens that used "exi" in - order to be sure not to accept it again. Attacker may use this to - deplete the RS's storage resources. - The first drawback is inherent to the deployment scenario and the "exi" solution. It can therefore not be mitigated without requiring the the RS be online at times. The second drawback can be mitigated by regularly storing the value of "exi" counters to persistent - memory. The third problem can be mitigated by the AS, by assigning - identifiers (e.g. 'cti') to the tokens, that include an RS identifier - and a sequence number. The RS would then just have to store the - highest sequence number of an expired token it has seen, thus - limiting the necessary state. + memory. 6.7. Combining profiles There may be use cases were different profiles of this framework are combined. For example, an MQTT-TLS profile is used between the client and the RS in combination with a CoAP-DTLS profile for interactions between the client and the AS. The security of a profile MUST NOT depend on the assumption that the profile is used for all the different types of interactions in this framework. @@ -2161,25 +2166,25 @@ obsolete profile that in turn specifies a vulnerable security mechanism via the authz-info endpoint. Such an attack would require a valid access token containing an "ace_profile" claim requesting the use of said obsolete profile. Resource Owners should update the configuration of their RS's to prevent them from using such obsolete profiles. 6.9. Identifying audiences The audience claim as defined in [RFC7519] and the equivalent - "audience" parameter from [I-D.ietf-oauth-token-exchange] are - intentionally vague on how to match the audience value to a specific - RS. This is intended to allow application specific semantics to be - used. This section attempts to give some general guidance for the - use of audiences in constrained environments. + "audience" parameter from [RFC8693] are intentionally vague on how to + match the audience value to a specific RS. This is intended to allow + application specific semantics to be used. This section attempts to + give some general guidance for the use of audiences in constrained + environments. URLs are not a good way of identifying mobile devices that can switch networks and thus be associated with new URLs. If the audience represents a single RS, and asymmetric keys are used, the RS can be uniquely identified by a hash of its public key. If this approach is used this framework RECOMMENDS to apply the procedure from section 3 of [RFC6920]. If the audience addresses a group of resource servers, the mapping of group identifier to individual RS has to be provisioned to each RS @@ -2537,26 +2542,26 @@ 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: scope o Claim Key: TBD (suggested: 9) o Claim Value Type(s): byte string or text string o Change Controller: IESG - o Specification Document(s): Section 4.2 of - [I-D.ietf-oauth-token-exchange] + o Specification Document(s): Section 4.2 of [RFC8693] 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 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: exi @@ -2588,22 +2593,22 @@ Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as CBOR map containing the protocol parameters defined in [this document]. Security considerations: See Section 6 of this document. Interoperability considerations: n/a - Published specification: [this document] + Published specification: [this document] Applications that use this media type: The type is used by authorization servers, clients and resource servers that support the ACE framework as specified in [this document]. Additional information: Magic number(s): n/a File extension(s): .ace @@ -2704,26 +2709,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-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-10 (work in progress), January 2020. - - [I-D.ietf-oauth-token-exchange] - Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. - Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- - token-exchange-19 (work in progress), July 2019. + params-11 (work in progress), January 2020. [IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", . [IANA.JsonWebTokenClaims] IANA, "JSON Web Token Claims", . @@ -2811,20 +2811,25 @@ . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, + . + 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-