draft-ietf-ace-dtls-authorize-11.txt   draft-ietf-ace-dtls-authorize-12.txt 
ACE Working Group S. Gerdes ACE Working Group S. Gerdes
Internet-Draft O. Bergmann Internet-Draft O. Bergmann
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: December 20, 2020 Universitaet Bremen TZI Expires: January 7, 2021 Universitaet Bremen TZI
G. Selander G. Selander
Ericsson AB Ericsson AB
L. Seitz L. Seitz
Combitech Combitech
June 18, 2020 July 06, 2020
Datagram Transport Layer Security (DTLS) Profile for Authentication and Datagram Transport Layer Security (DTLS) Profile for Authentication and
Authorization for Constrained Environments (ACE) Authorization for Constrained Environments (ACE)
draft-ietf-ace-dtls-authorize-11 draft-ietf-ace-dtls-authorize-12
Abstract Abstract
This specification defines a profile of the ACE framework that allows This specification defines a profile of the ACE framework that allows
constrained servers to delegate client authentication and constrained servers to delegate client authentication and
authorization. The protocol relies on DTLS version 1.2 for authorization. The protocol relies on DTLS version 1.2 for
communication security between entities in a constrained network communication security between entities in a constrained network
using either raw public keys or pre-shared keys. A resource- using either raw public keys or pre-shared keys. A resource-
constrained server can use this protocol to delegate management of constrained server can use this protocol to delegate management of
authorization information to a trusted host with less severe authorization information to a trusted host with less severe
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 December 20, 2020. This Internet-Draft will expire on January 7, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Communication Between the Client and the Authorization 3.1. Communication Between the Client and the Authorization
Server . . . . . . . . . . . . . . . . . . . . . . . . . 6 Server . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6 3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6
3.2.1. DTLS Channel Setup Between Client and Resource Server 9 3.2.1. DTLS Channel Setup Between Client and Resource Server 9
3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10 3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10
3.3.1. DTLS Channel Setup Between Client and Resource Server 14 3.3.1. DTLS Channel Setup Between Client and Resource Server 14
3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16
4. Dynamic Update of Authorization Information . . . . . . . . . 17 4. Dynamic Update of Authorization Information . . . . . . . . . 17
5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 18 5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19
6. Secure Communication with an Authorization Server . . . . . . 19 6. Secure Communication with an Authorization Server . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 20 7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21
7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 21 7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 21
7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 21 7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This specification defines a profile of the ACE framework This specification defines a profile of the ACE framework
[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
skipping to change at page 8, line 20 skipping to change at page 8, line 20
server MUST protect the integrity of the access token such that the server MUST protect the integrity of the access token such that the
resource server can detect unauthorized changes. If the access token resource server can detect unauthorized changes. If the access token
contains confidential data, the authorization server MUST also contains confidential data, the authorization server MUST also
protect the confidentiality of the access token. protect the confidentiality of the access token.
The client MUST ascertain that the access token response belongs to a The client MUST ascertain that the access token response belongs to a
certain previously sent access token request, as the request may certain previously sent access token request, as the request may
specify the resource server with which the client wants to specify the resource server with which the client wants to
communicate. communicate.
An example access token response from the authorization to the client An example access token response from the authorization server to the
is depicted in Figure 4. Here, the contents of the "access_token" client is depicted in Figure 4. Here, the contents of the
claim have been truncated to improve readability. Caching proxies "access_token" claim have been truncated to improve readability.
process the Max-Age option in the CoAP response which has a default Caching proxies process the Max-Age option in the CoAP response which
value of 60 seconds (Section 5.6.1 of [RFC7252]). The authorization has a default value of 60 seconds (Section 5.6.1 of [RFC7252]). The
server SHOULD adjust the Max-Age option such that it does not exceed authorization server SHOULD adjust the Max-Age option such that it
the "expires_in" parameter to avoid stale responses. does not exceed the "expires_in" parameter to avoid stale responses.
2.01 Created 2.01 Created
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Max-Age: 3560 Max-Age: 3560
Payload: Payload:
{ {
access_token : b64'SlAV32hkKG... access_token : b64'SlAV32hkKG...
(remainder of CWT omitted for brevity; (remainder of CWT omitted for brevity;
CWT contains the client's RPK in the cnf claim)', CWT contains the client's RPK in the cnf claim)',
expires_in : 3600, expires_in : 3600,
skipping to change at page 13, line 33 skipping to change at page 13, line 33
o IKM, the input keying material, is the key derivation key as o IKM, the input keying material, is the key derivation key as
defined above defined above
o info is the serialization of a CBOR array consisting of o info is the serialization of a CBOR array consisting of
([RFC8610]): ([RFC8610]):
info = [ info = [
type : tstr, type : tstr,
L : uint, L : uint,
access_token: map access_token: bytes
] ]
where: where:
o type is set to the constant text string "ACE-CoAP-DTLS-key- o type is set to the constant text string "ACE-CoAP-DTLS-key-
derivation", derivation",
o L is the size of the symmetric key in bytes, o L is the size of the symmetric key in bytes,
o access_token is the decrypted access_token as transferred from the o access_token is the content of the "access_token" field as
authorization server to the resource server. The decrypted access transferred from the authorization server to the resource server.
token usually denotes a CWT claim set represented as CBOR map.
All CBOR data types are encoded in CBOR using preferred serialization
and deterministic encoding as specified in Section 4 of
[I-D.ietf-cbor-7049bis]. This implies in particular that the "type"
and "L" components use the minimum length encoding. The content of
the "access_token" field is treated as opaque data for the purpose of
key derivation.
Use of a unique (per resource server) "kid" and the use of a key Use of a unique (per resource server) "kid" and the use of a key
derivation IKM that is unique per authorization server/resource derivation IKM that is unique per authorization server/resource
server pair as specified above will ensure that the derived key is server pair as specified above will ensure that the derived key is
not shared across multiple clients. However, to additionally provide not shared across multiple clients. However, to additionally provide
variation in the derived key across different tokens used by the same variation in the derived key across different tokens used by the same
client, it is additionally RECOMMENDED to include the "iat" claim and client, it is additionally RECOMMENDED to include the "iat" claim and
either the "exp" or "exi" claims in the access token. either the "exp" or "exi" claims in the access token.
3.3.1. DTLS Channel Setup Between Client and Resource Server 3.3.1. DTLS Channel Setup Between Client and Resource Server
skipping to change at page 15, line 17 skipping to change at page 15, line 30
perform any re-coding. This allows the resource server to retrieve perform any re-coding. This allows the resource server to retrieve
the shared secret directly from the "cnf" claim of the access token. the shared secret directly from the "cnf" claim of the access token.
If a resource server receives a ClientKeyExchange message that If a resource server receives a ClientKeyExchange message that
contains a "psk_identity" with a length greater than zero, it MUST contains a "psk_identity" with a length greater than zero, it MUST
parse the contents of the "psk_identity" field as CBOR data structure parse the contents of the "psk_identity" field as CBOR data structure
and process the contents as following: and process the contents as following:
o If the data contains a "cnf" field with a "COSE_Key" structure o If the data contains a "cnf" field with a "COSE_Key" structure
with a "kid", the resource server continues the DTLS handshake with a "kid", the resource server continues the DTLS handshake
with the stored key associated with this kid. with the associated key that corresponds to this kid.
o If the data comprises additional CWT information, this information o If the data comprises additional CWT information, this information
must be stored as access token for this DTLS association before must be stored as an access token for this DTLS association before
continuing with the DTLS handshake. continuing with the DTLS handshake.
If the contents of the "psk_identity" do not yield sufficient If the contents of the "psk_identity" do not yield sufficient
information to select a valid access token for the requesting client, information to select a valid access token for the requesting client,
the resource server aborts the DTLS handshake with an the resource server aborts the DTLS handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
When the resource server receives an access token, it MUST check if When the resource server receives an access token, it MUST check if
the access token is still valid, if the resource server is the the access token is still valid, if the resource server is the
intended destination (i.e., the audience of the token), and if the intended destination (i.e., the audience of the token), and if the
skipping to change at page 20, line 43 skipping to change at page 20, line 51
exchange and interject forged messages with a valid cookie to exchange and interject forged messages with a valid cookie to
continue with the handshake. A similar issue exists with the continue with the handshake. A similar issue exists with the
unprotected authorization information endpoint where the resource unprotected authorization information endpoint where the resource
server needs to keep valid access tokens until their expiry. server needs to keep valid access tokens until their expiry.
Adversaries can fill up the constrained resource server's internal Adversaries can fill up the constrained resource server's internal
storage for a very long time with interjected or otherwise retrieved storage for a very long time with interjected or otherwise retrieved
valid access tokens. The protection of access tokens that are stored valid access tokens. The protection of access tokens that are stored
in the authorization information endpoint depends on the keying in the authorization information endpoint depends on the keying
material that is used between the authorization server and the material that is used between the authorization server and the
resource server: The resource server must ensure that it processes resource server: The resource server must ensure that it processes
only access tokens that are encrypted and integrity-protected by an only access tokens that are (encrypted and) integrity-protected by an
authorization server that is authorized to provide access tokens for authorization server that is authorized to provide access tokens for
the resource server. the resource server.
7.1. Reuse of Existing Sessions 7.1. Reuse of Existing Sessions
To avoid the overhead of a repeated DTLS handshake, [RFC7925] To avoid the overhead of a repeated DTLS handshake, [RFC7925]
recommends session resumption [RFC5077] to reuse session state from recommends session resumption [RFC5077] to reuse session state from
an earlier DTLS association and thus requires client side an earlier DTLS association and thus requires client side
implementation. In this specification, the DTLS session is subject implementation. In this specification, the DTLS session is subject
to the authorization rules denoted by the access token that was used to the authorization rules denoted by the access token that was used
for the initial setup of the DTLS association. Enabling session for the initial setup of the DTLS association. Enabling session
resumption would require the server to transfer the authorization resumption would require the server to transfer the authorization
information with the session state in an encrypted SessionTicket to information with the session state in an encrypted SessionTicket to
the client. Assuming that the server uses long-lived keying the client. Assuming that the server uses long-lived keying
material, this could open up attacks due to the lack of forward material, this could open up attacks due to the lack of forward
secrecy. Moreover, using this mechanism, a client can resume a DTLS secrecy. Moreover, using this mechanism, a client can resume a DTLS
session without proving the possession of the PoP key again. session without proving the possession of the PoP key again.
Therefore, the use of session resumption is NOT RECOMMENDED for Therefore, the use of session resumption is NOT RECOMMENDED for
resource servers. resource servers.
Since renogiation of DTLS associations is prone to attacks as well, Since renegotiation of DTLS associations is prone to attacks as well,
[RFC7925] requires clients to decline any renogiation attempt. A [RFC7925] requires clients to decline any renogiation attempt. A
server that wants to initiate re-keying therefore SHOULD periodically server that wants to initiate re-keying therefore SHOULD periodically
force a full handshake. force a full handshake.
7.2. Multiple Access Tokens 7.2. Multiple Access Tokens
The use of multiple access tokens for a single client increases the The use of multiple access tokens for a single client increases the
strain on the resource server as it must consider every access token strain on the resource server as it must consider every access token
and calculate the actual permissions of the client. Also, tokens may and calculate the actual permissions of the client. Also, tokens may
contradict each other which may lead the server to enforce wrong contradict each other which may lead the server to enforce wrong
skipping to change at page 23, line 18 skipping to change at page 23, line 30
Profile ID: TBD (suggested: 1) Profile ID: TBD (suggested: 1)
Change Controller: IESG Change Controller: IESG
Reference: [RFC-XXXX] Reference: [RFC-XXXX]
10. Acknowledgments 10. Acknowledgments
Thanks to Jim Schaad for his contributions and reviews of this Thanks to Jim Schaad for his contributions and reviews of this
document. Special thanks to Ben Kaduk for his thorough review of document. Special thanks to Ben Kaduk for his thorough reviews of
this document. this document.
Ludwig Seitz worked on this document as part of the CelticNext Ludwig Seitz worked on this document as part of the CelticNext
projects CyberWI, and CRITISEC with funding from Vinnova. projects CyberWI, and CRITISEC with funding from Vinnova.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35
(work in progress), February 2020. (work in progress), June 2020.
[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-13 (work in progress), April 2020. params-13 (work in progress), April 2020.
[I-D.ietf-cbor-7049bis]
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", draft-ietf-cbor-7049bis-14 (work
in progress), June 2020.
[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>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>. <https://www.rfc-editor.org/info/rfc4279>.
 End of changes. 18 change blocks. 
26 lines changed or deleted 37 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/