< draft-ietf-ace-oauth-authz-25.txt   draft-ietf-ace-oauth-authz-26.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: May 2, 2020 Ericsson Expires: May 22, 2020 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
October 30, 2019 November 19, 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-25 draft-ietf-ace-oauth-authz-26
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 2, 2020. This Internet-Draft will expire on May 22, 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 14 skipping to change at page 3, line 14
5.8.1. The Authorization Information Endpoint . . . . . . . 36 5.8.1. The Authorization Information Endpoint . . . . . . . 36
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37
5.8.1.2. Protecting the Authorization Information 5.8.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 39 Endpoint . . . . . . . . . . . . . . . . . . . . 39
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 . . . . . . . . . . . . . . . . . . 44
6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44
6.5. Minimal security requirements for communication . 44 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 . . . . . . . . . . . . . . . . . 46 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 . . . . . . . . . . . . . . . . . . . 48 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.1. ACE Authorization Server Request Creation Hints . . . . . 49 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 . . . . . . . . . 50 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 . . . . . . . . . . . . . . . . 51 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52
8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 51 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 . . . 53 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 . . . . . . . . . . . . . . . . . . 54 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 . . . . . . . . . . . . . . . . . . . . . . . . . 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1. Normative References . . . . . . . . . . . . . . . . . . 58 10.1. Normative References . . . . . . . . . . . . . . . . . . 59
10.2. Informative References . . . . . . . . . . . . . . . . . 61 10.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. Design Justification . . . . . . . . . . . . . . . . 63 Appendix A. Design Justification . . . . . . . . . . . . . . . . 64
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 69 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 . . . . . . . . . . . . . . . . 70 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71
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 resource [RFC4949]. The authorization task itself can best access a generic resource [RFC4949]. The authorization task itself
be described as granting access to a requesting client, for a can best be described as granting access to a requesting client, for
resource hosted on a device, the resource server (RS). This exchange a resource hosted on a device, the resource server (RS). This
is mediated by one or multiple authorization servers (AS). Managing exchange is mediated by one or multiple authorization servers (AS).
authorization for a large number of devices and users can be a Managing authorization for a large number of devices and users can be
complex task. a complex task.
While prior work on authorization solutions for the Web and for the While prior work on authorization solutions for the Web and for the
mobile environment also applies to the Internet of Things (IoT) mobile environment also applies to the Internet of Things (IoT)
environment, many IoT devices are constrained, for example, in terms environment, many IoT devices are constrained, for example, in terms
of processing capabilities, available memory, etc. For web of processing capabilities, available memory, etc. For web
applications on constrained nodes, this specification RECOMMENDS the applications on constrained nodes, this specification RECOMMENDS the
use of CoAP [RFC7252] as replacement for HTTP. use of CoAP [RFC7252] as replacement for HTTP.
A detailed treatment of constraints can be found in [RFC7228], and A detailed treatment of constraints can be found in [RFC7228], and
the different IoT deployments present a continuous range of device the different IoT deployments present a continuous range of device
skipping to change at page 11, line 15 skipping to change at page 11, line 15
security for CoAP over a different transport in a uniform way, is to security for CoAP over a different transport in a uniform way, is to
provide security at the application layer using an object-based provide security at the application layer using an object-based
security mechanism such as COSE [RFC8152]. security mechanism such as COSE [RFC8152].
One application of COSE is OSCORE [RFC8613], which provides end-to- One application of COSE is OSCORE [RFC8613], which provides end-to-
end confidentiality, integrity and replay protection, and a secure end confidentiality, integrity and replay protection, and a secure
binding between CoAP request and response messages. In OSCORE, the binding between CoAP request and response messages. In OSCORE, the
CoAP messages are wrapped in COSE objects and sent using CoAP. CoAP messages are wrapped in COSE objects and sent using CoAP.
This framework RECOMMENDS the use of CoAP as replacement for HTTP for This framework RECOMMENDS the use of CoAP as replacement for HTTP for
use in constrained environments. use in constrained environments. For communication security this
framework does not make an explicit protocol recommendation, since
the choice depends on the requirements of the specific application.
DTLS [RFC6347], [I-D.ietf-tls-dtls13] and OSCORE [RFC8613] are
mentioned as examples, other protocols fulfilling the requirements
from Section 6.5 are also applicable.
4. Protocol Interactions 4. Protocol Interactions
The ACE framework is based on the OAuth 2.0 protocol interactions The ACE framework is based on the OAuth 2.0 protocol interactions
using the token endpoint and optionally the introspection endpoint. using the token endpoint and optionally the introspection endpoint.
A client obtains an access token, and optionally a refresh token, A client obtains an access token, and optionally a refresh token,
from an AS using the token endpoint and subsequently presents the from an AS using the token endpoint and subsequently presents the
access token to a RS to gain access to a protected resource. In most access token to a RS to gain access to a protected resource. In most
deployments the RS can process the access token locally, however in deployments the RS can process the access token locally, however in
some cases the RS may present it to the AS via the introspection some cases the RS may present it to the AS via the introspection
skipping to change at page 15, line 19 skipping to change at page 15, line 19
The following sections detail the profiling and extensions of OAuth The following sections detail the profiling and extensions of OAuth
2.0 for constrained environments, which constitutes the ACE 2.0 for constrained environments, which constitutes the ACE
framework. framework.
Credential Provisioning Credential Provisioning
For IoT, it cannot be assumed that the client and RS are part of a For IoT, it cannot be assumed that the client and RS are part of a
common key infrastructure, so the AS provisions credentials or common key infrastructure, so the AS provisions credentials or
associated information to allow mutual authentication between associated information to allow mutual authentication between
client and RS. The resulting security association between client client and RS. The resulting security association between client
and RS may then be re-used by binding these credentials to and RS may then also be used to bind these credentials to the
additional access tokens. access tokens the client uses.
Proof-of-Possession Proof-of-Possession
The ACE framework, by default, implements proof-of-possession for The ACE framework, by default, implements proof-of-possession for
access tokens, i.e., that the token holder can prove being a access tokens, i.e., that the token holder can prove being a
holder of the key bound to the token. The binding is provided by holder of the key bound to the token. The binding is provided by
the "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession] indicating the "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession] indicating
what key is used for proof-of-possession. If a client needs to what key is used for proof-of-possession. If a client needs to
submit a new access token, e.g., to obtain additional access submit a new access token, e.g., to obtain additional access
rights, they can request that the AS binds this token to the same rights, they can request that the AS binds this token to the same
key as the previous one. key as the previous one.
skipping to change at page 41, line 10 skipping to change at page 41, line 10
introspection request as specified in Section 5.7. This requires introspection request as specified in Section 5.7. This requires
the RS to have a reliable network connection to the AS and to be the RS to have a reliable network connection to the AS and to be
able to handle two secure sessions in parallel (C to RS and RS to able to handle two secure sessions in parallel (C to RS and RS to
AS). AS).
o In order to support token expiration for devices that have no o In order to support token expiration for devices that have no
reliable way of synchronizing their internal clocks, this reliable way of synchronizing their internal clocks, this
specification defines the following approach: The claim "exi" specification defines the following approach: The claim "exi"
("expires in") can be used, to provide the RS with the lifetime of ("expires in") can be used, to provide the RS with the lifetime of
the token in seconds from the time the RS first receives the the token in seconds from the time the RS first receives the
token. This approach is of course vulnerable to malicious clients token. Processing this claim requires that the RS does the
holding back tokens they do not want to expire. Such an attack following:
can only be prevented if the RS is able to communicate with the AS
in some regular intervals, so that the can AS provide the RS with * For each token the RS receives, that contains an "exi" claim:
a list of expired tokens. The drawback of this mitigation is that Keep track of the time it received that token and revisit that
the RS might as well use the communication with the AS to list regularly to expunge expired tokens.
synchronize its internal clock.
* Keep track of the identifiers of tokens containing the "exi"
claim that have expired (in order to avoid accepting them
again).
If a token that authorizes a long running request such as a CoAP If a token that authorizes a long running request such as a CoAP
Observe [RFC7641] expires, the RS MUST send an error response with Observe [RFC7641] expires, the RS MUST send an error response with
the response code equivalent to the CoAP code 4.01 (Unauthorized) to the response code equivalent to the CoAP code 4.01 (Unauthorized) to
the client and then terminate processing the long running request. the client and then terminate processing the long running request.
5.8.4. Key Expiration 5.8.4. Key Expiration
The AS provides the client with key material that the RS uses. This The AS provides the client with key material that the RS uses. This
can either be a common symmetric PoP-key, or an asymmetric key used can either be a common symmetric PoP-key, or an asymmetric key used
skipping to change at page 44, line 30 skipping to change at page 44, line 37
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
trustworthy authorization servers. AS Request Creation Hints trustworthy authorization servers, possibly including information
referring to a URI not listed there would be ignored. used to authenticate the AS, such as a public key or certificate
fingerprint. AS Request Creation Hints referring to a URI not listed
there would be ignored.
A compromised RS may use the hints to trick a client into contacting A compromised RS may use the hints to trick a client into contacting
an AS that is not supposed to be in charge of that RS. Since this AS an AS that is not supposed to be in charge of that RS. Since this AS
must be in the hard-coded list of trusted AS no violation of must be in the hard-coded list of trusted AS no violation of
privileges and or exposure of redentials should happen. However a privileges and or exposure of credentials should happen, since a
trusted AS is expected to refuse requestes for which it is not
applicable and render a corresponding error response. However a
compromised RS may use this to perform a denial of service against a compromised RS may use this to perform a denial of service against a
specific AS, by redirecting a large number of client requests to that specific AS, by redirecting a large number of client requests to that
AS. AS.
A compromised client can be made to contact any AS, including A compromised client can be made to contact any AS, including
compromised ones. This should not affect the RS, since it is compromised ones. This should not affect the RS, since it is
supposed to keep track of which AS are trusted and have corresponding supposed to keep track of which AS are trusted and have corresponding
credentials to verify the source of access tokens it receives. credentials to verify the source of access tokens it receives.
6.5. Minimal security requirements for communication 6.5. Minimal security requirements for communication
skipping to change at page 46, line 20 skipping to change at page 46, line 26
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.
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: First a malicious client may hold back tokens need to be considered:
with the "exi" claim in order to prolong their lifespan, and second
if an RS loses state (e.g. due to an unscheduled reboot), it looses A malicious client may hold back tokens with the "exi" claim in
the current values of counters tracking the "exi" claims of tokens it order to prolong their lifespan.
is storing. The first drawback is inherent to the deployment
scenario and the "exi" solution. It can therefore not be mitigated If an RS loses state (e.g. due to an unscheduled reboot), it may
without requiring the the RS be online at times. The second drawback loose the current values of counters tracking the "exi" claims of
can be mitigated by regularly storing the value of "exi" Counters to tokens it is storing.
persistent memory.
The RS needs to keep state about expired tokens that used "exi" in
order to be sure not to accept it again. Attacker may use this to
deplete the RS's storage resources.
The first drawback is inherent to the deployment scenario and the
"exi" solution. It can therefore not be mitigated without requiring
the the RS be online at times. The second drawback can be mitigated
by regularly storing the value of "exi" counters to persistent
memory. The third problem can be mitigated by the AS, by assigning
identifiers (e.g. 'cti') to the tokens, that include a RS identifier
and a sequence number. The RS would then just have to store the
highest sequence number of an expired token it has seen, thus
limiting the necessary state.
6.7. Combining profiles 6.7. 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. 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.
skipping to change at page 47, line 19 skipping to change at page 47, line 42
authentication). In cases where this is not possible this framework authentication). In cases where this is not possible this framework
RECOMMENDS to use encrypted CWTs or tokens that are opaque references RECOMMENDS to use encrypted CWTs or tokens that are opaque references
and need to be subjected to introspection by the RS. and need to be subjected to introspection by the RS.
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
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
obsole profile that in turn specifies a vulnerable security mechanism
via the authz-info endpoint. Such an attack would require a valid
access token containing a "profile" claim requesting the use of said
obsolete profile. Resource Owners should update the 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.
URLs are not a good way of identifying mobile devices that can switch URLs are not a good way of identifying mobile devices that can switch
skipping to change at page 58, line 40 skipping to change at page 59, line 15
the context of the CelticNext project Critisec. 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-09 (work in progress), October 2019. possession-11 (work in progress), October 2019.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-05 (work in progress), March 2019. params-05 (work in progress), March 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.
skipping to change at page 59, line 44 skipping to change at page 60, line 20
[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>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
skipping to change at page 61, line 41 skipping to change at page 62, line 24
"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-v5.0.html>. mqtt-v5.0.html>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[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>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
 End of changes. 28 change blocks. 
83 lines changed or deleted 117 lines changed or added

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