--- 1/draft-ietf-ace-oauth-authz-28.txt 2019-12-14 09:13:14.793695800 -0800 +++ 2/draft-ietf-ace-oauth-authz-29.txt 2019-12-14 09:13:14.957700001 -0800 @@ -6,31 +6,32 @@ E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. December 14, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-28 + draft-ietf-ace-oauth-authz-29 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 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 better serve the IoT use cases. + 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 + better serve the IoT use cases. 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 https://datatracker.ietf.org/drafts/current/. @@ -172,48 +173,51 @@ 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. While prior work on authorization solutions for the Web and for the mobile environment also applies to the Internet of Things (IoT) environment, many IoT devices are constrained, for example, in terms of processing capabilities, available memory, etc. For web 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 - the different IoT deployments present a continuous range of device - and network capabilities. Taking energy consumption as an example: - At one end there are energy-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. + Appendix A gives an overview of the constraints considered in this + design, and a more detailed treatment of constraints can be found in + [RFC7228]. This design aims to accommodate different IoT deployments + and thus a continuous range of device and network capabilities. + Taking energy consumption as an example: At one end there are energy- + 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 processing and message exchange capabilities and there is a need to support many different authorization use cases [RFC7744]. This specification describes a framework for authentication and authorization in constrained environments (ACE) built on re-use of OAuth 2.0 [RFC6749], thereby extending authorization to Internet of Things devices. This specification contains the necessary building blocks for adjusting OAuth 2.0 to IoT environments. - More detailed, interoperable specifications can be found in profiles. - Implementations may claim conformance with a specific profile, - whereby implementations utilizing the same profile interoperate while - implementations of different profiles are not expected to be - 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. + More detailed, interoperable specifications can be found in separate + profile specifications. Implementations may claim conformance with a + specific profile, whereby implementations utilizing the same profile + interoperate while implementations of different profiles are not + expected to be 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Certain security-related terms such as "authentication", @@ -258,34 +262,36 @@ widespread deployment. Many IoT devices can support OAuth 2.0 without any additional extensions, but for certain constrained settings additional profiling is needed. 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 [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 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 CBOR [RFC7049], 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 third building block is the Concise Binary Object Representation + (CBOR) [RFC7049], 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 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 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 OAuth bearer tokens. The default token format is defined in CBOR web token (CWT) [RFC8392]. Application layer security for CoAP using COSE can be provided with OSCORE [RFC8613]. With the building blocks listed above, solutions satisfying various IoT device and network constraints are possible. A list of @@ -818,26 +823,28 @@ Payload : { "AS" : "coaps://as.example.com/token", "audience" : "coaps://rs.example.com" "scope" : "rTempC", "cnonce" : h'e0a156bb3f' } Figure 3: AS Request Creation Hints payload example - In this example, the attribute AS points the receiver of this message - to the URI "coaps://as.example.com/token" to request access - permissions. The originator of the AS Request Creation Hints payload - (i.e., RS) uses a local clock that is loosely synchronized with a - time scale common between RS and AS (e.g., wall clock time). - Therefore, it has included a parameter "nonce" (see Section 5.1.2.1). + In the example above, the response parameter "AS" points the receiver + of this message to the URI "coaps://as.example.com/token" to request + access tokens. The RS sending this response (i.e., RS) uses an + internal clock that is only loosely synchronized with the clock of + the AS. Therefore it can not reliably verify the expiration time of + 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 message payload shown in Figure 3. a4 # map(4) 01 # unsigned(1) (=AS) 78 1c # text(28) 636f6170733a2f2f61732e657861 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 05 # unsigned(5) (=audience) @@ -855,27 +862,27 @@ 5.1.2.1. The Client-Nonce Parameter 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 have been compromised. In order to ensure some level of token freshness in that case, the RS can use the "cnonce" (client-nonce) parameter. The processing requirements for this parameter are as follows: - o A RS sending a "cnonce" parameter in an an AS Request Creation - Hints message MUST store information to validate that a given - cnonce is fresh. How this is implemented internally is out of - scope for this specification. Expiration of client-nonces should - be based roughly on the time it would take a client to obtain an - access token after receiving the AS Request Creation Hints - message, with some allowance for unexpected delays. + o A RS sending a "cnonce" parameter in an AS Request Creation Hints + message MUST store information to validate that a given cnonce is + fresh. How this is implemented internally is out of scope for + this specification. Expiration of client-nonces should be based + roughly on the time it would take a client to obtain an access + token after receiving the AS Request Creation Hints message, with + some allowance for unexpected delays. o A client receiving a "cnonce" parameter in an AS Request Creation Hints message MUST include this in the parameters when requesting an access token at the AS, using the "cnonce" parameter from Section 5.6.4.4. o If an AS grants an access token request containing a "cnonce" parameter, it MUST include this value in the access token, using the "cnonce" claim specified in Section 5.8. @@ -1283,24 +1290,24 @@ 5.6.4.1. Grant Type The abbreviations specified in the registry defined in Section 8.4 MUST be used in CBOR encodings instead of the string values defined in [RFC6749], if CBOR payloads are used. /--------------------+------------+------------------------\ | Name | CBOR Value | Original Specification | |--------------------+------------+------------------------| - | password | 0 | RFC6749 | - | authorization_code | 1 | RFC6749 | - | client_credentials | 2 | RFC6749 | - | refresh_token | 3 | RFC6749 | + | 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.2. Token Type 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 is receiving (e.g., a bearer token).