draft-ietf-ace-oauth-authz-41.txt   draft-ietf-ace-oauth-authz-42.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: November 6, 2021 Ericsson Expires: December 10, 2021 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
May 5, 2021 June 8, 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-41 draft-ietf-ace-oauth-authz-42
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 November 6, 2021. This Internet-Draft will expire on December 10, 2021.
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 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16
5.2. Unauthorized Resource Request Message . . . . . . . . . . 16 5.2. Unauthorized Resource Request Message . . . . . . . . . . 17
5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17 5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17
5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19 5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19
5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20 5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20
5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21 5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21
5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21 5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21
5.7. The Authorization Endpoint . . . . . . . . . . . . . . . 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.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22
5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25 5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25
5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27 5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27
5.8.4. Request and Response Parameters . . . . . . . . . . . 28 5.8.4. Request and Response Parameters . . . . . . . . . . . 28
5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28 5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28
5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29 5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29
5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29 5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29
5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30 5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30
5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30 5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30
5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31 5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31
5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32 5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32
5.9.2. Introspection Response . . . . . . . . . . . . . . . 33 5.9.2. Introspection Response . . . . . . . . . . . . . . . 33
5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34 5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34
5.9.4. Mapping Introspection Parameters to CBOR . . . . . . 35 5.9.4. Mapping Introspection Parameters to CBOR . . . . . . 35
5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35 5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35
5.10.1. The Authorization Information Endpoint . . . . . . . 36 5.10.1. The Authorization Information Endpoint . . . . . . . 36
5.10.1.1. Verifying an Access Token . . . . . . . . . . . 37 5.10.1.1. Verifying an Access Token . . . . . . . . . . . 37
5.10.1.2. Protecting the Authorization Information 5.10.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 39 Endpoint . . . . . . . . . . . . . . . . . . . . 39
5.10.2. Client Requests to the RS . . . . . . . . . . . . . 40 5.10.2. Client Requests to the RS . . . . . . . . . . . . . 39
5.10.3. Token Expiration . . . . . . . . . . . . . . . . . . 40 5.10.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
5.10.4. Key Expiration . . . . . . . . . . . . . . . . . . . 42 5.10.4. Key Expiration . . . . . . . . . . . . . . . . . . . 42
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
skipping to change at page 6, line 33 skipping to change at page 6, line 33
[MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC [MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC
[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, which may be used for encoding of self code and message size. Self-contained tokens and protocol message
contained tokens, and also for encoding payloads transferred in payloads are encoded in CBOR when CoAP is used.
protocol messages.
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 16, line 20 skipping to change at page 16, line 20
to define a new profile if the communication between C and AS, or to define a new profile if the communication between C and AS, or
between RS and AS, is protected with a different security protocol between RS and AS, is protected with a different security protocol
complying with the security requirements above. complying with the security requirements above.
In OAuth 2.0 the communication with the Token and the Introspection 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 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 parameters. When profiles of this framework use CoAP instead, it is
REQUIRED to use of the following alternative instead of Uri-query REQUIRED to use of the following alternative instead of Uri-query
parameters: The sender (client or RS) encodes the parameters of its 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 as a CBOR map and submits that map as the payload of the POST
request. request. The CBOR encoding for a number of OAuth 2.0 parameters is
specified in this document, if a profile needs to use other OAuth 2.0
parameters with CoAP it MUST specify their CBOR encoding.
Profiles that use CBOR encoding of protocol message parameters at the Profiles that use CBOR encoding of protocol message parameters at the
outermost encoding layer MUST use the content format 'application/ outermost encoding layer MUST use the content format 'application/
ace+cbor'. If CoAP is used for communication, the Content-Format ace+cbor'. If CoAP is used for communication, the Content-Format
MUST be abbreviated with the ID: 19 (see Section 8.16). 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 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 responses both to client and RS. If CoAP is used, it is REQUIRED to
use CBOR [RFC8949] 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. CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.
skipping to change at page 39, line 40 skipping to change at page 39, line 40
client. client.
5.10.1.2. Protecting the Authorization Information Endpoint 5.10.1.2. Protecting the Authorization Information Endpoint
As this framework can be used in RESTful environments, it is As this framework can be used in RESTful environments, it is
important to make sure that attackers cannot perform unauthorized important to make sure that attackers cannot perform unauthorized
requests on the authz-info endpoints, other than submitting access requests on the authz-info endpoints, other than submitting access
tokens. tokens.
Specifically it SHOULD NOT be possible to perform GET, DELETE or PUT Specifically it SHOULD NOT be possible to perform GET, DELETE or PUT
on the authz-info endpoint and on its children (if any). on the authz-info endpoint.
The POST method SHOULD NOT be allowed on children of the authz-info
endpoint.
The RS SHOULD implement rate limiting measures to mitigate attacks The RS SHOULD implement rate limiting measures to mitigate attacks
aiming to overload the processing capacity of the RS by repeatedly aiming to overload the processing capacity of the RS by repeatedly
submitting tokens. For CoAP-based communication the RS could use the submitting tokens. For CoAP-based communication the RS could use the
mechanisms from [RFC8516] to indicate that it is overloaded. mechanisms from [RFC8516] to indicate that it is overloaded.
5.10.2. Client Requests to the RS 5.10.2. Client Requests to the RS
Before sending a request to an RS, the client MUST verify that the Before sending a request to an RS, the client MUST verify that the
keys used to protect this communication are still valid. See keys used to protect this communication are still valid. See
 End of changes. 10 change blocks. 
15 lines changed or deleted 13 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/