--- 1/draft-ietf-ace-oauth-authz-10.txt 2018-03-19 06:13:30.154226160 -0700 +++ 2/draft-ietf-ace-oauth-authz-11.txt 2018-03-19 06:13:30.282229197 -0700 @@ -1,94 +1,96 @@ ACE Working Group L. Seitz Internet-Draft RISE SICS Intended status: Standards Track G. Selander -Expires: August 17, 2018 Ericsson +Expires: September 20, 2018 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig ARM Ltd. - February 13, 2018 + March 19, 2018 Authentication and Authorization for Constrained Environments (ACE) - draft-ietf-ace-oauth-authz-10 + using the OAuth 2.0 Framework (ACE-OAuth) + draft-ietf-ace-oauth-authz-11 Abstract This specification defines a framework for authentication and - authorization in Internet of Things (IoT) environments. 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 defined. + 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 + defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 17, 2018. + This Internet-Draft will expire on September 20, 2018. Copyright Notice Copyright (c) 2018 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 - 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.1. Discovering Authorization Servers . . . . . . . . . . . . 14 + 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 5.1. Discovering Authorization Servers . . . . . . . . . . . . 15 5.1.1. Unauthorized Resource Request Message . . . . . . . . 15 - 5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 15 + 5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17 - 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 17 + 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 18 - 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 18 + 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 19 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 22 - 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 24 + 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 25 5.6.4. Request and Response Parameters . . . . . . . . . . . 25 - 5.6.4.1. Audience . . . . . . . . . . . . . . . . . . . . 25 - 5.6.4.2. Grant Type . . . . . . . . . . . . . . . . . . . 25 + 5.6.4.1. Audience . . . . . . . . . . . . . . . . . . . . 26 + 5.6.4.2. Grant Type . . . . . . . . . . . . . . . . . . . 26 5.6.4.3. Token Type . . . . . . . . . . . . . . . . . . . 26 - 5.6.4.4. Profile . . . . . . . . . . . . . . . . . . . . . 26 - 5.6.4.5. Confirmation . . . . . . . . . . . . . . . . . . 26 + 5.6.4.4. Profile . . . . . . . . . . . . . . . . . . . . . 27 + 5.6.4.5. Confirmation . . . . . . . . . . . . . . . . . . 27 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27 5.7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 28 5.7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 29 5.7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 29 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 32 5.8.1. The 'Authorization Information' Endpoint . . . . . . 32 5.8.2. Token Expiration . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 @@ -102,46 +104,47 @@ 8.2. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 37 8.3. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 38 8.4. OAuth Access Token Types . . . . . . . . . . . . . . . . 38 8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 38 8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39 8.6. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 39 8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 39 8.8. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 40 8.9. OAuth Introspection Response Parameter Registration . . . 41 8.10. Introspection Endpoint CBOR Mappings Registry . . . . . . 41 - 8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42 + 8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 41 8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42 8.13. CoAP Option Number Registration . . . . . . . . . . . . . 42 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.1. Normative References . . . . . . . . . . . . . . . . . . 43 10.2. Informative References . . . . . . . . . . . . . . . . . 44 Appendix A. Design Justification . . . . . . . . . . . . . . . . 46 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 50 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 52 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 53 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 53 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 53 E.2. Introspection Aided Token Validation . . . . . . . . . . 57 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 61 - F.1. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 61 - F.2. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 61 - F.3. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 62 - F.4. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 62 - F.5. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 62 - F.6. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 62 - F.7. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 63 - F.8. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 63 - F.9. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 63 - F.10. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 64 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 + F.1. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 61 + F.2. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 61 + F.3. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 61 + F.4. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 62 + F.5. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 62 + F.6. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 62 + F.7. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 63 + F.8. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 63 + F.9. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 63 + F.10. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 63 + F.11. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 64 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 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. @@ -177,22 +180,23 @@ interoperable. Some devices, such as mobile phones and tablets, may implement multiple profiles and will therefore be able to interact with a wider range of low end devices. Requirements on profiles are described at contextually appropriate places throughout this specification, and also summarized in Appendix C. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from [RFC4949]. Since exchanges in this specification are described as RESTful protocol interactions, HTTP [RFC7231] offers useful terminology. Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource @@ -234,21 +238,21 @@ Another building block is the lightweight web transfer protocol CoAP [RFC7252], for those communication environments where HTTP is not appropriate. CoAP typically runs on top of UDP, which further reduces overhead and message exchanges. While this specification defines extensions for the use of OAuth over CoAP, other underlying protocols are not prohibited from being supported in the future, such as HTTP/2, MQTT, BLE and QUIC. A third building block is CBOR [RFC7049], for encodings where JSON - [RFC7159] is not sufficiently compact. CBOR is a binary encoding + [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 payload transferred in protocol messages. A fourth building block is the compact CBOR-based secure message format COSE [RFC8152], which enables application layer security as an alternative or complement to transport layer security (DTLS [RFC6347] or TLS [RFC5246]). COSE is used to secure self-contained tokens such as proof-of-possession (PoP) tokens, which is an extension to the OAuth tokens. The default token format is defined in CBOR web token @@ -1100,31 +1100,31 @@ where a response code equivalent to the CoAP code 4.01 (Unauthorized) MAY be used under the same conditions as specified in Section 5.2 of [RFC6749]. o The parameters "error", "error_description" and "error_uri" MUST be abbreviated using the codes specified in Figure 12, when a CBOR encoding is used. o The error code (i.e., value of the "error" parameter) MUST be abbreviated as specified in Figure 10, when a CBOR encoding is used. - /------------------------+----------\ - | Name | CBOR Key | - |------------------------+----------| + /------------------------+-------------\ + | Name | CBOR Values | + |------------------------+-------------| | invalid_request | 0 | | invalid_client | 1 | | invalid_grant | 2 | | unauthorized_client | 3 | | unsupported_grant_type | 4 | | invalid_scope | 5 | | unsupported_pop_key | 6 | - \------------------------+----------/ + \------------------------+-------------/ Figure 10: CBOR abbreviations for common error codes In addition to the error responses defined in OAuth 2.0, the following behavior MUST be implemented by the AS: If the client submits an asymmetric key in the token request that the RS cannot process, the AS MUST reject that request with a response code equivalent to the CoAP code 4.00 (Bad Request) including the error code "unsupported_pop_key" defined in Figure 10. @@ -1142,28 +1142,28 @@ application specific. When encoded as a CBOR payload it is represented as a CBOR text string. 5.6.4.2. Grant Type The abbreviations in Figure 11 MUST be used in CBOR encodings instead of the string values defined in [RFC6749], if CBOR payloads are used. - /--------------------+----------+------------------------\ - | Name | CBOR Key | Original Specification | - |--------------------+----------+------------------------| + /--------------------+------------+------------------------\ + | Name | CBOR Value | Original Specification | + |--------------------+------------+------------------------| | password | 0 | RFC6749 | | authorization_code | 1 | RFC6749 | | client_credentials | 2 | RFC6749 | | refresh_token | 3 | RFC6749 | - \--------------------+----------+------------------------/ + \--------------------+------------+------------------------/ Figure 11: CBOR abbreviations for common grant types 5.6.4.3. Token Type The token_type parameter is defined in [RFC6749], allowing the AS to indicate to the client which type of access token it is receiving (e.g., a bearer token). This document registers the new value "pop" for the OAuth Access @@ -1233,32 +1233,32 @@ | Name | CBOR Key | Value Type | |-------------------+----------+---------------------| | aud | 3 | text string | | client_id | 8 | text string | | client_secret | 9 | byte string | | response_type | 10 | text string | | redirect_uri | 11 | text string | | scope | 12 | text or byte string | | state | 13 | text string | | code | 14 | byte string | - | error | 15 | text string | + | error | 15 | unsinged integer | | error_description | 16 | text string | | error_uri | 17 | text string | | grant_type | 18 | unsigned integer | - | access_token | 19 | text string | + | access_token | 19 | byte string | | token_type | 20 | unsigned integer | | expires_in | 21 | unsigned integer | | username | 22 | text string | | password | 23 | text string | - | refresh_token | 24 | text string | + | refresh_token | 24 | byte string | | cnf | 25 | map | - | profile | 26 | text string | + | profile | 26 | unsigned integer | | rs_cnf | 31 | map | \-------------------+----------+---------------------/ Figure 12: CBOR mappings used in token requests 5.7. The 'Introspect' Endpoint Token introspection [RFC7662] can be OPTIONALLY provided by the AS, and is then used by the RS and potentially the client to query the AS for metadata about a given token e.g., validity or scope. Analogous @@ -1389,42 +1389,41 @@ 5.7.4. Mapping Introspection parameters to CBOR The introspection request and response parameters MUST be mapped to CBOR types as specified in Figure 15, using the given integer abbreviation for the key. Note that we have aligned these abbreviations with the claim abbreviations defined in [I-D.ietf-ace-cbor-web-token]. - /-----------------+----------+-----------------------\ + /-----------------+----------+----------------------------------\ | Parameter name | CBOR Key | Value Type | - |-----------------+----------+-----------------------| + |-----------------+----------+----------------------------------| | iss | 1 | text string | | sub | 2 | text string | | aud | 3 | text string | - | exp | 4 | Epoch-based date/time | - | nbf | 5 | Epoch-based date/time | - | iat | 6 | Epoch-based date/time | + | exp | 4 | integer or floating-point number | + | nbf | 5 | integer or floating-point number | + | iat | 6 | integer or floating-point number | | cti | 7 | byte string | | client_id | 8 | text string | | scope | 12 | text OR byte string | | token_type | 20 | text string | | username | 22 | text string | | cnf | 25 | map | | profile | 26 | unsigned integer | - | token | 27 | text string | + | token | 27 | byte string | | token_type_hint | 28 | text string | - | active | 29 | unsigned integer | - | client_token | 30 | byte string | - | rs_cnf | 31 | map | - \-----------------+----------+-----------------------/ + | active | 29 | True or False | + | rs_cnf | 30 | map | + \-----------------+----------+----------------------------------/ Figure 15: CBOR Mappings to Token Introspection Parameters. 5.8. The Access Token This framework RECOMMENDS the use of CBOR web token (CWT) as specified in [I-D.ietf-ace-cbor-web-token]. In order to facilitate offline processing of access tokens, this draft uses the "cnf" claim from @@ -1692,21 +1691,21 @@ 8.2. OAuth Error Code CBOR Mappings Registry A new registry will be requested from IANA, entitled "OAuth Error Code CBOR Mappings Registry". The registry is to be created as Expert Review Required. The columns of this table are: Name The OAuth Error Code name, refers to the name in Section 5.2. of [RFC6749] e.g., "invalid_request". - CBOR Key The unsigned integer value abbreviating this error code. + CBOR Value The unsigned integer value abbreviating this error code. Registration in the table is based on the value of the mapping requested. Integer values between 1 and 255 are designated as Standards Track Document required. Integer values from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as private use. Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 10. @@ -1715,21 +1714,21 @@ 8.3. OAuth Grant Type CBOR Mappings A new registry will be requested from IANA, entitled "OAuth Grant Type CBOR Mappings". The registry is to be created as Expert Review Required. The columns of this table are: Name The name of the grant type as specified in Section 1.3 of [RFC6749]. - CBOR Key The unsigned integer value abbreviating this grant type. + CBOR Value The unsigned integer value abbreviating this grant type. Registration in the table is based on the value of the mapping requested. Integer values between 1 and 255 are designated as Standards Track Document required. Integer values from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as private use. Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. Original Specification This contains a pointer to the public specification of the grant type, if one exists. @@ -1748,21 +1747,21 @@ 8.5. OAuth Token Type CBOR Mappings A new registry will be requested from IANA, entitled "Token Type CBOR Mappings". The registry is to be created as Expert Review Required. The columns of this table are: Name The name of token type as registered in the OAuth Access Token Types registry e.g., "Bearer". - CBOR Key The unsigned integer value abbreviating this access token + CBOR Value The unsigned integer value abbreviating this access token type. Registration in the table is based on the value of the mapping requested. Integer values between 1 and 255 are designated as Standards Track Document required. Integer values from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as private use. Reference This contains a pointer to the public specification of the OAuth token type abbreviation, if one exists. Original Specification This contains a pointer to the public specification of the grant type, if one exists. @@ -1782,26 +1781,26 @@ A new registry will be requested from IANA, entitled "ACE Profile Registry". The registry is to be created as Expert Review Required. The columns of this table are: Name The name of the profile, to be used as value of the profile attribute. Description Text giving an overview of the profile and the context it is developed for. - CBOR Key The unsigned integer value abbreviating this profile name. - Registration in the table is based on the value of the mapping - requested. Integer values between 1 and 255 are designated as - Standards Track Document required. Integer values from 256 to - 65535 are designated as Specification Required. Integer values - greater than 65535 are designated as private use. + CBOR Value The unsigned integer value abbreviating this profile + name. Registration in the table is based on the value of the + mapping requested. Integer values between 1 and 255 are + designated as Standards Track Document required. Integer values + from 256 to 65535 are designated as Specification Required. + Integer values greater than 65535 are designated as private use. Reference This contains a pointer to the public specification of the profile abbreviation, if one exists. 8.7. OAuth Parameter Registration This specification registers the following parameters in the OAuth Parameters Registry: o Name: "aud" o Parameter Usage Location: authorization request, token request @@ -1859,26 +1858,20 @@ o Description: Key to prove the right to use a PoP token. o Change Controller: IESG o Reference: Section 5.7.2 of [this document] o Name: "profile" o Description: The communication and communication security profile used between client and RS, as defined in ACE profiles. o Change Controller: IESG o Reference: Section 5.7.2 of [this document] - o Name: "client_token" - o Description: Information that the RS MUST pass to the client e.g., - about the proof-of-possession keys. - o Change Controller: IESG - o Reference: Section 5.7.2 of [this document] - 8.10. Introspection Endpoint CBOR Mappings Registry A new registry will be requested from IANA, entitled "Introspection Endpoint CBOR Mappings Registry". The registry is to be created as Expert Review Required. The columns of this table are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry e.g., "client_id". @@ -1955,28 +1949,28 @@ Ludwig Seitz and Goeran Selander worked on this document as part of the CelticPlus project CyberWI, with funding from Vinnova. 10. References 10.1. Normative References [I-D.ietf-ace-cbor-web-token] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, - "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-12 - (work in progress), February 2018. + "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-14 + (work in progress), March 2018. [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt- - proof-of-possession-01 (work in progress), October 2017. + proof-of-possession-02 (work in progress), March 2018. [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, . @@ -1996,54 +1990,58 @@ [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 10.2. Informative References [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-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An architecture for authorization in constrained environments", draft-ietf-ace-actors-06 (work in progress), November 2017. [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments - (OSCORE)", draft-ietf-core-object-security-08 (work in - progress), January 2018. + (OSCORE)", draft-ietf-core-object-security-10 (work in + progress), March 2018. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", draft-ietf-core- - resource-directory-12 (work in progress), October 2017. + resource-directory-13 (work in progress), March 2018. [I-D.ietf-oauth-device-flow] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Flow for Browserless and Input Constrained Devices", draft-ietf-oauth-device-flow-07 (work in progress), October 2017. [I-D.ietf-oauth-discovery] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", draft-ietf-oauth- - discovery-08 (work in progress), November 2017. + discovery-10 (work in progress), March 2018. [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), 2010 August. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", @@ -2065,24 +2063,20 @@ [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, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . - [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data - Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March - 2014, . - [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . @@ -2113,20 +2107,25 @@ [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, . + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, . + Appendix A. Design Justification This section provides further insight into the design decisions of the solution documented in this document. Section 3 lists several building blocks and briefly summarizes their importance. The justification for offering some of those building blocks, as opposed to using OAuth 2.0 as is, is given below. Common IoT constraints are: @@ -2805,40 +2804,48 @@ | | Payload: | | F: |<--------+ Header: 2.04 Changed | 2.04 | Payload: | | Figure 25: Resource request and response protected by OSCOAP Appendix F. Document Updates -F.1. Version -09 to -10 + RFC EDITOR: PLEASE REMOVE THIS SECTION. + +F.1. Version -10 to -11 + + o Fixed some CBOR data type errors. + o Updated boilerplate text + +F.2. Version -09 to -10 o Removed CBOR major type numbers. o Removed the client token design. o Rephrased to clarify that other protocols than CoAP can be used. o Clarifications regarding the use of HTTP -F.2. Version -08 to -09 +F.3. Version -08 to -09 o Allowed scope to be byte arrays. o Defined default names for endpoints. o Refactored the IANA section for briefness and consistency. o Refactored tables that define IANA registry contents for consistency. o Created IANA registry for CBOR mappings of error codes, grant types and Authorization Server Information. + o Added references to other document sections defining IANA entries in the IANA section. -F.3. Version -07 to -08 +F.4. Version -07 to -08 o Moved AS discovery from the DTLS profile to the framework, see Section 5.1. o Made the use of CBOR mandatory. If you use JSON you can use vanilla OAuth. o Made it mandatory for profiles to specify C-AS security and RS-AS security (the latter only if introspection is supported). o Made the use of CBOR abbreviations mandatory. o Added text to clarify the use of token references as an alternative to CWTs. @@ -2852,40 +2859,39 @@ o Added text that clarifies that introspection is optional. o Made profile parameter optional since it can be implicit. o Clarified that CoAP is not mandatory and other protocols can be used. o Clarified the design justification for specific features of the framework in appendix A. o Clarified appendix E.2. o Removed specification of the "cnf" claim for CBOR/COSE, and replaced with references to [I-D.ietf-ace-cwt-proof-of-possession] -F.4. Version -06 to -07 +F.5. Version -06 to -07 o Various clarifications added. o Fixed erroneous author email. -F.5. Version -05 to -06 +F.6. Version -05 to -06 o Moved sections that define the ACE framework into a subsection of the framework Section 5. o Split section on client credentials and grant into two separate sections, Section 5.2, and Section 5.3. o Added Section 5.4 on AS authentication. o Added Section 5.5 on the Authorization endpoint. -F.6. Version -04 to -05 +F.7. Version -04 to -05 o Added RFC 2119 language to the specification of the required behavior of profile specifications. o Added Section 5.3 on the relation to the OAuth2 grant types. - o Added CBOR abbreviations for error and the error codes defined in OAuth2. o Added clarification about token expiration and long-running requests in Section 5.8.2 o Added security considerations about tokens with symmetric pop keys valid for more than one RS. o Added privacy considerations section. o Added IANA registry mapping the confirmation types from RFC 7800 to equivalent COSE types. o Added appendix D, describing assumptions about what the AS knows @@ -2884,64 +2890,64 @@ o Added clarification about token expiration and long-running requests in Section 5.8.2 o Added security considerations about tokens with symmetric pop keys valid for more than one RS. o Added privacy considerations section. o Added IANA registry mapping the confirmation types from RFC 7800 to equivalent COSE types. o Added appendix D, describing assumptions about what the AS knows about the client and the RS. -F.7. Version -03 to -04 +F.8. Version -03 to -04 o Added a description of the terms "framework" and "profiles" as used in this document. o Clarified protection of access tokens in section 3.1. o Clarified uses of the "cnf" parameter in section 6.4.5. o Clarified intended use of Client Token in section 7.4. -F.8. Version -02 to -03 +F.9. Version -02 to -03 o Removed references to draft-ietf-oauth-pop-key-distribution since the status of this draft is unclear. o Copied and adapted security considerations from draft-ietf-oauth- pop-key-distribution. o Renamed "client information" to "RS information" since it is information about the RS. o Clarified the requirements on profiles of this framework. o Clarified the token endpoint protocol and removed negotiation of "profile" and "alg" (section 6). o Renumbered the abbreviations for claims and parameters to get a consistent numbering across different endpoints. o Clarified the introspection endpoint. o Renamed token, introspection and authz-info to "endpoint" instead of "resource" to mirror the OAuth 2.0 terminology. o Updated the examples in the appendices. -F.9. Version -01 to -02 +F.10. Version -01 to -02 o Restructured to remove communication security parts. These shall now be defined in profiles. + o Restructured section 5 to create new sections on the OAuth endpoints token, introspection and authz-info. o Pulled in material from draft-ietf-oauth-pop-key-distribution in order to define proof-of-possession key distribution. o Introduced the "cnf" parameter as defined in RFC7800 to reference or transport keys used for proof of possession. - o Introduced the "client-token" to transport client information from the AS to the client via the RS in conjunction with introspection. o Expanded the IANA section to define parameters for token request, introspection and CWT claims. o Moved deployment scenarios to the appendix as examples. -F.10. Version -00 to -01 +F.11. Version -00 to -01 o Changed 5.1. from "Communication Security Protocol" to "Client Information". o Major rewrite of 5.1 to clarify the information exchanged between C and AS in the PoP access token request profile for IoT. * Allow the client to indicate preferences for the communication security protocol. * Defined the term "Client Information" for the additional information returned to the client in addition to the access