draft-ietf-ace-oauth-authz-42.txt   draft-ietf-ace-oauth-authz-43.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: December 10, 2021 Ericsson Expires: January 11, 2022 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
June 8, 2021 July 10, 2021
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)
using the OAuth 2.0 Framework (ACE-OAuth) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-42 draft-ietf-ace-oauth-authz-43
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and the Constrained Application Protocol (CoAP), thus OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to where possible, but extensions are added and profiles are defined to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2021. This Internet-Draft will expire on January 11, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 43 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 43
6.2. Communication Security . . . . . . . . . . . . . . . . . 44 6.2. Communication Security . . . . . . . . . . . . . . . . . 44
6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44
6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 45 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 45
6.5. Minimal Security Requirements for Communication . 45 6.5. Minimal Security Requirements for Communication . 45
6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46
6.7. Combining Profiles . . . . . . . . . . . . . . . . . . . 47 6.7. Combining Profiles . . . . . . . . . . . . . . . . . . . 47
6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
6.9. Identifying Audiences . . . . . . . . . . . . . . . . . . 48 6.9. Identifying Audiences . . . . . . . . . . . . . . . . . . 48
6.10. Denial of Service Against or with Introspection . . 48 6.10. Denial of Service Against or with Introspection . . 49
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.1. ACE Authorization Server Request Creation Hints . . . . . 50 8.1. ACE Authorization Server Request Creation Hints . . . . . 50
8.2. CoRE Resource Type Registry . . . . . . . . . . . . . . . 51 8.2. CoRE Resource Type Registry . . . . . . . . . . . . . . . 51
8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51 8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51
8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51
8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52 8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52
8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52
8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 53
8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53 8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53
8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53 8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53
8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54 8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54
8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54 8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54
8.11. OAuth Introspection Response Parameter Registration . . . 54 8.11. OAuth Introspection Response Parameter Registration . . . 55
8.12. OAuth Token Introspection Response CBOR Mappings Registry 55 8.12. OAuth Token Introspection Response CBOR Mappings Registry 55
8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 56
8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56
8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57 8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57
8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58 8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58
8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58 8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 60
10.2. Informative References . . . . . . . . . . . . . . . . . 62 10.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Design Justification . . . . . . . . . . . . . . . . 65 Appendix A. Design Justification . . . . . . . . . . . . . . . . 65
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 69
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71
Appendix D. Assumptions on AS Knowledge about C and RS . . . . . 72 Appendix D. Assumptions on AS Knowledge about C and RS . . . . . 72
Appendix E. Differences to OAuth 2.0 . . . . . . . . . . . . . . 72 Appendix E. Differences to OAuth 2.0 . . . . . . . . . . . . . . 73
Appendix F. Deployment Examples . . . . . . . . . . . . . . . . 73 Appendix F. Deployment Examples . . . . . . . . . . . . . . . . 73
F.1. Local Token Validation . . . . . . . . . . . . . . . . . 73 F.1. Local Token Validation . . . . . . . . . . . . . . . . . 74
F.2. Introspection Aided Token Validation . . . . . . . . . . 77 F.2. Introspection Aided Token Validation . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
Authorization is the process for granting approval to an entity to Authorization is the process for granting approval to an entity to
access a generic resource [RFC4949]. The authorization task itself access a generic resource [RFC4949]. The authorization task itself
can best be described as granting access to a requesting client, for can best be described as granting access to a requesting client, for
a resource hosted on a device, the resource server (RS). This a resource hosted on a device, the resource server (RS). This
exchange is mediated by one or multiple authorization servers (AS). exchange is mediated by one or multiple authorization servers (AS).
Managing authorization for a large number of devices and users can be Managing authorization for a large number of devices and users can be
a complex task. a complex task.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
[I-D.ietf-quic-transport]. Note that this document specifies [I-D.ietf-quic-transport]. Note that this document specifies
protocol exchanges in terms of RESTful verbs such as GET and POST. protocol exchanges in terms of RESTful verbs such as GET and POST.
Future profiles using protocols that do not support these verbs MUST Future profiles using protocols that do not support these verbs MUST
specify how the corresponding protocol messages are transmitted specify how the corresponding protocol messages are transmitted
instead. instead.
A third building block is the Concise Binary Object Representation A third building block is the Concise Binary Object Representation
(CBOR) [RFC8949], 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 sufficiently compact. CBOR is a binary encoding designed for small
code and message size. Self-contained tokens and protocol message code and message size. Self-contained tokens and protocol message
payloads are encoded in CBOR when CoAP is used. payloads are encoded in CBOR when CoAP is used. When CoAP is not
used, the use of CBOR remains RECOMMENDED.
A fourth building block is CBOR Object Signing and Encryption (COSE) A fourth building block is CBOR Object Signing and Encryption (COSE)
[RFC8152], which enables object-level layer security as an [RFC8152], which enables object-level layer security as an
alternative or complement to transport layer security (DTLS [RFC6347] alternative or complement to transport layer security (DTLS [RFC6347]
or TLS [RFC8446]). COSE is used to secure self-contained tokens such or TLS [RFC8446]). COSE is used to secure self-contained tokens such
as proof-of-possession (PoP) tokens, which are an extension to the as proof-of-possession (PoP) tokens, which are an extension to the
OAuth bearer tokens. The default token format is defined in CBOR Web OAuth bearer tokens. The default token format is defined in CBOR Web
Token (CWT) [RFC8392]. Application-layer security for CoAP using Token (CWT) [RFC8392]. Application-layer security for CoAP using
COSE can be provided with OSCORE [RFC8613]. COSE can be provided with OSCORE [RFC8613].
skipping to change at page 47, line 7 skipping to change at page 47, line 7
lose the current values of counters tracking the "exi" claims of lose the current values of counters tracking the "exi" claims of
tokens it is storing. tokens it is storing.
The first drawback is inherent to the deployment scenario and the The first drawback is inherent to the deployment scenario and the
"exi" solution. It can therefore not be mitigated without requiring "exi" solution. It can therefore not be mitigated without requiring
the RS be online at times. The second drawback can be mitigated by the RS be online at times. The second drawback can be mitigated by
regularly storing the value of "exi" counters to persistent memory. regularly storing the value of "exi" counters to persistent memory.
6.7. Combining Profiles 6.7. Combining Profiles
There may be use cases were different profiles of this framework are There may be use cases where different transport and security
combined. For example, an MQTT-TLS profile is used between the protocols are allowed for the different interactions, and, if that is
client and the RS in combination with a CoAP-DTLS profile for not explicitly covered by an existing profile, it corresponds to
interactions between the client and the AS. The security of a combining profiles into a new one. For example, a new profile could
profile MUST NOT depend on the assumption that the profile is used specify that a previously-defined MQTT-TLS profile is used between
for all the different types of interactions in this framework. the client and the RS in combination with a previously-defined CoAP-
DTLS profile for interactions between the client and the AS. The new
profile that combines existing profiles MUST specify how the existing
profiles' security properties are achieved. Any profile therefore
MUST clearly specify its security requirements and MUST document if
its security depends on the combination of various protocol
interactions.
6.8. Unprotected Information 6.8. Unprotected Information
Communication with the authz-info endpoint, as well as the various Communication with the authz-info endpoint, as well as the various
error responses defined in this framework, all potentially include error responses defined in this framework, all potentially include
sending information over an unprotected channel. These messages may sending information over an unprotected channel. These messages may
leak information to an adversary, or may be manipulated by active leak information to an adversary, or may be manipulated by active
attackers to induce incorrect behavior. For example error responses attackers to induce incorrect behavior. For example error responses
for requests to the Authorization Information endpoint can reveal for requests to the Authorization Information endpoint can reveal
information about an otherwise opaque access token to an adversary information about an otherwise opaque access token to an adversary
skipping to change at page 73, line 4 skipping to change at page 73, line 27
o Cardinality of "grant_type" parameter -- In client-to-AS requests o Cardinality of "grant_type" parameter -- In client-to-AS requests
using OAuth 2.0, the "grant_type" parameter is required (per using OAuth 2.0, the "grant_type" parameter is required (per
[RFC6749]). In this framework, this parameter is optional. See [RFC6749]). In this framework, this parameter is optional. See
Section 5.8.1. Section 5.8.1.
o Encoding of "scope" parameter -- In client-to-AS requests using o Encoding of "scope" parameter -- In client-to-AS requests using
OAuth 2.0, the "scope" parameter is string encoded (per OAuth 2.0, the "scope" parameter is string encoded (per
[RFC6749]). In this framework, this parameter may also be encoded [RFC6749]). In this framework, this parameter may also be encoded
as a byte string. See Section 5.8.1. as a byte string. See Section 5.8.1.
o Cardinality of "token_type" parameter -- in AS-to-client responses o Cardinality of "token_type" parameter -- in AS-to-client responses
using OAuth 2.0, the token_type parameter is required (per using OAuth 2.0, the token_type parameter is required (per
[RFC6749]). In this framework, this parameter is optional. See [RFC6749]). In this framework, this parameter is optional. See
Section 5.8.2. Section 5.8.2.
o Access token retention -- in OAuth 2.0, the access token is sent o Access token retention -- in OAuth 2.0, the access token may be
with each request to the RS. In this framework, the RS must be sent with every request to the RS. The exact use of access tokens
depends on the semantics of the application and the session
management concept it uses. In this framework, the RS must be
able to store these tokens for later use. See Section 5.10.1. able to store these tokens for later use. See Section 5.10.1.
Appendix F. Deployment Examples Appendix F. Deployment Examples
There is a large variety of IoT deployments, as is indicated in There is a large variety of IoT deployments, as is indicated in
Appendix A, and this section highlights a few common variants. This Appendix A, and this section highlights a few common variants. This
section is not normative but illustrates how the framework can be section is not normative but illustrates how the framework can be
applied. applied.
For each of the deployment variants, there are a number of possible For each of the deployment variants, there are a number of possible
 End of changes. 16 change blocks. 
25 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/