draft-ietf-ace-oauth-authz-22.txt   draft-ietf-ace-oauth-authz-23.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft RISE Internet-Draft RISE
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: September 6, 2019 Ericsson Expires: September 26, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
March 5, 2019 March 25, 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-22 draft-ietf-ace-oauth-authz-23
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 making a well-known and widely used OAuth 2.0 and CoAP, thus making a well-known and widely used
authorization solution suitable for IoT devices. Existing authorization solution suitable for IoT devices. Existing
specifications are used where possible, but where the constraints of specifications are used where possible, but where the constraints of
IoT devices require it, extensions are added and profiles are IoT devices require it, extensions are added and profiles are
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 September 6, 2019. This Internet-Draft will expire on September 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16
5.1.1. Unauthorized Resource Request Message . . . . . . . . 16 5.1.1. Unauthorized Resource Request Message . . . . . . . . 16
5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 17 5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 17
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 19 5.1.2.1. The Client-Nonce Parameter . . . . . . . . . . . 19
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 20
5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20
5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 20 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 21
5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 20 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 21
5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 20 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21
5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 21 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22
5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 24 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 24
5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 26 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 26
5.6.4. Request and Response Parameters . . . . . . . . . . . 27 5.6.4. Request and Response Parameters . . . . . . . . . . . 27
5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 27 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 27
5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 28 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 28
5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 28 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 28
5.6.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 29
5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 29 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 29
5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 29 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 30
5.7.1. Introspection Request . . . . . . . . . . . . . . . . 30 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 30
5.7.2. Introspection Response . . . . . . . . . . . . . . . 31 5.7.2. Introspection Response . . . . . . . . . . . . . . . 31
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 33 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 34
5.8.1. The Authorization Information Endpoint . . . . . . . 34 5.8.1. The Authorization Information Endpoint . . . . . . . 34
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35
5.8.1.2. Protecting the Authorization Information 5.8.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 37 Endpoint . . . . . . . . . . . . . . . . . . . . 37
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 37 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 38
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38
5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 39 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41
6.2. Minimal security requirements for communication . 41 6.2. Minimal security requirements for communication . 41
6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 42 6.3. Use of Nonces for Token Freshness . . . . . . . . . . . . 42
6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 42 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 43
6.5. Unprotected Information . . . . . . . . . . . . . . . . . 42 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 43
6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43 6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43
6.7. Denial of service against or with Introspection . . 44 6.7. Denial of service against or with Introspection . . 44
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
8.1. ACE Authorization Server Request Creation Hints . . . . . 45 8.1. ACE Authorization Server Request Creation Hints . . . . . 45
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 47 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 47
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47
8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 47 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 48
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49
8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49
8.10. OAuth Introspection Response Parameter Registration . . . 49 8.10. OAuth Introspection Response Parameter Registration . . . 50
8.11. OAuth Token Introspection Response CBOR Mappings Registry 50 8.11. OAuth Token Introspection Response CBOR Mappings Registry 50
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 51 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 52
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 52 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 53
8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.1. Normative References . . . . . . . . . . . . . . . . . . 54 10.1. Normative References . . . . . . . . . . . . . . . . . . 55
10.2. Informative References . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Design Justification . . . . . . . . . . . . . . . . 59 Appendix A. Design Justification . . . . . . . . . . . . . . . . 59
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 62 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 63
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 64 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 65
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 65 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 66
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 65 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 66
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66
E.2. Introspection Aided Token Validation . . . . . . . . . . 70 E.2. Introspection Aided Token Validation . . . . . . . . . . 71
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 74 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 75
F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 74 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 75
F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 74 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 75
F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 74 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 75
F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 75 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 76
F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 75 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 76
F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 75 F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 76
F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 76 F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 77
F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 76 F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 77
F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 76 F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 77
F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 76 F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 77
F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 76 F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 77
F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 77 F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 78
F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 77 F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 78
F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 77 F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 78
F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 77 F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 78
F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 78 F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 79
F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 78 F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 79
F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 78 F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 79
F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 78 F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 79
F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 78 F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 79
F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 79 F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 80
F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 79 F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
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 resource [RFC4949]. The authorization task itself can best access a resource [RFC4949]. The authorization task itself can best
be described as granting access to a requesting client, for a be described as granting access to a requesting client, for a
resource hosted on a device, the resource server (RS). This exchange resource hosted on a device, the resource server (RS). This exchange
is mediated by one or multiple authorization servers (AS). Managing is mediated by one or multiple authorization servers (AS). Managing
authorization for a large number of devices and users can be a authorization for a large number of devices and users can be a
complex task. complex task.
skipping to change at page 16, line 23 skipping to change at page 16, line 23
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, this parameters. When profiles of this framework use CoAP instead, this
framework REQUIRES the use of the following alternative instead of framework REQUIRES the use of the following alternative instead of
Uri-query parameters: The sender (client or RS) encodes the Uri-query parameters: The sender (client or RS) encodes the
parameters of its request as a CBOR map and submits that map as the parameters of its request as a CBOR map and submits that map as the
payload of the POST request. Profiles that use CBOR encoding of payload of the POST request. Profiles that use CBOR encoding of
protocol message parameters MUST use the media format 'application/ protocol message parameters MUST use the media format 'application/
ace+cbor', unless the protocol message is wrapped in another Content- ace+cbor', unless the protocol message is wrapped in another Content-
Format (e.g. object security). If CoAP is used for communication, Format (e.g. object security). If CoAP is used for communication,
the Content-Format MUST be abbreviated with the ID: 19 (see the Content-Format MUST be abbreviated with the ID: 19 (see
Section 8.15. Section 8.15).
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, this framework responses both to client and RS. If CoAP is used, this framework
REQUIRES the use of CBOR [RFC7049] instead of JSON. Depending on the REQUIRES the use of CBOR [RFC7049] instead of JSON. Depending on the
profile, the CBOR payload MAY be enclosed in a non-CBOR cryptographic profile, the CBOR payload MAY be enclosed in a non-CBOR cryptographic
wrapper. wrapper.
5.1. Discovering Authorization Servers 5.1. Discovering Authorization Servers
In order to determine the AS in charge of a resource hosted at the In order to determine the AS in charge of a resource hosted at the
skipping to change at page 17, line 46 skipping to change at page 17, line 46
o A "audience" element containing a suggested audience that the o A "audience" element containing a suggested audience that the
client should request towards the AS. client should request towards the AS.
o A "kid" element containing the key identifier of a key used in an o A "kid" element containing the key identifier of a key used in an
existing security association between the client and the RS. The existing security association between the client and the RS. The
RS expects the client to request an access token bound to this RS expects the client to request an access token bound to this
key, in order to avoid having to re-establish the security key, in order to avoid having to re-establish the security
association. association.
o A "nonce" element containing a nonce generated by RS to ensure o A "cnonce" element containing a client-nonce. See
freshness in case that the RS and AS do not have synchronized Section 5.1.2.1.
clocks.
o A "scope" element containing the suggested scope that the client o A "scope" element containing the suggested scope that the client
should request towards the AS. should request towards the AS.
Figure 2 summarizes the parameters that may be part of the AS Request Figure 2 summarizes the parameters that may be part of the AS Request
Creation Hints. Creation Hints.
/-----------+----------+---------------------\ /-----------+----------+---------------------\
| Name | CBOR Key | Value Type | | Name | CBOR Key | Value Type |
|-----------+----------+---------------------| |-----------+----------+---------------------|
| AS | 0 | text string | | AS | 1 | text string |
| kid | 4 | byte string | | kid | 2 | byte string |
| nonce | 5 | byte string | | audience | 5 | text string |
| scope | 9 | text or byte string | | scope | 9 | text or byte string |
| audience | 18 | text string | | cnonce | 39 | byte string |
\-----------+----------+---------------------/ \-----------+----------+---------------------/
Figure 2: AS Request Creation Hints Figure 2: AS Request Creation Hints
Note that the schema part of the AS parameter may need to be adapted Note that the schema part of the AS parameter may need to be adapted
to the security protocol that is used between the client and the AS. to the security protocol that is used between the client and the AS.
Thus the example AS value "coap://as.example.com/token" might need to Thus the example AS value "coap://as.example.com/token" might need to
be transformed to "coaps://as.example.com/token". It is assumed that be transformed to "coaps://as.example.com/token". It is assumed that
the client can determine the correct schema part on its own depending the client can determine the correct schema part on its own depending
on the way it communicates with the AS. on the way it communicates with the AS.
Figure 3 shows an example for an AS Request Creation Hints message Figure 3 shows an example for an AS Request Creation Hints message
payload using CBOR [RFC7049] diagnostic notation, using the parameter payload using CBOR [RFC7049] diagnostic notation, using the parameter
names instead of the CBOR keys for better human readability. names instead of the CBOR keys for better human readability.
4.01 Unauthorized 4.01 Unauthorized
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
{"AS" : "coaps://as.example.com/token", Payload :
"nonce" : h'e0a156bb3f', {
"scope" : "rTempC", "AS" : "coaps://as.example.com/token",
"audience" : "coaps://rs.example.com" "audience" : "coaps://rs.example.com"
"scope" : "rTempC",
"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 this example, the attribute AS points the receiver of this message
to the URI "coaps://as.example.com/token" to request access to the URI "coaps://as.example.com/token" to request access
permissions. The originator of the AS Request Creation Hints payload permissions. The originator of the AS Request Creation Hints payload
(i.e., RS) uses a local clock that is loosely synchronized with a (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). time scale common between RS and AS (e.g., wall clock time).
Therefore, it has included a parameter "nonce" for replay attack Therefore, it has included a parameter "nonce" (see Section 5.1.2.1).
prevention.
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)
00 # unsigned(0) (=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) (=nonce) 05 # unsigned(5) (=audience)
45 # bytes(5)
e0a156bb3f # "\xE0\xA1V\xBB?"
09 # unsigned(9) (=scope)
66 # text(6)
7254656d7043 # "rTempC"
12 # unsigned(18) (=audience)
76 # text(22) 76 # text(22)
636f6170733a2f2f72732e657861 636f6170733a2f2f72732e657861
6d706c652e636f6d # "coaps://rs.example.com" 6d706c652e636f6d # "coaps://rs.example.com"
09 # unsigned(9) (=scope)
66 # text(6)
7254656d7043 # "rTempC"
18 27 # unsigned(39) (=cnonce)
45 # bytes(5)
e0a156bb3f # "\xE0\xA1V\xBB?"
Figure 4: AS Request Creation Hints example encoded in CBOR Figure 4: AS Request Creation Hints example encoded in CBOR
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.
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.
o A RS that is using the client-nonce mechanism and that receives an
access token MUST verify that this token contains a cnonce claim,
with a client-nonce value that is fresh according to the
information stored at the first step above. If the cnonce claim
is not present or if the cnonce claim value is not fresh, it MUST
discard the access token. If this was an interaction with the
authz-info endpoint the RS MUST also respond with an error message
using a response code equivalent to the CoAP code 4.01
(Unauthorized).
5.2. Authorization Grants 5.2. Authorization Grants
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
resource owner or uses its client credentials as grant. The resource owner or uses its client credentials as grant. The
authorization is expressed in the form of an authorization grant. authorization is expressed in the form of an authorization grant.
The OAuth framework [RFC6749] defines four grant types. The grant The OAuth framework [RFC6749] defines four grant types. The grant
types can be split up into two groups, those granted on behalf of the types can be split up into two groups, those granted on behalf of the
resource owner (password, authorization code, implicit) and those for resource owner (password, authorization code, implicit) and those for
the client (client credentials). Further grant types have been added the client (client credentials). Further grant types have been added
later, such as [RFC7521] defining an assertion-based authorization later, such as [RFC7521] defining an assertion-based authorization
grant. grant.
The grant type is selected depending on the use case. In cases where The grant type is selected depending on the use case. In cases where
the client acts on behalf of the resource owner, authorization code the client acts on behalf of the resource owner, authorization code
grant is recommended. If the client acts on behalf of the resource grant is recommended. If the client acts on behalf of the resource
owner, but does not have any display or very limited interaction owner, but does not have any display or very limited interaction
possibilities it is recommended to use the device code grant defined possibilities it is recommended to use the device code grant defined
in [I-D.ietf-oauth-device-flow]. In cases where the client does not in [I-D.ietf-oauth-device-flow]. In cases where the client does not
act on behalf of the resource owner, client credentials grant is acts autonomously the client credentials grant is recommended.
recommended.
For details on the different grant types, see section 1.3 of For details on the different grant types, see section 1.3 of
[RFC6749]. The OAuth 2.0 framework provides an extension mechanism [RFC6749]. The OAuth 2.0 framework provides an extension mechanism
for defining additional grant types so profiles of this framework MAY for defining additional grant types so profiles of this framework MAY
define additional grant types, if needed. define additional grant types, if needed.
5.3. Client Credentials 5.3. Client Credentials
Authentication of the client is mandatory independent of the grant Authentication of the client is mandatory independent of the grant
type when requesting the access token from the token endpoint. In type when requesting the access token from the token endpoint. In
skipping to change at page 20, line 34 skipping to change at page 21, line 18
client connects to. In classic OAuth, the AS is authenticated with a client connects to. In classic OAuth, the AS is authenticated with a
TLS server certificate. TLS server certificate.
Profiles of this framework MUST specify how clients authenticate the Profiles of this framework MUST specify how clients authenticate the
AS and how communication security is implemented, otherwise server AS and how communication security is implemented, otherwise server
side TLS certificates, as defined by OAuth 2.0, are required. side TLS certificates, as defined by OAuth 2.0, are required.
5.5. The Authorization Endpoint 5.5. The Authorization Endpoint
The authorization endpoint is used to interact with the resource The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant in certain grant flows. owner and obtain an authorization grant in certain grant flows. The
Since it requires the use of a user agent (i.e., browser), it is not primary use case for this framework is machine-to-machine
expected that these types of grant flow will be used by constrained interactions, not involving the resource owner in the authorization
clients. This endpoint is therefore out of scope for this flow, therefore this endpoint is out of scope here. Future profiles
specification. Implementations should use the definition and may define constrained adaptation mechanisms for this endpoint as
recommendations of section 3.1 of [RFC6749] and of section 4.2 of well. Non-constrained clients interacting with constrained resource
[RFC6819]. servers can use the specifications in section 3.1 of [RFC6749] and of
section 4.2 of [RFC6819].
If clients involved cannot support HTTP and TLS, profiles MAY define
mappings for the authorization endpoint.
5.6. The Token Endpoint 5.6. The Token Endpoint
In standard OAuth 2.0, the AS provides the token endpoint for In standard OAuth 2.0, the AS provides the token endpoint for
submitting access token requests. This framework extends the submitting access token requests. This framework extends the
functionality of the token endpoint, giving the AS the possibility to functionality of the token endpoint, giving the AS the possibility to
help the client and RS to establish shared keys or to exchange their help the client and RS to establish shared keys or to exchange their
public keys. Furthermore, this framework defines encodings using public keys. Furthermore, this framework defines encodings using
CBOR, as a substitute for JSON. CBOR, as a substitute for JSON.
skipping to change at page 21, line 35 skipping to change at page 22, line 17
illustrative purposes. Note that implementations MUST use the illustrative purposes. Note that implementations MUST use the
integer abbreviations and the binary CBOR encoding, if the CBOR integer abbreviations and the binary CBOR encoding, if the CBOR
encoding is used. encoding is used.
5.6.1. Client-to-AS Request 5.6.1. Client-to-AS Request
The client sends a POST request to the token endpoint at the AS. The The client sends a POST request to the token endpoint at the AS. The
profile MUST specify how the communication is protected. The content profile MUST specify how the communication is protected. The content
of the request consists of the parameters specified in the relevant of the request consists of the parameters specified in the relevant
subsection of section 4 of the OAuth 2.0 specification [RFC6749], subsection of section 4 of the OAuth 2.0 specification [RFC6749],
depending on the grant type. The parameter "grant_type" is an depending on the grant type with the following exceptions and
exception, as it is OPTIONAL in the context of this framework (as additions:
opposed to REQUIRED in RFC6749). If that parameter is missing, the
default value "client_credentials" is implied.
Furthermore the "audience" parameter from o The parameter "grant_type" is OPTIONAL in the context of this
[I-D.ietf-oauth-token-exchange] can be used to request an access framework (as opposed to REQUIRED in RFC6749). If that parameter
token bound to a specific audience. is missing, the default value "client_credentials" is implied.
In addition to these parameters, a client MUST be able to use the o The "audience" parameter from [I-D.ietf-oauth-token-exchange] is
parameters from [I-D.ietf-ace-oauth-params] in an access token OPTIONAL to request an access token bound to a specific audience.
request to the token endpoint and the AS MUST be able to process
these additional parameters.
If CBOR is used then this parameter MUST be encoded as a CBOR map. o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if
The "scope" parameter can be formatted as specified in section 3.3 of the RS provided a client-nonce in the "AS Request Creation Hints"
[RFC6749] and additionally as a byte string, in order to allow message Section 5.1.2
compact encoding of complex scopes.
o The "scope" parameter MAY be encoded as a byte string instead of
the string encoding specified in section 3.3 of [RFC6749], in
order allow compact encoding of complex scopes.
o A client MUST be able to use the parameters from
[I-D.ietf-ace-oauth-params] in an access token request to the
token endpoint and the AS MUST be able to process these additional
parameters.
If CBOR is used then these parameters MUST be encoded as a CBOR map.
When HTTP is used as a transport then the client makes a request to When HTTP is used as a transport then the client makes a request to
the token endpoint by sending the parameters using the "application/ the token endpoint by sending the parameters using the "application/
x-www-form-urlencoded" format with a character encoding of UTF-8 in x-www-form-urlencoded" format with a character encoding of UTF-8 in
the HTTP request entity-body, as defined in section 3.2 of [RFC6749]. the HTTP request entity-body, as defined in section 3.2 of [RFC6749].
The following examples illustrate different types of requests for The following examples illustrate different types of requests for
proof-of-possession tokens. proof-of-possession tokens.
Figure 5 shows a request for a token with a symmetric proof-of- Figure 5 shows a request for a token with a symmetric proof-of-
skipping to change at page 23, line 12 skipping to change at page 23, line 34
note that this example uses the "req_cnf" parameter from note that this example uses the "req_cnf" parameter from
[I-D.ietf-ace-oauth-params]. [I-D.ietf-ace-oauth-params].
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
OSCORE: 0x19, 0x05, 0x05, 0x44, 0x61, 0x6c, 0x65, 0x6b OSCORE: 0x19, 0x05, 0x05, 0x44, 0x61, 0x6c, 0x65, 0x6b
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
0x44025d1 ... (full payload omitted for brevity) ... 68b3825e 0x44025d1 ... (full payload omitted for brevity) ... 68b3825e
)
Decrypted payload: Decrypted payload:
{ {
"client_id" : "myclient", "client_id" : "myclient",
"req_cnf" : { "req_cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "EC", "kty" : "EC",
"kid" : h'11', "kid" : h'11',
"crv" : "P-256", "crv" : "P-256",
"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
skipping to change at page 24, line 43 skipping to change at page 24, line 47
If the access token request has been successfully verified by the AS If the access token request has been successfully verified by the AS
and the client is authorized to obtain an access token corresponding and the client is authorized to obtain an access token corresponding
to its access token request, the AS sends a response with the to its access token request, the AS sends a response with the
response code equivalent to the CoAP response code 2.01 (Created). response code equivalent to the CoAP response code 2.01 (Created).
If client request was invalid, or not authorized, the AS returns an If client request was invalid, or not authorized, the AS returns an
error response as described in Section 5.6.3. error response as described in Section 5.6.3.
Note that the AS decides which token type and profile to use when Note that the AS decides which token type and profile to use when
issuing a successful response. It is assumed that the AS has prior issuing a successful response. It is assumed that the AS has prior
knowledge of the capabilities of the client and the RS (see knowledge of the capabilities of the client and the RS (see
Appendix D. This prior knowledge may, for example, be set by the use Appendix D). This prior knowledge may, for example, be set by the
of a dynamic client registration protocol exchange [RFC7591]. use of a dynamic client registration protocol exchange [RFC7591].
The content of the successful reply is the Access Information. When The content of the successful reply is the Access Information. When
using CBOR payloads, the content MUST be encoded as CBOR map, using CBOR payloads, the content MUST be encoded as CBOR map,
containing parameters as specified in Section 5.1 of [RFC6749], with containing parameters as specified in Section 5.1 of [RFC6749], with
the following additions and changes: the following additions and changes:
profile: profile:
OPTIONAL. This indicates the profile that the client MUST use OPTIONAL. This indicates the profile that the client MUST use
towards the RS. See Section 5.6.4.3 for the formatting of this towards the RS. See Section 5.6.4.3 for the formatting of this
parameter. If this parameter is absent, the AS assumes that the parameter. If this parameter is absent, the AS assumes that the
client implicitly knows which profile to use towards the RS. client implicitly knows which profile to use towards the RS.
token_type: token_type:
This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]. This parameter is OPTIONAL, as opposed to 'required' in [RFC6749].
By default implementations of this framework SHOULD assume that By default implementations of this framework SHOULD assume that
the token_type is "pop". If a specific use case requires another the token_type is "pop". If a specific use case requires another
token_type (e.g., "Bearer") to be used then this parameter is token_type (e.g., "Bearer") to be used then this parameter is
skipping to change at page 29, line 5 skipping to change at page 29, line 5
A profile MUST specify an identifier that MUST be used to uniquely A profile MUST specify an identifier that MUST be used to uniquely
identify itself in the "profile" parameter. The textual identify itself in the "profile" parameter. The textual
representation of the profile identifier is just intended for human representation of the profile identifier is just intended for human
readability and MUST NOT be used in parameters and claims. readability and MUST NOT be used in parameters and claims.
Profiles MAY define additional parameters for both the token request Profiles MAY define additional parameters for both the token request
and the Access Information in the access token response in order to and the Access Information in the access token response in order to
support negotiation or signaling of profile specific parameters. support negotiation or signaling of profile specific parameters.
5.6.4.4. Client-Nonce
This parameter MUST be sent from the client to the AS, if it
previously received a "cnonce" parameter in the AS Request Creation
Hints Section 5.1.2. The parameter is encoded as a byte string and
copies the value from the cnonce parameter in the AS Request Creation
Hints.
5.6.5. Mapping Parameters to CBOR 5.6.5. Mapping Parameters to CBOR
If CBOR encoding is used, all OAuth parameters in access token If CBOR encoding is used, all OAuth parameters in access token
requests and responses MUST be mapped to CBOR types as specified in requests and responses MUST be mapped to CBOR types as specified in
Figure 12, using the given integer abbreviation for the map keys. Figure 12, using the given integer abbreviation for the map keys.
Note that we have aligned the abbreviations corresponding to claims Note that we have aligned the abbreviations corresponding to claims
with the abbreviations defined in [RFC8392]. with the abbreviations defined in [RFC8392].
Note also that abbreviations from -24 to 23 have a 1 byte encoding Note also that abbreviations from -24 to 23 have a 1 byte encoding
size in CBOR. We have thus chosen to assign abbreviations in that size in CBOR. We have thus chosen to assign abbreviations in that
range to parameters we expect to be used most frequently in range to parameters we expect to be used most frequently in
constrained scenarios. constrained scenarios.
/-------------------+----------+---------------------\ /-------------------+----------+---------------------\
| Name | CBOR Key | Value Type | | Name | CBOR Key | Value Type |
|-------------------+----------+---------------------| |-------------------+----------+---------------------|
| access_token | 1 | byte string | | access_token | 1 | byte string |
| expires_in | 2 | unsigned integer |
| audience | 5 | text string |
| scope | 9 | text or byte string | | scope | 9 | text or byte string |
| audience | 18 | text string |
| client_id | 24 | text string | | client_id | 24 | text string |
| client_secret | 25 | byte string | | client_secret | 25 | byte string |
| response_type | 26 | text string | | response_type | 26 | text string |
| redirect_uri | 27 | text string | | redirect_uri | 27 | text string |
| state | 28 | text string | | state | 28 | text string |
| code | 29 | byte string | | code | 29 | byte string |
| error | 30 | unsigned integer | | error | 30 | unsigned integer |
| error_description | 31 | text string | | error_description | 31 | text string |
| error_uri | 32 | text string | | error_uri | 32 | text string |
| grant_type | 33 | unsigned integer | | grant_type | 33 | unsigned integer |
| token_type | 34 | unsigned integer | | token_type | 34 | unsigned integer |
| expires_in | 35 | unsigned integer | | username | 35 | text string |
| username | 36 | text string | | password | 36 | text string |
| password | 37 | text string | | refresh_token | 37 | byte string |
| refresh_token | 38 | byte string | | profile | 38 | unsigned integer |
| profile | 39 | unsigned integer | | cnonce | 39 | byte string |
\-------------------+----------+---------------------/ \-------------------+----------+---------------------/
Figure 12: CBOR mappings used in token requests Figure 12: CBOR mappings used in token requests
5.7. The Introspection Endpoint 5.7. The Introspection Endpoint
Token introspection [RFC7662] can be OPTIONALLY provided by the AS, 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 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 for metadata about a given token, e.g., validity or scope. Analogous
to the protocol defined in [RFC7662] for HTTP and JSON, this section to the protocol defined in [RFC7662] for HTTP and JSON, this section
skipping to change at page 31, line 38 skipping to change at page 31, line 45
error response as described in Section 5.7.3. error response as described in Section 5.7.3.
In a successful response, the AS encodes the response parameters in a In a successful response, the AS encodes the response parameters in a
map including with the same required and optional parameters as in map including with the same required and optional parameters as in
Section 2.2 of [RFC7662] with the following addition: Section 2.2 of [RFC7662] with the following addition:
profile OPTIONAL. This indicates the profile that the RS MUST use profile OPTIONAL. This indicates the profile that the RS MUST use
with the client. See Section 5.6.4.3 for more details on the with the client. See Section 5.6.4.3 for more details on the
formatting of this parameter. formatting of this parameter.
cnonce OPTIONAL. A client-nonce previously provided to the AS by
the RS via the client. See Section 5.6.4.4.
exi OPTIONAL. The "expires-in" claim associated to this access
token. See Section 5.8.3.
Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that
the AS MUST be able to use when responding to a request to the the AS MUST be able to use when responding to a request to the
introspection endpoint. introspection endpoint.
For example, Figure 15 shows an AS response to the introspection For example, Figure 15 shows an AS response to the introspection
request in Figure 13. Note that this example contains the "cnf" request in Figure 13. Note that this example contains the "cnf"
parameter defined in [I-D.ietf-ace-oauth-params]. parameter defined in [I-D.ietf-ace-oauth-params].
Header: Created Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"active" : true, "active" : true,
"scope" : "read", "scope" : "read",
"profile" : "coap_dtls", "profile" : "coap_dtls",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "Symmetric", "kty" : "Symmetric",
"kid" : b64'39Gqlw', "kid" : b64'39Gqlw',
skipping to change at page 33, line 32 skipping to change at page 33, line 39
| aud | 3 | text string | | aud | 3 | text string |
| exp | 4 | integer or | | exp | 4 | integer or |
| | | floating-point number | | | | floating-point number |
| nbf | 5 | integer or | | nbf | 5 | integer or |
| | | floating-point number | | | | floating-point number |
| iat | 6 | integer or | | iat | 6 | integer or |
| | | floating-point number | | | | floating-point number |
| cti | 7 | byte string | | cti | 7 | byte string |
| scope | 9 | text or byte string | | scope | 9 | text or byte string |
| active | 10 | True or False | | active | 10 | True or False |
| token | 12 | byte string | | token | 11 | byte string |
| client_id | 24 | text string | | client_id | 24 | text string |
| error | 30 | unsigned integer | | error | 30 | unsigned integer |
| error_description | 31 | text string | | error_description | 31 | text string |
| error_uri | 32 | text string | | error_uri | 32 | text string |
| token_type_hint | 33 | text string | | token_type_hint | 33 | text string |
| token_type | 34 | text string | | token_type | 34 | text string |
| username | 36 | text string | | username | 35 | text string |
| profile | 39 | unsigned integer | | profile | 38 | unsigned integer |
| cnonce | 39 | byte string |
| exi | 40 | unsigned integer |
\-------------------+----------+-------------------------/ \-------------------+----------+-------------------------/
Figure 16: CBOR Mappings to Token Introspection Parameters. Figure 16: CBOR Mappings to Token Introspection Parameters.
5.8. The Access Token 5.8. The Access Token
This framework RECOMMENDS the use of CBOR web token (CWT) as This framework RECOMMENDS the use of CBOR web token (CWT) as
specified in [RFC8392]. specified in [RFC8392].
In order to facilitate offline processing of access tokens, this In order to facilitate offline processing of access tokens, this
skipping to change at page 34, line 20 skipping to change at page 34, line 27
Section 3.3 of [RFC6749], but in addition implementers MAY use byte Section 3.3 of [RFC6749], but in addition implementers MAY use byte
strings as scope values, to achieve compact encoding of large scope strings as scope values, to achieve compact encoding of large scope
elements. The meaning of a specific scope value is application elements. The meaning of a specific scope value is application
specific and expected to be known to the RS running that application. specific and expected to be known to the RS running that application.
If the AS needs to convey a hint to the RS about which profile it If the AS needs to convey a hint to the RS about which profile it
should use to communicate with the client, the AS MAY include a should use to communicate with the client, the AS MAY include a
"profile" claim in the access token, with the same syntax and "profile" claim in the access token, with the same syntax and
semantics as defined in Section 5.6.4.3. semantics as defined in Section 5.6.4.3.
If the client submitted a client-nonce parameter in the access token
request Section 5.6.4.4, the AS MUST include the value of this
parameter in the "cnonce" claim specified here. The "cnonce" claim
uses binary encoding.
5.8.1. The Authorization Information Endpoint 5.8.1. The Authorization Information Endpoint
The access token, containing authorization information and The access token, containing authorization information and
information about the key used by the client, needs to be transported information about the key used by the client, needs to be transported
to the RS so that the RS can authenticate and authorize the client to the RS so that the RS can authenticate and authorize the client
request. request.
This section defines a method for transporting the access token to This section defines a method for transporting the access token to
the RS using a RESTful protocol such as CoAP. Profiles of this the RS using a RESTful protocol such as CoAP. Profiles of this
framework MAY define other methods for token transport. framework MAY define other methods for token transport.
skipping to change at page 37, line 39 skipping to change at page 38, line 7
The POST method SHOULD NOT be allowed on children of the authz-info The POST method SHOULD NOT be allowed on children of the authz-info
endpoint. 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.8.2. Client Requests to the RS 5.8.2. Client Requests to the RS
Before sending a request to a RS, the client MUST verify that the
keys used to protect this communication are still valid. See
Section 5.8.4 for details on how the client determines the validity
of the keys used.
If an RS receives a request from a client, and the target resource If an RS receives a request from a client, and the target resource
requires authorization, the RS MUST first verify that it has an requires authorization, the RS MUST first verify that it has an
access token that authorizes this request, and that the client has access token that authorizes this request, and that the client has
performed the proof-of-possession for that token. performed the proof-of-possession for that token.
The response code MUST be 4.01 (Unauthorized) in case the client has The response code MUST be 4.01 (Unauthorized) in case the client has
not performed the proof-of-possession, or if RS has no valid access not performed the proof-of-possession, or if RS has no valid access
token for the client. If RS has an access token for the client but token for the client. If RS has an access token for the client but
not for the resource that was requested, RS MUST reject the request not for the resource that was requested, RS MUST reject the request
with a 4.03 (Forbidden). If RS has an access token for the client with a 4.03 (Forbidden). If RS has an access token for the client
skipping to change at page 39, line 39 skipping to change at page 40, line 11
o The client knows a default validity period for all tokens it is o The client knows a default validity period for all tokens it is
using. This information could be provisioned to the client when using. This information could be provisioned to the client when
it is registered at the AS, or published by the AS in a way that it is registered at the AS, or published by the AS in a way that
the client can query. the client can query.
o The AS informs the client about the token validity using the o The AS informs the client about the token validity using the
"expires_in" parameter in the Access Information. "expires_in" parameter in the Access Information.
o The client performs an introspection of the token. Although this o The client performs an introspection of the token. Although this
is not explicitly forbidden, how exactly this is done is not is not explicitly forbidden, how exactly a client does
currently specified for OAuth. introspection is not currently specified for OAuth.
A client that is not able to obtain information about the expiration A client that is not able to obtain information about the expiration
of a token MUST NOT use this token. of a token MUST NOT use this token.
6. Security Considerations 6. Security Considerations
Security considerations applicable to authentication and Security considerations applicable to authentication and
authorization in RESTful environments provided in OAuth 2.0 [RFC6749] authorization in RESTful environments provided in OAuth 2.0 [RFC6749]
apply to this work. Furthermore [RFC6819] provides additional apply to this work. Furthermore [RFC6819] provides additional
security considerations for OAuth which apply to IoT deployments as security considerations for OAuth which apply to IoT deployments as
skipping to change at page 42, line 27 skipping to change at page 42, line 46
protection as well as a binding between requests and responses. protection as well as a binding between requests and responses.
This requires that the client learned either the RS's public key This requires that the client learned either the RS's public key
or received a symmetric proof-of-possession key bound to the or received a symmetric proof-of-possession key bound to the
access token from the AS. The RS must have learned either the access token from the AS. The RS must have learned either the
client's public key or a shared symmetric key from the claims in client's public key or a shared symmetric key from the claims in
the token or an introspection request. Since ACE does not provide the token or an introspection request. Since ACE does not provide
profile negotiation between C and RS, the client MUST have learned profile negotiation between C and RS, the client MUST have learned
what profile the RS supports (e.g. from the AS or pre-configured) what profile the RS supports (e.g. from the AS or pre-configured)
and initiate the communication accordingly. and initiate the communication accordingly.
6.3. Use of Nonces for Replay Protection 6.3. Use of Nonces for Token Freshness
The RS may add a nonce to the AS Request Creation Hints message sent An RS that does not synchronize its clock with the AS may be tricked
as a response to an unauthorized request to ensure freshness of an into accepting old access tokens that are no longer valid or have
Access Token subsequently presented to RS. While a time-stamp of been compromised. In order to prevent this, an RS may use the nonce-
some granularity would be sufficient to protect against replay based mechanism defined in Section 5.1.2 to ensure freshness of an
attacks, using randomized nonce is preferred to prevent disclosure of Access Token subsequently presented to this RS.
information about RS's internal clock characteristics.
6.4. Combining profiles 6.4. Combining profiles
There may be use cases were different profiles of this framework are There may be use cases were different profiles of this framework are
combined. For example, an MQTT-TLS profile is used between the combined. For example, an MQTT-TLS profile is used between the
client and the RS in combination with a CoAP-DTLS profile for client and the RS in combination with a CoAP-DTLS profile for
interactions between the client and the AS. Ideally, profiles should interactions between the client and the AS. Ideally, profiles should
be designed in a way that the security of system should not depend on be designed in a way that the security of system should not depend on
the specific security mechanisms used in individual protocol the specific security mechanisms used in individual protocol
interactions. interactions.
skipping to change at page 51, line 9 skipping to change at page 51, line 20
o Reference: Section 5.8 of [this document] o Reference: Section 5.8 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: "Expires in". Lifetime of the token in seconds o Claim Description: "Expires in". Lifetime of the token in seconds
from the time the RS first sees it. Used to implement a weaker from the time the RS first sees it. Used to implement a weaker
from of token expiration for devices that cannot synchronize their from of token expiration for devices that cannot synchronize their
internal clocks. internal clocks.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8.3 of [this document] o Reference: Section 5.8.3 of [this document]
o Claim Name: "cnonce"
o Claim Description: "client-nonce". A nonce previously provided to
the AS by the RS via the client. Used verify token freshness when
the RS cannot synchronize its clock with the AS.
o Change Controller: IESG
o Reference: Section 5.8 of [this document]
8.13. CBOR Web Token Claims 8.13. CBOR Web Token Claims
This specification registers the following new claims in the "CBOR This specification registers the following new claims in the "CBOR
Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].
o Claim Name: "scope" o Claim Name: "scope"
o Claim Description: The scope of an access token as defined in o Claim Description: The scope of an access token as defined in
[RFC6749]. [RFC6749].
o JWT Claim Name: scope o JWT Claim Name: scope
o Claim Key: TBD (suggested: 9) o Claim Key: TBD (suggested: 9)
o Claim Value Type(s): byte string or text string o Claim Value Type(s): byte string or text string
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "profile" o Claim Name: "profile"
o Claim Description: The profile a token is supposed to be used o Claim Description: The profile a token is supposed to be used
with. with.
o JWT Claim Name: profile o JWT Claim Name: profile
o Claim Key: TBD (suggested: 39) o Claim Key: TBD (suggested: 38)
o Claim Value Type(s): integer o Claim Value Type(s): integer
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: The expiration time of a token measured from o Claim Description: The expiration time of a token measured from
when it was received at the RS in seconds. when it was received at the RS in seconds.
o JWT Claim Name: exi o JWT Claim Name: exi
o Claim Key: TBD (suggested: 41) o Claim Key: TBD (suggested: 40)
o Claim Value Type(s): integer o Claim Value Type(s): integer
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8.3 of [this document]
o Claim Name: "cnonce"
o Claim Description: The client-nonce sent to the AS by the RS via
the client.
o JWT Claim Name: cnonce
o Claim Key: TBD (suggested: 39)
o Claim Value Type(s): byte string
o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
8.14. Media Type Registrations 8.14. Media Type Registrations
This specification registers the 'application/ace+cbor' media type This specification registers the 'application/ace+cbor' media type
for messages of the protocols defined in this document carrying for messages of the protocols defined in this document carrying
parameters encoded in CBOR. This registration follows the procedures parameters encoded in CBOR. This registration follows the procedures
specified in [RFC6838]. specified in [RFC6838].
Type name: application Type name: application
skipping to change at page 54, line 21 skipping to change at page 54, line 47
Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for
contributing their work on AS discovery from draft-gerdes-ace-dcaf- contributing their work on AS discovery from draft-gerdes-ace-dcaf-
authorize (see Section 5.1). authorize (see Section 5.1).
Thanks to Jim Schaad and Mike Jones for their comprehensive reviews. Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.
Thanks to Benjamin Kaduk for his input on various questions related Thanks to Benjamin Kaduk for his input on various questions related
to this work. to this work.
Thanks to Cigdem Sengul for some very useful review comments.
Ludwig Seitz and Goeran Selander worked on this document as part of Ludwig Seitz and Goeran Selander worked on this document as part of
the CelticPlus project CyberWI, with funding from Vinnova. the CelticPlus project CyberWI, with funding from Vinnova. Ludwig
Seitz was also received further funding for this work by Vinnova in
the context of the CelticNext project Critisec.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-06 (work in progress), February 2019. possession-06 (work in progress), February 2019.
skipping to change at page 56, line 41 skipping to change at page 57, line 27
10.2. Informative References 10.2. Informative References
[I-D.erdtman-ace-rpcc] [I-D.erdtman-ace-rpcc]
Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
Key as OAuth client credentials", draft-erdtman-ace- Key as OAuth client credentials", draft-erdtman-ace-
rpcc-02 (work in progress), October 2017. rpcc-02 (work in progress), October 2017.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), August 2018. progress), March 2019.
[I-D.ietf-oauth-device-flow] [I-D.ietf-oauth-device-flow]
Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Flow for Browserless and Input "OAuth 2.0 Device Authorization Grant", draft-ietf-oauth-
Constrained Devices", draft-ietf-oauth-device-flow-14 device-flow-15 (work in progress), March 2019.
(work in progress), January 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress), 1.3", draft-ietf-tls-dtls13-30 (work in progress),
November 2018. November 2018.
[Margi10impact] [Margi10impact]
Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr, Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,
M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,
 End of changes. 60 change blocks. 
133 lines changed or deleted 217 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/