--- 1/draft-ietf-ace-oauth-authz-37.txt 2021-03-22 13:23:41.153232061 -0700 +++ 2/draft-ietf-ace-oauth-authz-38.txt 2021-03-22 13:23:41.321236239 -0700 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft Combitech Intended status: Standards Track G. Selander -Expires: August 8, 2021 Ericsson +Expires: September 9, 2021 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - February 4, 2021 + March 8, 2021 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-37 + draft-ietf-ace-oauth-authz-38 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 August 8, 2021. + This Internet-Draft will expire on September 9, 2021. 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 @@ -68,26 +68,26 @@ 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.2. Unauthorized Resource Request Message . . . . . . . . . . 17 5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17 5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19 5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20 5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21 5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21 5.7. The Authorization Endpoint . . . . . . . . . . . . . . . 21 - 5.8. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21 + 5.8. The Token Endpoint . . . . . . . . . . . . . . . . . . . 22 5.8.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22 5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25 5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27 5.8.4. Request and Response Parameters . . . . . . . . . . . 28 - 5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28 + 5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 29 5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29 5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29 5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30 5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30 5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31 5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32 5.9.2. Introspection Response . . . . . . . . . . . . . . . 33 5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34 5.9.4. Mapping Introspection parameters to CBOR . . . . . . 35 5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35 @@ -126,23 +126,23 @@ 8.12. OAuth Token Introspection Response CBOR Mappings Registry 55 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57 8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . 62 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 + Appendix A. Design Justification . . . . . . . . . . . . . . . . 65 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 + Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 72 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72 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 @@ -272,21 +272,21 @@ protocols are not prohibited from being supported in the future, such as HTTP/2 [RFC7540], Message Queuing Telemetry Transport (MQTT) [MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC [I-D.ietf-quic-transport]. Note that this document specifies protocol exchanges in terms of RESTful verbs such as GET and POST. Future profiles using protocols that do not support these verbs MUST specify how the corresponding protocol messages are transmitted instead. A third building block is the Concise Binary Object Representation - (CBOR) [RFC7049], for encodings where JSON [RFC8259] is not + (CBOR) [RFC8949], for encodings where JSON [RFC8259] is not sufficiently compact. CBOR is a binary encoding designed for small code and message size, which may be used for encoding of self contained tokens, and also for encoding payloads transferred in protocol messages. A fourth building block is CBOR Object Signing and Encryption (COSE) [RFC8152], which enables object-level layer security as an alternative or complement to transport layer security (DTLS [RFC6347] or TLS [RFC8446]). COSE is used to secure self-contained tokens such as proof-of-possession (PoP) tokens, which are an extension to the @@ -693,39 +693,48 @@ communications named above are encrypted, integrity protected and protected against message replay. It is also REQUIRED that the communicating endpoints perform mutual authentication. Furthermore it MUST be assured that responses are bound to the requests in the sense that the receiver of a response can be certain that the response actually belongs to a certain request. Note that setting up such a secure communication may require some unprotected messages to be exchanged first (e.g. sending the token from the client to the RS). - Profiles MUST specify a communication security protocol that provides - the features required above. + Profiles MUST specify a communication security protocol between + client and RS that provides the features required above. Profiles + MUST specify a communication security protocol RECOMMENDED to be used + between client and AS that provides the features required above. + Profiles MUST specify for introspection a communication security + protocol RECOMMENDED to be used between RS and AS that provides the + features required above. These recommendations enable + interoperability between different implementations without the need + to define a new profile if the communication between C and AS, or + between RS and AS, is protected with a different security protocol + complying with the security requirements above. In OAuth 2.0 the communication with the Token and the Introspection endpoints at the AS is assumed to be via HTTP and may use Uri-query parameters. When profiles of this framework use CoAP instead, it is REQUIRED to use of the following alternative instead of Uri-query parameters: The sender (client or RS) encodes the parameters of its request as a CBOR map and submits that map as the payload of the POST request. Profiles that use CBOR encoding of protocol message parameters at the outermost encoding layer MUST use the media format 'application/ ace+cbor'. If CoAP is used for communication, the Content-Format MUST be abbreviated with the ID: 19 (see Section 8.16). The OAuth 2.0 AS uses a JSON structure in the payload of its responses both to client and RS. If CoAP is used, it is REQUIRED to - use CBOR [RFC7049] instead of JSON. Depending on the profile, the + use CBOR [RFC8949] instead of JSON. Depending on the profile, the CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper. 5.1. Discovering Authorization Servers C must discover the AS in charge of RS to determine where to request the access token. To do so, C must 1. find out the AS URI to which the token request message must be sent and 2. MUST validate that the AS with this URI is authorized to provide access tokens for this RS. In order to determine the AS URI, C MAY send an initial Unauthorized @@ -810,21 +819,21 @@ Figure 2: AS Request Creation Hints Note that the schema part of the AS parameter may need to be adapted to the security protocol that is used between the client and the AS. Thus the example AS value "coap://as.example.com/token" might need to be transformed to "coaps://as.example.com/token". It is assumed that the client can determine the correct schema part on its own depending on the way it communicates with the AS. Figure 3 shows an example for an AS Request Creation Hints message - payload using CBOR [RFC7049] diagnostic notation, using the parameter + payload using CBOR [RFC8949] diagnostic notation, using the parameter names instead of the CBOR keys for better human readability. 4.01 Unauthorized Content-Format: application/ace+cbor Payload : { "AS" : "coaps://as.example.com/token", "audience" : "coaps://rs.example.com" "scope" : "rTempC", "cnonce" : h'e0a156bb3f' @@ -1962,22 +1971,22 @@ further standardization work that is out of scope for this document. 6.2. Communication Security Communication with the authorization server MUST use confidentiality protection. This step is extremely important since the client or the RS may obtain the proof-of-possession key from the authorization server for use with a specific access token. Not using confidentiality protection exposes this secret (and the access token) to an eavesdropper thereby completely negating proof-of-possession - security. Profiles MUST specify how communication security according - to the requirements in Section 5 is provided. + security. The requirements for communication security of profiles + are specified in Section 5. Additional protection for the access token can be applied by encrypting it, for example encryption of CWTs is specified in Section 5.1 of [RFC8392]. Such additional protection can be necessary if the token is later transferred over an insecure connection (e.g. when it is sent to the authz-info endpoint). Developers MUST ensure that the ephemeral credentials (i.e., the private key or the session key) are not leaked to third parties. An adversary in possession of the ephemeral credentials bound to the @@ -2771,24 +2780,20 @@ [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, @@ -2798,24 +2803,20 @@ [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, . - [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object - Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, - October 2013, . - [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", @@ -2842,20 +2843,25 @@ [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, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . + [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 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- @@ -2878,20 +2884,24 @@ "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 @@ -3055,21 +3065,21 @@ not limited to them. Other protocols such as HTTP, or even protocols such as Bluetooth Smart communication that do not necessarily use IP, could also be used. The latter raises the need for application layer security over the various interfaces. In the light of these constraints we have made the following design decisions: CBOR, COSE, CWT: - This framework RECOMMENDS the use of CBOR [RFC7049] as data + This framework RECOMMENDS the use of CBOR [RFC8949] as data format. Where CBOR data needs to be protected, the use of COSE [RFC8152] is RECOMMENDED. Furthermore, where self-contained tokens are needed, this framework RECOMMENDS the use of CWT [RFC8392]. These measures aim at reducing the size of messages sent over the wire, the RAM size of data objects that need to be kept in memory and the size of libraries that devices need to support. CoAP: