--- 1/draft-ietf-ace-oauth-authz-25.txt 2019-11-19 23:14:19.533981039 -0800 +++ 2/draft-ietf-ace-oauth-authz-26.txt 2019-11-19 23:14:19.693985139 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft RISE Intended status: Standards Track G. Selander -Expires: May 2, 2020 Ericsson +Expires: May 22, 2020 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - October 30, 2019 + November 19, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-25 + draft-ietf-ace-oauth-authz-26 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 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 better serve the IoT use cases. @@ -33,21 +33,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 May 2, 2020. + This Internet-Draft will expire on May 22, 2020. Copyright Notice 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -93,93 +93,93 @@ 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 . 44 + 6.5. Minimal security requirements for communication . 45 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 - 6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 46 - 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 46 - 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 47 + 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 . . . . . . . . . . . . . . . . . . . 48 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 - 8.1. ACE Authorization Server Request Creation Hints . . . . . 49 - 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 50 - 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 50 + 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 . . . . . . . . . . . . . . . . 51 - 8.6. OAuth Access Token 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 . . . . . . . . . . . . . . . . . . 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 . . . 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 . . . . . . . . . . . . . . . . . . 54 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 58 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 58 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . 61 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 63 + Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 69 - Appendix D. Assumptions on AS knowledge about C and RS . . . . . 70 - Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 70 + 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 . . . . . . . . . . . . . . . . . 71 - E.2. Introspection Aided Token Validation . . . . . . . . . . 75 + E.2. Introspection Aided Token Validation . . . . . . . . . . 76 - Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 79 - F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 80 - F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 80 - F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 80 - F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 80 - F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 80 - F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 80 - F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 81 - F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 81 - F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 81 - F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 81 - F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 82 - F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 82 - F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 82 - F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 82 - F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 82 - F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 83 - F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 83 - F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 83 - F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 84 - F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 84 - F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 84 - F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 85 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 + 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 + F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 82 + F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 83 + F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 83 + F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 83 + F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 83 + F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 83 + F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 84 + F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 84 + F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 84 + F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 85 + F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 85 + F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 85 + F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 86 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 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. + access a generic 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. While prior work on authorization solutions for the Web and for the mobile environment also applies to the Internet of Things (IoT) environment, many IoT devices are constrained, for example, in terms of processing capabilities, available memory, etc. For web applications on constrained nodes, this specification RECOMMENDS the use of CoAP [RFC7252] as replacement for HTTP. A detailed treatment of constraints can be found in [RFC7228], and the different IoT deployments present a continuous range of device @@ -467,21 +467,26 @@ security for CoAP over a different transport in a uniform way, is to provide security at the application layer using an object-based security mechanism such as COSE [RFC8152]. One application of COSE is OSCORE [RFC8613], which provides end-to- end confidentiality, integrity and replay protection, and a secure binding between CoAP request and response messages. In OSCORE, the CoAP messages are wrapped in COSE objects and sent using CoAP. This framework RECOMMENDS the use of CoAP as replacement for HTTP for - use in constrained environments. + use in constrained environments. For communication security this + framework does not make an explicit protocol recommendation, since + the choice depends on the requirements of the specific application. + DTLS [RFC6347], [I-D.ietf-tls-dtls13] and OSCORE [RFC8613] are + mentioned as examples, other protocols fulfilling the requirements + from Section 6.5 are also applicable. 4. Protocol Interactions The ACE framework is based on the OAuth 2.0 protocol interactions using the token endpoint and optionally the introspection endpoint. A client obtains an access token, and optionally a refresh token, from an AS using the token endpoint and subsequently presents the access token to a RS to gain access to a protected resource. In most deployments the RS can process the access token locally, however in some cases the RS may present it to the AS via the introspection @@ -646,22 +651,22 @@ The following sections detail the profiling and extensions of OAuth 2.0 for constrained environments, which constitutes the ACE framework. Credential Provisioning For IoT, it cannot be assumed that the client and RS are part of a 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 be re-used by binding these credentials to - additional access tokens. + 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. @@ -1817,27 +1822,30 @@ introspection request as specified in Section 5.7. This requires the RS to have a reliable network connection to the AS and to be able to handle two secure sessions in parallel (C to RS and RS to AS). o In order to support token expiration for devices that have no reliable way of synchronizing their internal clocks, this specification defines the following approach: The claim "exi" ("expires in") can be used, to provide the RS with the lifetime of the token in seconds from the time the RS first receives the - token. This approach is of course vulnerable to malicious clients - holding back tokens they do not want to expire. Such an attack - can only be prevented if the RS is able to communicate with the AS - in some regular intervals, so that the can AS provide the RS with - a list of expired tokens. The drawback of this mitigation is that - the RS might as well use the communication with the AS to - synchronize its internal clock. + token. 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). 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 @@ -1980,27 +1988,31 @@ that include securely erasing credentials and other security critical material in the devices being decommissioned. 6.4. Unprotected AS Request Creation Hints Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. It is therefore advisable to provide C with a (possibly hard-coded) list of - trustworthy authorization servers. AS Request Creation Hints - referring to a URI not listed there would be ignored. + trustworthy authorization servers, possibly including information + used to authenticate the AS, such as a public key or certificate + fingerprint. AS Request Creation Hints referring to a URI not listed + there would be ignored. A compromised RS may use the hints to trick a client into contacting an AS that is not supposed to be in charge of that RS. Since this AS must be in the hard-coded list of trusted AS no violation of - privileges and or exposure of redentials should happen. However a + privileges and or exposure of credentials should happen, since a + trusted AS is expected to refuse requestes for which it is not + applicable and render a corresponding error response. However a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. A compromised client can be made to contact any AS, including compromised ones. This should not affect the RS, since it is supposed to keep track of which AS are trusted and have corresponding credentials to verify the source of access tokens it receives. 6.5. Minimal security requirements for communication @@ -2061,29 +2073,42 @@ compromised. In order to prevent this, an RS may use the nonce-based mechanism defined in Section 5.1.2 to ensure freshness of an Access Token subsequently presented to this RS. Another problem with clock drift is that evaluating the standard token expiration claim "exp" can give unpredictable results. The expiration mechanism implemented by the "exi" claim, based on the first time the RS sees the token was defined to provide a more predictable alternative. The "exi" approach has some drawbacks that - need to be considered: First a malicious client may hold back tokens - with the "exi" claim in order to prolong their lifespan, and second - if an RS loses state (e.g. due to an unscheduled reboot), it looses - the current values of counters tracking the "exi" claims of tokens it - is storing. 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. + 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 a 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. 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. @@ -2108,20 +2133,29 @@ authentication). In cases where this is not possible this framework RECOMMENDS to use encrypted CWTs or tokens that are opaque references and need to be subjected to introspection by the RS. If the initial unauthorized resource request message (see Section 5.1.1) is used, the client MUST make sure that it is not sending sensitive content in this request. While GET and DELETE requests only reveal the target URI of the resource, POST and PUT requests would reveal the whole payload of the intended operation. + Since the client is not authenticated at the point when it is + submitting an access token to the authz-info endpoint, attackers may + be pretending to be a client and trying to trick an RS to use an + obsole profile that in turn specifies a vulnerable security mechanism + via the authz-info endpoint. Such an attack would require a valid + access token containing a "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. URLs are not a good way of identifying mobile devices that can switch @@ -2647,21 +2679,21 @@ 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-09 (work in progress), October 2019. + 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-05 (work in progress), March 2019. [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. @@ -2698,20 +2730,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, . + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, + . + [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, @@ -2791,24 +2827,20 @@ "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 Version 5.0", OASIS Standard, March 2019, . - [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", - FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, - . - [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth