--- 1/draft-ietf-ace-oauth-authz-23.txt 2019-03-27 03:13:50.856001708 -0700 +++ 2/draft-ietf-ace-oauth-authz-24.txt 2019-03-27 03:13:51.012005778 -0700 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft RISE Intended status: Standards Track G. Selander -Expires: September 26, 2019 Ericsson +Expires: September 28, 2019 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - March 25, 2019 + March 27, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-23 + draft-ietf-ace-oauth-authz-24 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 making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are @@ -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 September 26, 2019. + This Internet-Draft will expire on September 28, 2019. 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 @@ -70,103 +70,103 @@ 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.1.1. Unauthorized Resource Request Message . . . . . . . . 16 5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 17 5.1.2.1. The Client-Nonce Parameter . . . . . . . . . . . 19 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 20 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 21 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 21 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22 - 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 24 - 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 26 - 5.6.4. Request and Response Parameters . . . . . . . . . . . 27 - 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 27 + 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25 + 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 27 + 5.6.4. Request and Response Parameters . . . . . . . . . . . 28 + 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 28 - 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 28 + 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29 5.6.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 29 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 29 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 30 - 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 30 - 5.7.2. Introspection Response . . . . . . . . . . . . . . . 31 - 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32 - 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33 + 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 31 + 5.7.2. Introspection Response . . . . . . . . . . . . . . . 32 + 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 33 + 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 34 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 34 - 5.8.1. The Authorization Information Endpoint . . . . . . . 34 - 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35 + 5.8.1. The Authorization Information Endpoint . . . . . . . 35 + 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 36 5.8.1.2. Protecting the Authorization Information - Endpoint . . . . . . . . . . . . . . . . . . . . 37 + Endpoint . . . . . . . . . . . . . . . . . . . . 38 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 38 - 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38 - 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 39 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 - 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41 - 6.2. Minimal security requirements for communication . 41 - 6.3. Use of Nonces for Token Freshness . . . . . . . . . . . . 42 - 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 43 - 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 43 - 6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43 - 6.7. Denial of service against or with Introspection . . 44 - 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 - 8.1. ACE Authorization Server Request Creation Hints . . . . . 45 - 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46 - 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46 - 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 47 - 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47 - 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 48 - 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48 - 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48 - 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49 - 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49 - 8.10. OAuth Introspection Response Parameter Registration . . . 50 - 8.11. OAuth Token Introspection Response CBOR Mappings Registry 50 - 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50 - 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51 - 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 52 - 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 53 - 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 55 - 10.2. Informative References . . . . . . . . . . . . . . . . . 57 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 59 - Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 63 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 65 - Appendix D. Assumptions on AS knowledge about C and RS . . . . . 66 - Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 66 - E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66 - E.2. Introspection Aided Token Validation . . . . . . . . . . 71 - Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 75 - F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 75 - F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 75 - F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 75 - F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 76 - F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 76 - F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 76 - F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 77 - F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 77 - F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 77 - F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 77 - F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 77 - F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 78 - F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 78 - F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 78 - F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 78 - F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 79 - F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 79 - F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 79 - F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 79 - F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 79 - F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 80 - F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 80 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 + 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 39 + 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 40 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 + 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 42 + 6.2. Minimal security requirements for communication . 42 + 6.3. Use of Nonces for Token Freshness . . . . . . . . . . . . 43 + 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 44 + 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 44 + 6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 44 + 6.7. Denial of service against or with Introspection . . 45 + 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 46 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 + 8.1. ACE Authorization Server Request Creation Hints . . . . . 46 + 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 47 + 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 47 + 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 48 + 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 48 + 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 49 + 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 49 + 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 49 + 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 50 + 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 50 + 8.10. OAuth Introspection Response Parameter Registration . . . 51 + 8.11. OAuth Token Introspection Response CBOR Mappings Registry 51 + 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 51 + 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 52 + 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 53 + 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 54 + 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 54 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 56 + 10.2. Informative References . . . . . . . . . . . . . . . . . 58 + Appendix A. Design Justification . . . . . . . . . . . . . . . . 60 + Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 64 + Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 66 + Appendix D. Assumptions on AS knowledge about C and RS . . . . . 67 + Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 67 + E.1. Local Token Validation . . . . . . . . . . . . . . . . . 67 + E.2. Introspection Aided Token Validation . . . . . . . . . . 72 + Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 76 + F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 76 + F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 76 + F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 76 + F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 77 + F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 77 + F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 77 + F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 78 + F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 78 + F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 78 + F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 78 + F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 78 + F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 79 + F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 79 + F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 79 + F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 79 + F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 80 + F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 80 + F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 80 + F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 80 + F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 80 + F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 81 + F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 81 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 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. @@ -988,20 +988,24 @@ 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. + o The client can send an empty (null value) "profile" parameter to + indicate that it wants the AS to include the "profile" parameter + in the response. See Section 5.6.4.3. + o A client MUST be able to use the parameters from [I-D.ietf-ace-oauth-params] in an access token request to the token endpoint and the AS MUST be able to process these additional parameters. If CBOR is used then these parameters MUST be encoded as a CBOR map. When HTTP is used as a transport then the client makes a request to the token endpoint by sending the parameters using the "application/ x-www-form-urlencoded" format with a character encoding of UTF-8 in @@ -1107,24 +1111,26 @@ knowledge of the capabilities of the client and the RS (see Appendix D). This prior knowledge may, for example, be set by the use of a dynamic client registration protocol exchange [RFC7591]. The content of the successful reply is the Access Information. When using CBOR payloads, the content MUST be encoded as CBOR map, containing parameters as specified in Section 5.1 of [RFC6749], with the following additions and changes: profile: - OPTIONAL. This indicates the profile that the client MUST use - towards the RS. See Section 5.6.4.3 for the formatting of this - parameter. If this parameter is absent, the AS assumes that the - client implicitly knows which profile to use towards the RS. + OPTIONAL unless the request included an empty profile parameter in + which case it is MANDATORY. This indicates the profile that the + client MUST use towards the RS. See Section 5.6.4.3 for the + formatting of this parameter. If this parameter is absent, the AS + assumes that the client implicitly knows which profile to use + towards the RS. token_type: This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]. By default implementations of this framework SHOULD assume that the token_type is "pop". If a specific use case requires another token_type (e.g., "Bearer") to be used then this parameter is REQUIRED. Furthermore [I-D.ietf-ace-oauth-params] defines additional parameters that the AS MUST be able to use when responding to a request to the @@ -1284,20 +1290,24 @@ A profile MUST specify an identifier that MUST be used to uniquely identify itself in the "profile" parameter. The textual representation of the profile identifier is just intended for human readability and MUST NOT be used in parameters and claims. 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 "profile" parameter + in the access token response can indicate that by sending a profile + parameter with a null value in the access token request. + 5.6.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.1.2. The parameter is encoded as a byte string and copies the value from the cnonce parameter in the AS Request Creation Hints. 5.6.5. Mapping Parameters to CBOR