draft-ietf-ace-oauth-authz-39.txt   draft-ietf-ace-oauth-authz-40.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: October 18, 2021 Ericsson Expires: October 28, 2021 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
April 16, 2021 April 26, 2021
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-39 draft-ietf-ace-oauth-authz-40
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 the Constrained Application Protocol (CoAP), thus OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to where possible, but extensions are added and profiles are defined to
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 October 18, 2021. This Internet-Draft will expire on October 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 8 skipping to change at page 3, line 8
5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31 5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31
5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32 5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32
5.9.2. Introspection Response . . . . . . . . . . . . . . . 33 5.9.2. Introspection Response . . . . . . . . . . . . . . . 33
5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34 5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34
5.9.4. Mapping Introspection Parameters to CBOR . . . . . . 35 5.9.4. Mapping Introspection Parameters to CBOR . . . . . . 35
5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35 5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35
5.10.1. The Authorization Information Endpoint . . . . . . . 36 5.10.1. The Authorization Information Endpoint . . . . . . . 36
5.10.1.1. Verifying an Access Token . . . . . . . . . . . 37 5.10.1.1. Verifying an Access Token . . . . . . . . . . . 37
5.10.1.2. Protecting the Authorization Information 5.10.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 39 Endpoint . . . . . . . . . . . . . . . . . . . . 39
5.10.2. Client Requests to the RS . . . . . . . . . . . . . 39 5.10.2. Client Requests to the RS . . . . . . . . . . . . . 40
5.10.3. Token Expiration . . . . . . . . . . . . . . . . . . 40 5.10.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
5.10.4. Key Expiration . . . . . . . . . . . . . . . . . . . 42 5.10.4. Key Expiration . . . . . . . . . . . . . . . . . . . 42
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 43
6.2. Communication Security . . . . . . . . . . . . . . . . . 43 6.2. Communication Security . . . . . . . . . . . . . . . . . 44
6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44
6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 45 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 45
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 . . . . . . . . . . . . . . . . . . . 47 6.7. Combining Profiles . . . . . . . . . . . . . . . . . . . 47
6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
6.9. Identifying Audiences . . . . . . . . . . . . . . . . . . 48 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
skipping to change at page 25, line 51 skipping to change at page 25, line 51
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]. If use of a dynamic client registration protocol exchange [RFC7591]. If
the client has requested a specific proof-of-possession key using the the client has requested a specific proof-of-possession key using the
"req_cnf" parameter from [I-D.ietf-ace-oauth-params], this may also "req_cnf" parameter from [I-D.ietf-ace-oauth-params], this may also
influence which profile the AS selects, as it needs to support the influence which profile the AS selects, as it needs to support the
use of the key type requested the client. use of the key type requested the client.
The content of the successful reply is the Access Information. When The content of the successful reply is the Access Information. When
using CoAP, the payload MUST be encoded as a CBOR map, when using using CoAP, the payload MUST be encoded as a CBOR map, when using
HTTP the encoding is a JSON map as specified in seciton 5.1 of HTTP the encoding is a JSON map as specified in section 5.1 of
[RFC6749]. In both cases the parameters specified in Section 5.1 of [RFC6749]. In both cases the parameters specified in Section 5.1 of
[RFC6749] are used, with the following additions and changes: [RFC6749] are used, with the following additions and changes:
ace_profile: ace_profile:
OPTIONAL unless the request included an empty ace_profile OPTIONAL unless the request included an empty ace_profile
parameter in which case it is MANDATORY. This indicates the parameter in which case it is MANDATORY. This indicates the
profile that the client MUST use towards the RS. See profile that the client MUST use towards the RS. See
Section 5.8.4.3 for the formatting of this parameter. If this Section 5.8.4.3 for the formatting of this parameter. If this
parameter is absent, the AS assumes that the client implicitly parameter is absent, the AS assumes that the client implicitly
skipping to change at page 37, line 11 skipping to change at page 37, line 11
use. This is a difference to how access tokens are handled in OAuth use. This is a difference to how access tokens are handled in OAuth
2.0, where the access token is typically sent along with each 2.0, where the access token is typically sent along with each
request, and therefore not stored at the RS. request, and therefore not stored at the RS.
When using this framework it is RECOMMENDED that an RS stores only When using this framework it is RECOMMENDED that an RS stores only
one token per proof-of-possession key. This means that an additional one token per proof-of-possession key. This means that an additional
token linked to the same key will supersede any existing token at the token linked to the same key will supersede any existing token at the
RS, by replacing the corresponding authorization information. The RS, by replacing the corresponding authorization information. The
reason is that this greatly simplifies (constrained) implementations, reason is that this greatly simplifies (constrained) implementations,
with respect to required storage and resolving a request to the with respect to required storage and resolving a request to the
applicable token. applicable token. The use of multiple access tokens for a single
client increases the strain on the resource server as it must
consider every access token and calculate the actual permissions of
the client. Also, tokens may contradict each other which may lead
the server to enforce wrong permissions. If one of the access tokens
expires earlier than others, the resulting permissions may offer
insufficient protection.
If the payload sent to the authz-info endpoint does not parse to a If the payload sent to the authz-info endpoint does not parse to a
token, the RS MUST respond with a response code equivalent to the token, the RS MUST respond with a response code equivalent to the
CoAP code 4.00 (Bad Request). CoAP code 4.00 (Bad Request).
The RS MAY make an introspection request to validate the token before The RS MAY make an introspection request to validate the token before
responding to the POST request to the authz-info endpoint, e.g. if responding to the POST request to the authz-info endpoint, e.g. if
the token is an opaque reference. Some transport protocols may the token is an opaque reference. Some transport protocols may
provide a way to indicate that the RS is busy and the client should provide a way to indicate that the RS is busy and the client should
retry after an interval; this type of status update would be retry after an interval; this type of status update would be
skipping to change at page 44, line 19 skipping to change at page 44, line 27
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).
Care must by taken by developers to prevent leakage of the PoP Care must by taken by developers to prevent leakage of the PoP
credentials (i.e., the private key or the symmetric key). An credentials (i.e., the private key or the symmetric key). An
adversary in possession of the PoP credentials bound to the access adversary in possession of the PoP credentials bound to the access
token will be able to impersonate the client. Be aware that this is token will be able to impersonate the client. Be aware that this is
a real risk with many constrained environments, since adversaries may a real risk with many constrained environments, since adversaries may
get physical access to the devices and can therefore use phyical get physical access to the devices and can therefore use physical
extraction techniques to gain access to memory contents. This risk extraction techniques to gain access to memory contents. This risk
can be mitigated to some extent by making sure that keys are can be mitigated to some extent by making sure that keys are
refreshed frequently, by using software isolation techniques and by refreshed frequently, by using software isolation techniques and by
using hardware security. using hardware security.
6.3. Long-Term Credentials 6.3. Long-Term Credentials
Both clients and RSs have long-term credentials that are used to Both clients and RSs have long-term credentials that are used to
secure communications, and authenticate to the AS. These credentials secure communications, and authenticate to the AS. These credentials
need to be protected against unauthorized access. In constrained need to be protected against unauthorized access. In constrained
skipping to change at page 59, line 18 skipping to change at page 59, line 18
9. Acknowledgments 9. Acknowledgments
This document is a product of the ACE working group of the IETF. This document is a product of the ACE working group of the IETF.
Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and
UMA in IoT scenarios, Robert Taylor for his discussion input, and UMA in IoT scenarios, Robert Taylor for his discussion input, and
Malisa Vucinic for his input on the predecessors of this proposal. Malisa Vucinic for his input on the predecessors of this proposal.
Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from
where large parts of the security considerations where copied. where parts of the security considerations where copied.
Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for
contributing their work on AS discovery from draft-gerdes-ace-dcaf- contributing their work on AS discovery from draft-gerdes-ace-dcaf-
authorize (see Section 5.1). authorize (see Section 5.1) and the considerations on multiple access
tokens.
Thanks to Jim Schaad and Mike Jones for their comprehensive reviews. Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.
Thanks to Benjamin Kaduk for his input on various questions related Thanks to Benjamin Kaduk for his input on various questions related
to this work. to this work.
Thanks to Cigdem Sengul for some very useful review comments. Thanks to Cigdem Sengul for some very useful review comments.
Thanks to Carsten Bormann for contributing the text for the CoRE Thanks to Carsten Bormann for contributing the text for the CoRE
Resource Type registry. Resource Type registry.
skipping to change at page 59, line 49 skipping to change at page 59, line 50
Seitz was also received further funding for this work by Vinnova in Seitz was also received further funding for this work by Vinnova in
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-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-14 (work in progress), March 2021. params-13 (work in progress), April 2020.
[IANA.CborWebTokenClaims] [IANA.CborWebTokenClaims]
IANA, "CBOR Web Token (CWT) Claims", IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt/cwt.xhtml#claims- <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
registry>. registry>.
[IANA.CoreParameters] [IANA.CoreParameters]
IANA, "Constrained RESTful Environments (CoRE) IANA, "Constrained RESTful Environments (CoRE)
Parameters", <https://www.iana.org/assignments/core- Parameters", <https://www.iana.org/assignments/core-
parameters/core-parameters.xhtml>. parameters/core-parameters.xhtml>.
skipping to change at page 62, line 37 skipping to change at page 62, line 37
[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-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-16 (work in progress), March 2021. authorize-15 (work in progress), January 2021.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE Profile of the Authentication and Authorization "OSCORE Profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-18 (work in progress), April 2021. oscore-profile-15 (work in progress), January 2021.
[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-34 (work and Secure Transport", draft-ietf-quic-transport-34 (work
in progress), January 2021. in progress), January 2021.
[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-41 (work in progress), 1.3", draft-ietf-tls-dtls13-40 (work in progress), January
February 2021. 2021.
[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
 End of changes. 15 change blocks. 
17 lines changed or deleted 24 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/