--- 1/draft-ietf-ace-oauth-authz-26.txt 2019-11-20 19:13:12.731959688 -0800 +++ 2/draft-ietf-ace-oauth-authz-27.txt 2019-11-20 19:13:12.895963904 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft RISE Intended status: Standards Track G. Selander -Expires: May 22, 2020 Ericsson +Expires: May 24, 2020 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - November 19, 2019 + November 21, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-26 + draft-ietf-ace-oauth-authz-27 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 22, 2020. + This Internet-Draft will expire on May 24, 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,83 +93,83 @@ 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 . . . . . . . . . . . . . . . . . . 44 + 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43 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.7. Combining profiles . . . . . . . . . . . . . . . . . . . 46 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 - 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48 + 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 47 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.2. OAuth Extensions Error Registration . . . . . . . . . . . 50 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.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 52 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 67 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 - Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 + Appendix D. Assumptions on AS knowledge about C and RS . . . . . 70 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71 - E.2. Introspection Aided Token Validation . . . . . . . . . . 76 + E.2. Introspection Aided Token Validation . . . . . . . . . . 75 - 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 + 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 1. Introduction Authorization is the process for granting approval to an entity to 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. @@ -1842,46 +1842,43 @@ 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 - by the RS to authenticate towards the client. Since there is no - metadata associated to those keys, the client has no way of knowing - if these keys are still valid. This may lead to situations where the - client sends requests containing sensitive information to the RS - using a key that is expired and possibly in the hands of an attacker, - or accepts responses from the RS that are not properly protected and - could possibly have been forged by an attacker. + by the RS to authenticate towards the client. Since there is + currently no expiration metadata associated to those keys, the client + has no way of knowing if these keys are still valid. This may lead + to situations where the client sends requests containing sensitive + information to the RS using a key that is expired and possibly in the + hands of an attacker, or accepts responses from the RS that are not + properly protected and could possibly have been forged by an + attacker. In order to prevent this, the client must assume that those keys are only valid as long as the related access token is. Since the access token is opaque to the client, one of the following methods MUST be used to inform the client about the validity of an access token: o The client knows a default validity time for all tokens it is using (i.e. how long a token is valid after being issued). This information could be provisioned to the client when it is registered at the AS, or published by the AS in a way that the client can query. o The AS informs the client about the token validity using the "expires_in" parameter in the Access Information. - o The client performs an introspection of the token. Although this - is not explicitly forbidden, how exactly a client does - introspection is not currently specified for OAuth. - A client that is not able to obtain information about the expiration of a token MUST NOT use this token. 6. Security Considerations Security considerations applicable to authentication and authorization in RESTful environments provided in OAuth 2.0 [RFC6749] apply to this work. Furthermore [RFC6819] provides additional security considerations for OAuth which apply to IoT deployments as well. If the introspection endpoint is used, the security @@ -2684,21 +2683,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-05 (work in progress), March 2019. + params-06 (work in progress), November 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. [IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", . @@ -2805,27 +2804,27 @@ . [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-23 (work - in progress), September 2019. + and Secure Transport", draft-ietf-quic-transport-24 (work + in progress), November 2019. [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-33 (work in progress), October + 1.3", draft-ietf-tls-dtls13-34 (work in progress), November 2019. [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.