draft-ietf-ace-oauth-authz-28.txt   draft-ietf-ace-oauth-authz-29.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
December 14, 2019 December 14, 2019
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-28 draft-ietf-ace-oauth-authz-29
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 CoAP, thus transforming a well-known and widely used OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
authorization solution into a form suitable for IoT devices. transforming a well-known and widely used authorization solution into
Existing specifications are used where possible, but extensions are a form suitable for IoT devices. Existing specifications are used
added and profiles are defined to better serve the IoT use cases. where possible, but extensions are added and profiles are defined to
better serve the IoT use cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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.
While prior work on authorization solutions for the Web and for the While prior work on authorization solutions for the Web and for the
mobile environment also applies to the Internet of Things (IoT) mobile environment also applies to the Internet of Things (IoT)
environment, many IoT devices are constrained, for example, in terms environment, many IoT devices are constrained, for example, in terms
of processing capabilities, available memory, etc. For web of processing capabilities, available memory, etc. For web
applications on constrained nodes, this specification RECOMMENDS the applications on constrained nodes, this specification RECOMMENDS the
use of CoAP [RFC7252] as replacement for HTTP. use of the Constrained Application Protocol (CoAP) [RFC7252] as
replacement for HTTP.
A detailed treatment of constraints can be found in [RFC7228], and Appendix A gives an overview of the constraints considered in this
the different IoT deployments present a continuous range of device design, and a more detailed treatment of constraints can be found in
and network capabilities. Taking energy consumption as an example: [RFC7228]. This design aims to accommodate different IoT deployments
At one end there are energy-harvesting or battery powered devices and thus a continuous range of device and network capabilities.
which have a tight power budget, on the other end there are mains- Taking energy consumption as an example: At one end there are energy-
powered devices, and all levels in between. harvesting or battery powered devices which have a tight power
budget, on the other end there are mains-powered devices, and all
levels in between.
Hence, IoT devices may be very different in terms of available Hence, IoT devices may be very different in terms of available
processing and message exchange capabilities and there is a need to processing and message exchange capabilities and there is a need to
support many different authorization use cases [RFC7744]. support many different authorization use cases [RFC7744].
This specification describes a framework for authentication and This specification describes a framework for authentication and
authorization in constrained environments (ACE) built on re-use of authorization in constrained environments (ACE) built on re-use of
OAuth 2.0 [RFC6749], thereby extending authorization to Internet of OAuth 2.0 [RFC6749], thereby extending authorization to Internet of
Things devices. This specification contains the necessary building Things devices. This specification contains the necessary building
blocks for adjusting OAuth 2.0 to IoT environments. blocks for adjusting OAuth 2.0 to IoT environments.
More detailed, interoperable specifications can be found in profiles. More detailed, interoperable specifications can be found in separate
Implementations may claim conformance with a specific profile, profile specifications. Implementations may claim conformance with a
whereby implementations utilizing the same profile interoperate while specific profile, whereby implementations utilizing the same profile
implementations of different profiles are not expected to be interoperate while implementations of different profiles are not
interoperable. Some devices, such as mobile phones and tablets, may expected to be interoperable. Some devices, such as mobile phones
implement multiple profiles and will therefore be able to interact and tablets, may implement multiple profiles and will therefore be
with a wider range of low end devices. Requirements on profiles are able to interact with a wider range of low end devices. Requirements
described at contextually appropriate places throughout this on profiles are described at contextually appropriate places
specification, and also summarized in Appendix C. throughout this specification, and also summarized in Appendix C.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Certain security-related terms such as "authentication", Certain security-related terms such as "authentication",
skipping to change at page 6, line 33 skipping to change at page 6, line 38
widespread deployment. Many IoT devices can support OAuth 2.0 widespread deployment. Many IoT devices can support OAuth 2.0
without any additional extensions, but for certain constrained without any additional extensions, but for certain constrained
settings additional profiling is needed. settings additional profiling is needed.
Another building block is the lightweight web transfer protocol CoAP Another building block is the lightweight web transfer protocol CoAP
[RFC7252], for those communication environments where HTTP is not [RFC7252], for those communication environments where HTTP is not
appropriate. CoAP typically runs on top of UDP, which further appropriate. CoAP typically runs on top of UDP, which further
reduces overhead and message exchanges. While this specification reduces overhead and message exchanges. While this specification
defines extensions for the use of OAuth over CoAP, other underlying defines extensions for the use of OAuth over CoAP, other underlying
protocols are not prohibited from being supported in the future, such protocols are not prohibited from being supported in the future, such
as HTTP/2 [RFC7540], MQTT [MQTT5.0], BLE [BLE] and QUIC 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 [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 CBOR [RFC7049], for encodings where JSON A third building block is the Concise Binary Object Representation
[RFC8259] is not sufficiently compact. CBOR is a binary encoding (CBOR) [RFC7049], for encodings where JSON [RFC8259] is not
designed for small code and message size, which may be used for sufficiently compact. CBOR is a binary encoding designed for small
encoding of self contained tokens, and also for encoding payloads code and message size, which may be used for encoding of self
transferred in protocol messages. contained tokens, and also for encoding payloads transferred in
protocol messages.
A fourth building block is the CBOR-based secure message format 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].
With the building blocks listed above, solutions satisfying various With the building blocks listed above, solutions satisfying various
IoT device and network constraints are possible. A list of IoT device and network constraints are possible. A list of
skipping to change at page 18, line 46 skipping to change at page 18, line 49
Payload : Payload :
{ {
"AS" : "coaps://as.example.com/token", "AS" : "coaps://as.example.com/token",
"audience" : "coaps://rs.example.com" "audience" : "coaps://rs.example.com"
"scope" : "rTempC", "scope" : "rTempC",
"cnonce" : h'e0a156bb3f' "cnonce" : h'e0a156bb3f'
} }
Figure 3: AS Request Creation Hints payload example Figure 3: AS Request Creation Hints payload example
In this example, the attribute AS points the receiver of this message In the example above, the response parameter "AS" points the receiver
to the URI "coaps://as.example.com/token" to request access of this message to the URI "coaps://as.example.com/token" to request
permissions. The originator of the AS Request Creation Hints payload access tokens. The RS sending this response (i.e., RS) uses an
(i.e., RS) uses a local clock that is loosely synchronized with a internal clock that is only loosely synchronized with the clock of
time scale common between RS and AS (e.g., wall clock time). the AS. Therefore it can not reliably verify the expiration time of
Therefore, it has included a parameter "nonce" (see Section 5.1.2.1). access tokens it receives. To ensure a certain level of access token
freshness nevetheless, the RS has included a "cnonce" parameter (see
Section 5.1.2.1) in the response.
Figure 4 illustrates the mandatory to use binary encoding of the Figure 4 illustrates the mandatory to use binary encoding of the
message payload shown in Figure 3. message payload shown in Figure 3.
a4 # map(4) a4 # map(4)
01 # unsigned(1) (=AS) 01 # unsigned(1) (=AS)
78 1c # text(28) 78 1c # text(28)
636f6170733a2f2f61732e657861 636f6170733a2f2f61732e657861
6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
05 # unsigned(5) (=audience) 05 # unsigned(5) (=audience)
skipping to change at page 19, line 35 skipping to change at page 19, line 39
5.1.2.1. The Client-Nonce Parameter 5.1.2.1. The Client-Nonce Parameter
If the RS does not synchronize its clock with the AS, it could be If the RS does not synchronize its clock with the AS, it could be
tricked into accepting old access tokens, that are either expired or tricked into accepting old access tokens, that are either expired or
have been compromised. In order to ensure some level of token have been compromised. In order to ensure some level of token
freshness in that case, the RS can use the "cnonce" (client-nonce) freshness in that case, the RS can use the "cnonce" (client-nonce)
parameter. The processing requirements for this parameter are as parameter. The processing requirements for this parameter are as
follows: follows:
o A RS sending a "cnonce" parameter in an an AS Request Creation o A RS sending a "cnonce" parameter in an AS Request Creation Hints
Hints message MUST store information to validate that a given message MUST store information to validate that a given cnonce is
cnonce is fresh. How this is implemented internally is out of fresh. How this is implemented internally is out of scope for
scope for this specification. Expiration of client-nonces should this specification. Expiration of client-nonces should be based
be based roughly on the time it would take a client to obtain an roughly on the time it would take a client to obtain an access
access token after receiving the AS Request Creation Hints token after receiving the AS Request Creation Hints message, with
message, with some allowance for unexpected delays. some allowance for unexpected delays.
o A client receiving a "cnonce" parameter in an AS Request Creation o A client receiving a "cnonce" parameter in an AS Request Creation
Hints message MUST include this in the parameters when requesting Hints message MUST include this in the parameters when requesting
an access token at the AS, using the "cnonce" parameter from an access token at the AS, using the "cnonce" parameter from
Section 5.6.4.4. Section 5.6.4.4.
o If an AS grants an access token request containing a "cnonce" o If an AS grants an access token request containing a "cnonce"
parameter, it MUST include this value in the access token, using parameter, it MUST include this value in the access token, using
the "cnonce" claim specified in Section 5.8. the "cnonce" claim specified in Section 5.8.
skipping to change at page 29, line 8 skipping to change at page 29, line 8
5.6.4.1. Grant Type 5.6.4.1. Grant Type
The abbreviations specified in the registry defined in Section 8.4 The abbreviations specified in the registry defined in Section 8.4
MUST be used in CBOR encodings instead of the string values defined MUST be used in CBOR encodings instead of the string values defined
in [RFC6749], if CBOR payloads are used. in [RFC6749], if CBOR payloads are used.
/--------------------+------------+------------------------\ /--------------------+------------+------------------------\
| Name | CBOR Value | Original Specification | | Name | CBOR Value | Original Specification |
|--------------------+------------+------------------------| |--------------------+------------+------------------------|
| password | 0 | RFC6749 | | password | 0 | [RFC6749] |
| authorization_code | 1 | RFC6749 | | authorization_code | 1 | [RFC6749] |
| client_credentials | 2 | RFC6749 | | client_credentials | 2 | [RFC6749] |
| refresh_token | 3 | RFC6749 | | refresh_token | 3 | [RFC6749] |
\--------------------+------------+------------------------/ \--------------------+------------+------------------------/
Figure 11: CBOR abbreviations for common grant types Figure 11: CBOR abbreviations for common grant types
5.6.4.2. Token Type 5.6.4.2. Token Type
The "token_type" parameter, defined in section 5.1 of [RFC6749], The "token_type" parameter, defined in section 5.1 of [RFC6749],
allows the AS to indicate to the client which type of access token it allows the AS to indicate to the client which type of access token it
is receiving (e.g., a bearer token). is receiving (e.g., a bearer token).
 End of changes. 11 change blocks. 
45 lines changed or deleted 53 lines changed or added

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