draft-ietf-ace-oauth-authz-27.txt   draft-ietf-ace-oauth-authz-28.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft RISE Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: May 24, 2020 Ericsson Expires: June 16, 2020 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
November 21, 2019 December 14, 2019
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)
using the OAuth 2.0 Framework (ACE-OAuth) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-27 draft-ietf-ace-oauth-authz-28
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and CoAP, thus transforming a well-known and widely used OAuth 2.0 and CoAP, thus transforming a well-known and widely used
authorization solution into a form suitable for IoT devices. authorization solution into a form suitable for IoT devices.
Existing specifications are used where possible, but extensions are Existing specifications are used where possible, but extensions are
added and profiles are defined to better serve the IoT use cases. added and profiles are defined to better serve the IoT use cases.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 24, 2020. This Internet-Draft will expire on June 16, 2020.
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 3, line 18 skipping to change at page 3, line 18
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42
6.2. Communication Security . . . . . . . . . . . . . . . . . 43 6.2. Communication Security . . . . . . . . . . . . . . . . . 43
6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43
6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44
6.5. Minimal security requirements for communication . 45 6.5. Minimal security requirements for communication . 45
6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46
6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 46 6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47
6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 47 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48
6.10. Denial of service against or with Introspection . . 48 6.10. Denial of service against or with Introspection . . 48
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.1. ACE Authorization Server Request Creation Hints . . . . . 50 8.1. ACE Authorization Server Request Creation Hints . . . . . 50
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 50 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 51
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52
8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 52 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 52
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 52 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 53 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 53
8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 53 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 53
8.10. OAuth Introspection Response Parameter Registration . . . 54 8.10. OAuth Introspection Response Parameter Registration . . . 54
8.11. OAuth Token Introspection Response CBOR Mappings Registry 54 8.11. OAuth Token Introspection Response CBOR Mappings Registry 54
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57
8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59
10.2. Informative References . . . . . . . . . . . . . . . . . 61 10.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 Appendix A. Design Justification . . . . . . . . . . . . . . . . 64
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 70 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72
E.2. Introspection Aided Token Validation . . . . . . . . . . 75 E.2. Introspection Aided Token Validation . . . . . . . . . . 76
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 79 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80
F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 80 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81
F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 80 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81
F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 80 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81
F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 80 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81
F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 80 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81
F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 80 F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81
F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 81 F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82
F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 81 F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 82
F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 81 F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 82
F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 81 F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 82
F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 82 F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 83
F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 82 F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 83
F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 82 F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 83
F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 82 F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 83
F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 82 F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 83
F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 83 F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 84
F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 83 F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 84
F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 83 F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 84
F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 84 F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 85
F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 84 F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 85
F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 84 F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 85
F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 85 F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
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 generic resource [RFC4949]. The authorization task itself access a generic resource [RFC4949]. The authorization task itself
can best be described as granting access to a requesting client, for can best be described as granting access to a requesting client, for
a resource hosted on a device, the resource server (RS). This a resource hosted on a device, the resource server (RS). This
exchange is mediated by one or multiple authorization servers (AS). exchange is mediated by one or multiple authorization servers (AS).
Managing authorization for a large number of devices and users can be Managing authorization for a large number of devices and users can be
a complex task. a complex task.
skipping to change at page 42, line 43 skipping to change at page 42, line 43
If the token is intended for multiple recipients (i.e. an audience If the token is intended for multiple recipients (i.e. an audience
that is a group), integrity protection of the token with a symmetric that is a group), integrity protection of the token with a symmetric
key, shared between the AS and the recipients, is not sufficient, key, shared between the AS and the recipients, is not sufficient,
since any of the recipients could modify the token undetected by the since any of the recipients could modify the token undetected by the
other recipients. Therefore a token with a multi-recipient audience other recipients. Therefore a token with a multi-recipient audience
MUST be protected with an asymmetric signature. MUST be protected with an asymmetric signature.
It is important for the authorization server to include the identity It is important for the authorization server to include the identity
of the intended recipient (the audience), typically a single resource of the intended recipient (the audience), typically a single resource
server (or a list of resource servers), in the token. Using a single server (or a list of resource servers), in the token. The same
shared secret as proof-of-possession key with multiple resource shared secret MUST NOT be used as proof-of-possession key with
servers is NOT RECOMMENDED since the benefit from using the proof-of- multiple resource servers since the benefit from using the proof-of-
possession concept is then significantly reduced. possession concept is then significantly reduced.
If clients are capable of doing so, they should frequently request If clients are capable of doing so, they should frequently request
fresh access tokens, as this allows the AS to keep the lifetime of fresh access tokens, as this allows the AS to keep the lifetime of
the tokens short. This allows the AS to use shorter proof-of- the tokens short. This allows the AS to use shorter proof-of-
possession key sizes, which translate to a performance benefit for possession key sizes, which translate to a performance benefit for
the client and for the resource server. Shorter keys also lead to the client and for the resource server. Shorter keys also lead to
shorter messages (particularly with asymmetric keying material). shorter messages (particularly with asymmetric keying material).
When authorization servers bind symmetric keys to access tokens, they When authorization servers bind symmetric keys to access tokens, they
skipping to change at page 43, line 21 skipping to change at page 43, line 21
that is still valid. Client-initiated revocation is specified in that is still valid. Client-initiated revocation is specified in
[RFC7009] for OAuth 2.0. Other revocation mechanisms are currently [RFC7009] for OAuth 2.0. Other revocation mechanisms are currently
not specified, as the underlying assumption in OAuth is that access not specified, as the underlying assumption in OAuth is that access
tokens are issued with a relatively short lifetime. This may not tokens are issued with a relatively short lifetime. This may not
hold true for disconnected constrained devices, needing access tokens hold true for disconnected constrained devices, needing access tokens
with relatively long lifetimes, and would therefore necessitate with relatively long lifetimes, and would therefore necessitate
further standardization work that is out of scope for this document. further standardization work that is out of scope for this document.
6.2. Communication Security 6.2. Communication Security
The authorization server MUST offer confidentiality protection for Communication with the authorization server MUST use confidentiality
any interactions with the client. This step is extremely important protection. This step is extremely important since the client or the
since the client may obtain the proof-of-possession key from the RS may obtain the proof-of-possession key from the authorization
authorization server for use with a specific access token. Not using server for use with a specific access token. Not using
confidentiality protection exposes this secret (and the access token) confidentiality protection exposes this secret (and the access token)
to an eavesdropper thereby completely negating proof-of-possession to an eavesdropper thereby completely negating proof-of-possession
security. Profiles MUST specify how communication security according security. Profiles MUST specify how communication security according
to the requirements in Section 5 is provided. to the requirements in Section 5 is provided.
Additional protection for the access token can be applied by Additional protection for the access token can be applied by
encrypting it, for example encryption of CWTs is specified in encrypting it, for example encryption of CWTs is specified in
Section 5.1 of [RFC8392]. Such additional protection can be Section 5.1 of [RFC8392]. Such additional protection can be
necessary if the token is later transferred over an insecure necessary if the token is later transferred over an insecure
connection (e.g. when it is sent to the authz-info endpoint). connection (e.g. when it is sent to the authz-info endpoint).
skipping to change at page 44, line 12 skipping to change at page 44, line 12
need to be protected against unauthorized access. In constrained need to be protected against unauthorized access. In constrained
devices, deployed in publicly accessible places, such protection can devices, deployed in publicly accessible places, such protection can
be difficult to achieve without specialized hardware (e.g. secure key be difficult to achieve without specialized hardware (e.g. secure key
storage memory). storage memory).
If credentials are lost or compromised, the operator of the affected If credentials are lost or compromised, the operator of the affected
devices needs to have procedures to invalidate any access these devices needs to have procedures to invalidate any access these
credentials give and to revoke tokens linked to such credentials. credentials give and to revoke tokens linked to such credentials.
The loss of a credential linked to a specific device MUST NOT lead to The loss of a credential linked to a specific device MUST NOT lead to
a compromise of other credentials not linked to that device, a compromise of other credentials not linked to that device,
therefore sharing secret keys between more than two parties is NOT therefore secret keys used for authentication MUST NOT be shared
RECOMMENDED. between more than two parties.
Operators of clients or RS should have procedures in place to replace Operators of clients or RS SHOULD have procedures in place to replace
credentials that are suspected to have been compromised or that have credentials that are suspected to have been compromised or that have
been lost. been lost.
Operators also need to have procedures for decommissioning devices, Operators also SHOULD have procedures for decommissioning devices,
that include securely erasing credentials and other security critical that include securely erasing credentials and other security critical
material in the devices being decommissioned. material in the devices being decommissioned.
6.4. Unprotected AS Request Creation Hints 6.4. Unprotected AS Request Creation Hints
Initially, no secure channel exists to protect the communication Initially, no secure channel exists to protect the communication
between C and RS. Thus, C cannot determine if the AS Request between C and RS. Thus, C cannot determine if the AS Request
Creation Hints contained in an unprotected response from RS to an Creation Hints contained in an unprotected response from RS to an
unauthorized request (see Section 5.1.2) are authentic. It is unauthorized request (see Section 5.1.2) are authentic. It is
therefore advisable to provide C with a (possibly hard-coded) list of therefore advisable to provide C with a (possibly hard-coded) list of
skipping to change at page 45, line 38 skipping to change at page 45, line 38
exchanged either a shared secret, or their public keys in order to exchanged either a shared secret, or their public keys in order to
negotiate a secure communication. Furthermore the RS MUST be able negotiate a secure communication. Furthermore the RS MUST be able
to determine whether an AS has the authority to issue access to determine whether an AS has the authority to issue access
tokens itself. This is usually configured out of band, but could tokens itself. This is usually configured out of band, but could
also be performed through an online lookup mechanism provided that also be performed through an online lookup mechanism provided that
it is also secured in the same way. it is also secured in the same way.
C-RS The initial communication between the client and the Resource C-RS The initial communication between the client and the Resource
Server can not be secured in general, since the RS is not in Server can not be secured in general, since the RS is not in
possession of on access token for that client, which would carry possession of on access token for that client, which would carry
the necessary parameters. Certain security mechanisms (e.g. DTLS the necessary parameters. If both parties support DTLS without
with server-side authentication via a certificate or a raw public client authentication it is RECOMMEND to use this mechanism for
key) can be possible and are RECOMMEND if supported by both protecting the initial communication. After the client has
parties. After the client has successfully transmitted the access successfully transmitted the access token to the RS, a secure
token to the RS, a secure communication protocol MUST be communication protocol MUST be established between client and RS
established between client and RS for the actual resource request. for the actual resource request. This protocol MUST provide
This protocol MUST provide confidentiality, integrity and replay confidentiality, integrity and replay protection as well as a
protection as well as a binding between requests and responses. binding between requests and responses. This requires that the
This requires that the client learned either the RS's public key client learned either the RS's public key or received a symmetric
or received a symmetric proof-of-possession key bound to the proof-of-possession key bound to the access token from the AS.
access token from the AS. The RS must have learned either the The RS must have learned either the client's public key or a
client's public key or a shared symmetric key from the claims in shared symmetric key from the claims in the token or an
the token or an introspection request. Since ACE does not provide introspection request. Since ACE does not provide profile
profile negotiation between C and RS, the client MUST have learned negotiation between C and RS, the client MUST have learned what
what profile the RS supports (e.g. from the AS or pre-configured) profile the RS supports (e.g. from the AS or pre-configured) and
and initiate the communication accordingly. initiate the communication accordingly.
6.6. Token Freshness and Expiration 6.6. Token Freshness and Expiration
An RS that is offline faces the problem of clock drift. Since it An RS that is offline faces the problem of clock drift. Since it
cannot synchronize its clock with the AS, it may be tricked into cannot synchronize its clock with the AS, it may be tricked into
accepting old access tokens that are no longer valid or have been accepting old access tokens that are no longer valid or have been
compromised. In order to prevent this, an RS may use the nonce-based compromised. In order to prevent this, an RS may use the nonce-based
mechanism defined in Section 5.1.2 to ensure freshness of an Access mechanism defined in Section 5.1.2 to ensure freshness of an Access
Token subsequently presented to this RS. Token subsequently presented to this RS.
Another problem with clock drift is that evaluating the standard Another problem with clock drift is that evaluating the standard
token expiration claim "exp" can give unpredictable results. token expiration claim "exp" can give unpredictable results.
Acceptable ranges of clock drift are highly dependent on the concrete
application. Important factors are how long access tokens are valid,
and how critical timely expiration of access token is.
The expiration mechanism implemented by the "exi" claim, based on the The expiration mechanism implemented by the "exi" claim, based on the
first time the RS sees the token was defined to provide a more first time the RS sees the token was defined to provide a more
predictable alternative. The "exi" approach has some drawbacks that predictable alternative. The "exi" approach has some drawbacks that
need to be considered: need to be considered:
A malicious client may hold back tokens with the "exi" claim in A malicious client may hold back tokens with the "exi" claim in
order to prolong their lifespan. order to prolong their lifespan.
If an RS loses state (e.g. due to an unscheduled reboot), it may If an RS loses state (e.g. due to an unscheduled reboot), it may
loose the current values of counters tracking the "exi" claims of loose the current values of counters tracking the "exi" claims of
skipping to change at page 47, line 12 skipping to change at page 47, line 19
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. The security of a interactions between the client and the AS. The security of a
profile MUST NOT depend on the assumption that the profile is used profile MUST NOT depend on the assumption that the profile is used
for all the different types of interactions in this framework. for all the different types of interactions in this framework.
6.8. Unprotected Information 6.8. Unprotected Information
Communication with the authz-info endpoint, as well as the various Communication with the authz-info endpoint, as well as the various
error responses defined in this framework, all potentially include error responses defined in this framework, all potentially include
sending information over an unprotected channel. These messages may sending information over an unprotected channel. These messages may
leak information to an adversary. For example error responses for leak information to an adversary, or may be manipulated by active
requests to the Authorization Information endpoint can reveal attackers to induce incorrect behavior. For example error responses
for requests to the Authorization Information endpoint can reveal
information about an otherwise opaque access token to an adversary information about an otherwise opaque access token to an adversary
who has intercepted this token. who has intercepted this token.
As far as error messages are concerned, this framework is written As far as error messages are concerned, this framework is written
under the assumption that, in general, the benefits of detailed error under the assumption that, in general, the benefits of detailed error
messages outweigh the risk due to information leakage. For messages outweigh the risk due to information leakage. For
particular use cases, where this assessment does not apply, detailed particular use cases, where this assessment does not apply, detailed
error messages can be replaced by more generic ones. error messages can be replaced by more generic ones.
In some scenarios it may be possible to protect the communication In some scenarios it may be possible to protect the communication
skipping to change at page 47, line 38 skipping to change at page 47, line 46
If the initial unauthorized resource request message (see If the initial unauthorized resource request message (see
Section 5.1.1) is used, the client MUST make sure that it is not Section 5.1.1) is used, the client MUST make sure that it is not
sending sensitive content in this request. While GET and DELETE sending sensitive content in this request. While GET and DELETE
requests only reveal the target URI of the resource, POST and PUT requests only reveal the target URI of the resource, POST and PUT
requests would reveal the whole payload of the intended operation. requests would reveal the whole payload of the intended operation.
Since the client is not authenticated at the point when it is Since the client is not authenticated at the point when it is
submitting an access token to the authz-info endpoint, attackers may submitting an access token to the authz-info endpoint, attackers may
be pretending to be a client and trying to trick an RS to use an be pretending to be a client and trying to trick an RS to use an
obsole profile that in turn specifies a vulnerable security mechanism obsolete profile that in turn specifies a vulnerable security
via the authz-info endpoint. Such an attack would require a valid mechanism via the authz-info endpoint. Such an attack would require
access token containing a "profile" claim requesting the use of said a valid access token containing an "ace_profile" claim requesting the
obsolete profile. Resource Owners should update the configuration of use of said obsolete profile. Resource Owners should update the
their RS's to prevent them from using such obsolete profiles. configuration of their RS's to prevent them from using such obsolete
profiles.
6.9. Identifying audiences 6.9. Identifying audiences
The audience claim as defined in [RFC7519] and the equivalent The audience claim as defined in [RFC7519] and the equivalent
"audience" parameter from [I-D.ietf-oauth-token-exchange] are "audience" parameter from [I-D.ietf-oauth-token-exchange] are
intentionally vague on how to match the audience value to a specific intentionally vague on how to match the audience value to a specific
RS. This is intended to allow application specific semantics to be RS. This is intended to allow application specific semantics to be
used. This section attempts to give some general guidance for the used. This section attempts to give some general guidance for the
use of audiences in constrained environments. use of audiences in constrained environments.
skipping to change at page 57, line 20 skipping to change at page 57, line 25
Macintosh file type code(s): n/a Macintosh file type code(s): n/a
Person & email address to contact for further information: Person & email address to contact for further information:
<iesg@ietf.org> <iesg@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Ludwig Seitz <ludwig.setiz@ri.se> Author: Ludwig Seitz <ludwig.setiz@combitech.se>
Change controller: IESG Change controller: IESG
8.15. CoAP Content-Format Registry 8.15. CoAP Content-Format Registry
This specification registers the following entry to the "CoAP This specification registers the following entry to the "CoAP
Content-Formats" registry: Content-Formats" registry:
Media Type: application/ace+cbor Media Type: application/ace+cbor
skipping to change at page 58, line 6 skipping to change at page 58, line 12
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already that the usage is not going to duplicate one that is already
registered, and that the point is likely to be used in registered, and that the point is likely to be used in
deployments. The zones tagged as private use are intended for deployments. The zones tagged as private use are intended for
testing purposes and closed environments; code points in other testing purposes and closed environments; code points in other
ranges should not be assigned for testing. ranges should not be assigned for testing.
o Specifications are needed for the first-come, first-serve range if
they are expected to be used outside of closed environments in an
interoperable way. When specifications are not provided, the
description provided needs to have sufficient information to
identify what the point is being used for.
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be code points of that length are left, the size of device it will be
used on. used on.
o Since a high degree of overlap is expected between these o Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters registries and the contents of the OAuth parameters
[IANA.OAuthParameters] registries, experts should require new [IANA.OAuthParameters] registries, experts should require new
skipping to change at page 59, line 27 skipping to change at page 59, line 34
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-06 (work in progress), November 2019. params-06 (work in progress), November 2019.
[I-D.ietf-oauth-token-exchange] [I-D.ietf-oauth-token-exchange]
Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
token-exchange-19 (work in progress), July 2019. token-exchange-19 (work in progress), July 2019.
[IANA.CborWebTokenClaims] [IANA.CborWebTokenClaims]
IANA, "CBOR Web Token (CWT) Claims", IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt/ <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
cwt.xhtml#claims-registry>. registry>.
[IANA.JsonWebTokenClaims] [IANA.JsonWebTokenClaims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>. <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.
[IANA.OAuthAccessTokenTypes] [IANA.OAuthAccessTokenTypes]
IANA, "OAuth Access Token Types", IANA, "OAuth Access Token Types",
<https://www.iana.org/assignments/oauth-parameters/ <https://www.iana.org/assignments/oauth-parameters/oauth-
oauth-parameters.xhtml#token-types>. parameters.xhtml#token-types>.
[IANA.OAuthExtensionsErrorRegistry] [IANA.OAuthExtensionsErrorRegistry]
IANA, "OAuth Extensions Error Registry", IANA, "OAuth Extensions Error Registry",
<https://www.iana.org/assignments/oauth-parameters/ <https://www.iana.org/assignments/oauth-parameters/oauth-
oauth-parameters.xhtml#extensions-error>. parameters.xhtml#extensions-error>.
[IANA.OAuthParameters] [IANA.OAuthParameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<https://www.iana.org/assignments/oauth-parameters/ <https://www.iana.org/assignments/oauth-parameters/oauth-
oauth-parameters.xhtml#parameters>. parameters.xhtml#parameters>.
[IANA.TokenIntrospectionResponse] [IANA.TokenIntrospectionResponse]
IANA, "OAuth Token Introspection Response", IANA, "OAuth Token Introspection Response",
<https://www.iana.org/assignments/oauth-parameters/ <https://www.iana.org/assignments/oauth-parameters/oauth-
oauth-parameters.xhtml#token-introspection-response>. parameters.xhtml#token-introspection-response>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 61, line 34 skipping to change at page 61, line 43
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
10.2. Informative References 10.2. Informative References
[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1", [BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",
Section 4.4, January 2019, Section 4.4, January 2019,
<https://www.bluetooth.com/specifications/ <https://www.bluetooth.com/specifications/bluetooth-core-
bluetooth-core-specification/>. specification/>.
[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-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-24 (work and Secure Transport", draft-ietf-quic-transport-24 (work
in progress), November 2019. in progress), November 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-34 (work in progress), November 1.3", draft-ietf-tls-dtls13-34 (work in progress),
2019. November 2019.
[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,
"Impact of Operating Systems on Wireless Sensor Networks "Impact of Operating Systems on Wireless Sensor Networks
(Security) Applications and Testbeds", Proceedings of (Security) Applications and Testbeds", Proceedings of
the 19th International Conference on Computer the 19th International Conference on Computer
Communications and Networks (ICCCN), August 2010. Communications and Networks (ICCCN), August 2010.
[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT [MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT
Version 5.0", OASIS Standard, March 2019, Version 5.0", OASIS Standard, March 2019,
<https://docs.oasis-open.org/mqtt/mqtt/v5.0/ <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
mqtt-v5.0.html>. v5.0.html>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013, DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>. <https://www.rfc-editor.org/info/rfc6819>.
skipping to change at page 85, line 41 skipping to change at page 86, line 41
o 5.3.2. Defined success and error responses from the RS when o 5.3.2. Defined success and error responses from the RS when
receiving an access token. receiving an access token.
o 5.6.:Added section giving guidance on how to handle token o 5.6.:Added section giving guidance on how to handle token
expiration in the absence of reliable time. expiration in the absence of reliable time.
o Appendix B Added list of roles and responsibilities for C, AS and o Appendix B Added list of roles and responsibilities for C, AS and
RS. RS.
Authors' Addresses Authors' Addresses
Ludwig Seitz Ludwig Seitz
RISE Combitech
Scheelevaegen 17 Djaeknegatan 31
Lund 223 70 Malmoe 211 35
Sweden Sweden
Email: ludwig.seitz@ri.se Email: ludwig.seitz@combitech.se
Goeran Selander Goeran Selander
Ericsson Ericsson
Faroegatan 6 Faroegatan 6
Kista 164 80 Kista 164 80
Sweden Sweden
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
Erik Wahlstroem Erik Wahlstroem
Sweden Sweden
 End of changes. 34 change blocks. 
92 lines changed or deleted 103 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/