draft-ietf-ace-oauth-authz-23.txt   draft-ietf-ace-oauth-authz-24.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 26, 2019 Ericsson Expires: September 28, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
March 25, 2019 March 27, 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-23 draft-ietf-ace-oauth-authz-24
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 26, 2019. This Internet-Draft will expire on September 28, 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 39 skipping to change at page 2, line 39
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.1.2.1. The Client-Nonce Parameter . . . . . . . . . . . 19 5.1.2.1. The Client-Nonce Parameter . . . . . . . . . . . 19
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 20 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 20
5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20
5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 21 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 21
5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 21 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 21
5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21
5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22
5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 24 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25
5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 26 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 27
5.6.4. Request and Response Parameters . . . . . . . . . . . 27 5.6.4. Request and Response Parameters . . . . . . . . . . . 28
5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 27 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . 29
5.6.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . 30 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 30
5.7.1. Introspection Request . . . . . . . . . . . . . . . . 30 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 31
5.7.2. Introspection Response . . . . . . . . . . . . . . . 31 5.7.2. Introspection Response . . . . . . . . . . . . . . . 32
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 33
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 34
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 34 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 34
5.8.1. The Authorization Information Endpoint . . . . . . . 34 5.8.1. The Authorization Information Endpoint . . . . . . . 35
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 36
5.8.1.2. Protecting the Authorization Information 5.8.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 37 Endpoint . . . . . . . . . . . . . . . . . . . . 38
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 38 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 38
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 39
5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 39 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 42
6.2. Minimal security requirements for communication . 41 6.2. Minimal security requirements for communication . 42
6.3. Use of Nonces for Token Freshness . . . . . . . . . . . . 42 6.3. Use of Nonces for Token Freshness . . . . . . . . . . . . 43
6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 43 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 44
6.5. Unprotected Information . . . . . . . . . . . . . . . . . 43 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 44
6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43 6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 44
6.7. Denial of service against or with Introspection . . 44 6.7. Denial of service against or with Introspection . . 45
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 46
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
8.1. ACE Authorization Server Request Creation Hints . . . . . 45 8.1. ACE Authorization Server Request Creation Hints . . . . . 46
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 47
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 47
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 47 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 48
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 48
8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 48 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 49
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 49
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 49
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 50
8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 50
8.10. OAuth Introspection Response Parameter Registration . . . 50 8.10. OAuth Introspection Response Parameter Registration . . . 51
8.11. OAuth Token Introspection Response CBOR Mappings Registry 50 8.11. OAuth Token Introspection Response CBOR Mappings Registry 51
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 51
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 52
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 52 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 53
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 53 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 54
8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 54
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.1. Normative References . . . . . . . . . . . . . . . . . . 55 10.1. Normative References . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . 57 10.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Design Justification . . . . . . . . . . . . . . . . 59 Appendix A. Design Justification . . . . . . . . . . . . . . . . 60
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 63 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 64
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 65 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 66
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 66 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 67
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 66 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 67
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 67
E.2. Introspection Aided Token Validation . . . . . . . . . . 71 E.2. Introspection Aided Token Validation . . . . . . . . . . 72
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 75 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 76
F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 75 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 76
F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 75 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 76
F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 75 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 76
F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 76 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 77
F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 76 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 77
F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 76 F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 77
F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 77 F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 78
F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 77 F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 78
F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 77 F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 78
F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 77 F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 78
F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 77 F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 78
F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 78 F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 79
F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 78 F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 79
F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 78 F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 79
F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 78 F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 79
F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 79 F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 80
F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 79 F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 80
F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 79 F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 80
F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 79 F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 80
F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 79 F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 80
F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 80 F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 81
F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 80 F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
Authorization is the process for granting approval to an entity to Authorization is the process for granting approval to an entity to
access a 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 22, line 35 skipping to change at page 22, line 35
OPTIONAL to request an access token bound to a specific audience. OPTIONAL to request an access token bound to a specific audience.
o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if
the RS provided a client-nonce in the "AS Request Creation Hints" the RS provided a client-nonce in the "AS Request Creation Hints"
message Section 5.1.2 message Section 5.1.2
o The "scope" parameter MAY be encoded as a byte string instead of o The "scope" parameter MAY be encoded as a byte string instead of
the string encoding specified in section 3.3 of [RFC6749], in the string encoding specified in section 3.3 of [RFC6749], in
order allow compact encoding of complex scopes. order allow compact encoding of complex scopes.
o The client can send an empty (null value) "profile" parameter to
indicate that it wants the AS to include the "profile" parameter
in the response. See Section 5.6.4.3.
o A client MUST be able to use the parameters from o A client MUST be able to use the parameters from
[I-D.ietf-ace-oauth-params] in an access token request to the [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 token endpoint and the AS MUST be able to process these additional
parameters. parameters.
If CBOR is used then these parameters MUST be encoded as a CBOR map. 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
skipping to change at page 25, line 8 skipping to change at page 25, line 34
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 Appendix D). This prior knowledge may, for example, be set by the
use 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 unless the request included an empty profile parameter in
towards the RS. See Section 5.6.4.3 for the formatting of this which case it is MANDATORY. This indicates the profile that the
parameter. If this parameter is absent, the AS assumes that the client MUST use towards the RS. See Section 5.6.4.3 for the
client implicitly knows which profile to use towards the RS. formatting of this parameter. If this parameter is absent, the AS
assumes that the 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
REQUIRED. REQUIRED.
Furthermore [I-D.ietf-ace-oauth-params] defines additional parameters Furthermore [I-D.ietf-ace-oauth-params] defines additional parameters
that the AS MUST be able to use when responding to a request to the that the AS MUST be able to use when responding to a request to the
skipping to change at page 29, line 5 skipping to change at page 29, line 23
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.
Clients that want the AS to provide them with the "profile" parameter
in the access token response can indicate that by sending a profile
parameter with a null value in the access token request.
5.6.4.4. Client-Nonce 5.6.4.4. Client-Nonce
This parameter MUST be sent from the client to the AS, if it This parameter MUST be sent from the client to the AS, if it
previously received a "cnonce" parameter in the AS Request Creation previously received a "cnonce" parameter in the AS Request Creation
Hints Section 5.1.2. The parameter is encoded as a byte string and 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 copies the value from the cnonce parameter in the AS Request Creation
Hints. Hints.
5.6.5. Mapping Parameters to CBOR 5.6.5. Mapping Parameters to CBOR
 End of changes. 13 change blocks. 
84 lines changed or deleted 94 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/