draft-ietf-ace-dtls-authorize-12.txt   draft-ietf-ace-dtls-authorize-13.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: January 7, 2021 Universitaet Bremen TZI Expires: March 12, 2021 Universitaet Bremen TZI
G. Selander G. Selander
Ericsson AB Ericsson AB
L. Seitz L. Seitz
Combitech Combitech
July 06, 2020 September 08, 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-12 draft-ietf-ace-dtls-authorize-13
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 January 7, 2021. This Internet-Draft will expire on March 12, 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 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . 7
3.2.1. DTLS Channel Setup Between Client and Resource Server 9 3.2.1. Access Token Retrieval from the Authorization Server 7
3.2.2. 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. Access Token Retrieval from the Authorization Server 10
3.3.2. 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 . . . . . . . . . 18
5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 20
7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21 7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21
7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 21 7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 22
7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22 7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
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
server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to
communicate. The client obtains an access token, bound to a key (the communicate. The client obtains an access token, bound to a key (the
proof-of-possession key), from an authorization server to prove its proof-of-possession key), from an authorization server to prove its
skipping to change at page 5, line 21 skipping to change at page 5, line 23
used by the client to establish a new DTLS session with the resource used by the client to establish a new DTLS session with the resource
server. When the client intends to use an asymmetric proof-of- server. When the client intends to use an asymmetric proof-of-
possession key in the DTLS handshake with the resource server, the possession key in the DTLS handshake with the resource server, the
client MUST upload the access token to the authz-info resource, i.e. client MUST upload the access token to the authz-info resource, i.e.
the authz-info endpoint, on the resource server before starting the the authz-info endpoint, on the resource server before starting the
DTLS handshake, as described in Section 5.8.1 of DTLS handshake, as described in Section 5.8.1 of
[I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric
proof-of-possession key in the DTLS handshake, the procedure as above proof-of-possession key in the DTLS handshake, the procedure as above
MAY be used, or alternatively, the access token MAY instead be MAY be used, or alternatively, the access token MAY instead be
transferred in the DTLS ClientKeyExchange message (see transferred in the DTLS ClientKeyExchange message (see
Section 3.3.1). In any case, DTLS MUST be used in a mode that Section 3.3.2). In any case, DTLS MUST be used in a mode that
provides replay protection. provides replay protection.
Figure 2 depicts the common protocol flow for the DTLS profile after Figure 2 depicts the common protocol flow for the DTLS profile after
the client has retrieved the access token from the authorization the client has retrieved the access token from the authorization
server, AS. server, AS.
C RS AS C RS AS
| [--- Access Token ------>] | | | [--- Access Token ------>] | |
| | | | | |
| <== DTLS channel setup ==> | | | <== DTLS channel setup ==> | |
skipping to change at page 6, line 48 skipping to change at page 7, line 7
association between the client and the authorization server is association between the client and the authorization server is
bootstrapped is not part of this document. The client and the bootstrapped is not part of this document. The client and the
authorization server must ensure the confidentiality, integrity and authorization server must ensure the confidentiality, integrity and
authenticity of all exchanged messages within the ACE protocol. authenticity of all exchanged messages within the ACE protocol.
Section 6 specifies how communication with the authorization server Section 6 specifies how communication with the authorization server
is secured. is secured.
3.2. RawPublicKey Mode 3.2. RawPublicKey Mode
When the client and the resource server use RawPublicKey When the client uses RawPublicKey authentication, the procedure is as
authentication, the procedure is as follows: After the client and the described in the following.
authorization server mutually authenticated each other and validated
each other's authorization, the client sends a token request to the 3.2.1. Access Token Retrieval from the Authorization Server
authorization server's token endpoint. The client MUST add a
"req_cnf" object carrying either its raw public key or a unique After the client and the authorization server mutually authenticated
identifier for a public key that it has previously made known to the each other and validated each other's authorization, the client sends
authorization server. It is RECOMMENDED that the client uses DTLS a token request to the authorization server's token endpoint. The
with the same keying material to secure the communication with the client MUST add a "req_cnf" object carrying either its raw public key
authorization server, proving possession of the key as part of the or a unique identifier for a public key that it has previously made
token request. Other mechanisms for proving possession of the key known to the authorization server. It is RECOMMENDED that the client
may be defined in the future. uses DTLS with the same keying material to secure the communication
with the authorization server, proving possession of the key as part
of the token request. Other mechanisms for proving possession of the
key may be defined in the future.
An example access token request from the client to the authorization An example access token request from the client to the authorization
server is depicted in Figure 3. server is depicted in Figure 3.
POST coaps://as.example.com/token POST coaps://as.example.com/token
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
grant_type : client_credentials, grant_type : client_credentials,
req_aud : "tempSensor4711", req_aud : "tempSensor4711",
skipping to change at page 9, line 5 skipping to change at page 9, line 26
kty : EC2, kty : EC2,
crv : P-256, crv : P-256,
x : h'd7cc072de2205bdc1537...', x : h'd7cc072de2205bdc1537...',
y : h'f95e1d4b851a2cc80fff...' y : h'f95e1d4b851a2cc80fff...'
} }
} }
} }
Figure 4: Access Token Response Example for RPK Mode Figure 4: Access Token Response Example for RPK Mode
3.2.1. DTLS Channel Setup Between Client and Resource Server 3.2.2. DTLS Channel Setup Between Client and Resource Server
Before the client initiates the DTLS handshake with the resource Before the client initiates the DTLS handshake with the resource
server, the client MUST send a "POST" request containing the obtained server, the client MUST send a "POST" request containing the obtained
access token to the authz-info resource hosted by the resource access token to the authz-info resource hosted by the resource
server. After the client receives a confirmation that the resource server. After the client receives a confirmation that the resource
server has accepted the access token, it SHOULD proceed to establish server has accepted the access token, it SHOULD proceed to establish
a new DTLS channel with the resource server. The client MUST use its a new DTLS channel with the resource server. The client MUST use its
correct public key in the DTLS handshake. If the authorization correct public key in the DTLS handshake. If the authorization
server has specified a "cnf" field in the access token response, the server has specified a "cnf" field in the access token response, the
client MUST use this key. Otherwise, the client MUST use the public client MUST use this key. Otherwise, the client MUST use the public
skipping to change at page 9, line 44 skipping to change at page 10, line 18
authorization server. The access token is constructed by the authorization server. The access token is constructed by the
authorization server such that the resource server can associate the authorization server such that the resource server can associate the
access token with the Client's public key. The "cnf" claim MUST access token with the Client's public key. The "cnf" claim MUST
contain either the client's RPK or, if the key is already known by contain either the client's RPK or, if the key is already known by
the resource server (e.g., from previous communication), a reference the resource server (e.g., from previous communication), a reference
to this key. If the authorization server has no certain knowledge to this key. If the authorization server has no certain knowledge
that the Client's key is already known to the resource server, the that the Client's key is already known to the resource server, the
Client's public key MUST be included in the access token's "cnf" Client's public key MUST be included in the access token's "cnf"
parameter. If CBOR web tokens [RFC8392] are used (as recommended in parameter. If CBOR web tokens [RFC8392] are used (as recommended in
[I-D.ietf-ace-oauth-authz]), keys MUST be encoded as specified in [I-D.ietf-ace-oauth-authz]), keys MUST be encoded as specified in
[RFC8747]. [RFC8747]. A resource server MUST have the capacity to store one
access token for every proof-of-possession key of every authorized
client.
The raw public key used in the DTLS handshake with the client MUST The raw public key used in the DTLS handshake with the client MUST
belong to the resource server. If the resource server has several belong to the resource server. If the resource server has several
raw public keys, it needs to determine which key to use. The raw public keys, it needs to determine which key to use. The
authorization server can help with this decision by including a "cnf" authorization server can help with this decision by including a "cnf"
parameter in the access token that is associated with this parameter in the access token that is associated with this
communication. In this case, the resource server MUST use the communication. In this case, the resource server MUST use the
information from the "cnf" field to select the proper keying information from the "cnf" field to select the proper keying
material. material.
Thus, the handshake only finishes if the client and the resource Thus, the handshake only finishes if the client and the resource
server are able to use their respective keying material. server are able to use their respective keying material.
3.3. PreSharedKey Mode 3.3. PreSharedKey Mode
When the client uses pre-shared key authentication, the procedure is
as described in the following.
3.3.1. Access Token Retrieval from the Authorization Server
To retrieve an access token for the resource that the client wants to To retrieve an access token for the resource that the client wants to
access, the client MAY include a "cnf" object carrying an identifier access, the client MAY include a "cnf" object carrying an identifier
for a symmetric key in its access token request to the authorization for a symmetric key in its access token request to the authorization
server. This identifier can be used by the authorization server to server. This identifier can be used by the authorization server to
determine the shared secret to construct the proof-of-possession determine the shared secret to construct the proof-of-possession
token. The authorization server MUST check if the identifier refers token. The authorization server MUST check if the identifier refers
to a symmetric key that was previously generated by the authorization to a symmetric key that was previously generated by the authorization
server as a shared secret for the communication between this client server as a shared secret for the communication between this client
and the resource server. If no such symmetric key was found, the and the resource server. If no such symmetric key was found, the
authorization server MUST generate a new symmetric key that is authorization server MUST generate a new symmetric key that is
skipping to change at page 13, line 9 skipping to change at page 13, line 43
identifier which MUST be unique among all key identifiers used by the identifier which MUST be unique among all key identifiers used by the
authorization server for this resource server. The authorization authorization server for this resource server. The authorization
server then uses the key derivation key shared with the resource server then uses the key derivation key shared with the resource
server to derive the symmetric key as specified below. Instead of server to derive the symmetric key as specified below. Instead of
providing the keying material in the access token, the authorization providing the keying material in the access token, the authorization
server includes the key identifier in the "kid" parameter, see server includes the key identifier in the "kid" parameter, see
Figure 7. This key identifier enables the resource server to Figure 7. This key identifier enables the resource server to
calculate the symmetric key used for the communication with the calculate the symmetric key used for the communication with the
client using the key derivation key and a KDF to be defined by the client using the key derivation key and a KDF to be defined by the
application, for example HKDF-SHA-256. The key identifier picked by application, for example HKDF-SHA-256. The key identifier picked by
the authorization server needs to be unique for each access token the authorization server MUST be unique for each access token where a
where a unique symmetric key is required. unique symmetric key is required.
In this example, HKDF consists of the composition of the HKDF-Extract In this example, HKDF consists of the composition of the HKDF-Extract
and HKDF-Expand steps [RFC5869]. The symmetric key is derived from and HKDF-Expand steps [RFC5869]. The symmetric key is derived from
the key identifier, the key derivation key and other data: the key identifier, the key derivation key and other data:
OKM = HKDF(salt, IKM, info, L), OKM = HKDF(salt, IKM, info, L),
where: where:
o OKM, the output keying material, is the derived symmetric key o OKM, the output keying material, is the derived symmetric key
skipping to change at page 14, line 6 skipping to change at page 14, line 39
transferred from the authorization server to the resource server. transferred from the authorization server to the resource server.
All CBOR data types are encoded in CBOR using preferred serialization All CBOR data types are encoded in CBOR using preferred serialization
and deterministic encoding as specified in Section 4 of and deterministic encoding as specified in Section 4 of
[I-D.ietf-cbor-7049bis]. This implies in particular that the "type" [I-D.ietf-cbor-7049bis]. This implies in particular that the "type"
and "L" components use the minimum length encoding. The content of and "L" components use the minimum length encoding. The content of
the "access_token" field is treated as opaque data for the purpose of the "access_token" field is treated as opaque data for the purpose of
key derivation. 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 MUST be 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.2. DTLS Channel Setup Between Client and Resource Server
When a client receives an access token response from an authorization When a client receives an access token response from an authorization
server, the client MUST check if the access token response is bound server, the client MUST check if the access token response is bound
to a certain previously sent access token request, as the request may to a 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.
The client checks if the payload of the access token response The client checks if the payload of the access token response
contains an "access_token" parameter and a "cnf" parameter. With contains an "access_token" parameter and a "cnf" parameter. With
this information the client can initiate the establishment of a new this information the client can initiate the establishment of a new
skipping to change at page 15, line 45 skipping to change at page 16, line 22
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
token was issued by an authorized authorization server. This token was issued by an authorized authorization server. This
specification assumes that the access token is a PoP token as specification implements access tokens as proof-of-possession tokens.
described in [I-D.ietf-ace-oauth-authz] unless specifically stated Therefore, the access token is bound to a symmetric PoP key that is
otherwise. Therefore, the access token is bound to a symmetric PoP used as shared secret between the client and the resource server. A
key that is used as shared secret between the client and the resource resource server MUST have the capacity to store one access token for
server. The resource server may use token introspection [RFC7662] on every proof-of-possession key of every authorized client. The
the access token to retrieve more information about the specific resource server may use token introspection [RFC7662] on the access
token. The use of introspection is out of scope for this token to retrieve more information about the specific token. The use
specification. of introspection is out of scope for this specification.
While the client can retrieve the shared secret from the contents of While the client can retrieve the shared secret from the contents of
the "cnf" parameter in the AS-to-Client response, the resource server the "cnf" parameter in the AS-to-Client response, the resource server
uses the information contained in the "cnf" claim of the access token uses the information contained in the "cnf" claim of the access token
to determine the actual secret when no explicit "kid" was provided in to determine the actual secret when no explicit "kid" was provided in
the "psk_identity" field. If key derivation is used, the resource the "psk_identity" field. If key derivation is used, the resource
server uses the "COSE_KDF_Context" information as described above. server uses the "COSE_KDF_Context" information as described above.
3.4. Resource Access 3.4. Resource Access
skipping to change at page 16, line 25 skipping to change at page 16, line 51
or Section 3.3, respectively, the client is authorized to access or Section 3.3, respectively, the client is authorized to access
resources covered by the access token it has uploaded to the authz- resources covered by the access token it has uploaded to the authz-
info resource hosted by the resource server. info resource hosted by the resource server.
With the successful establishment of the DTLS channel, the client and With the successful establishment of the DTLS channel, the client and
the resource server have proven that they can use their respective the resource server have proven that they can use their respective
keying material. An access token that is bound to the client's keying material. An access token that is bound to the client's
keying material is associated with the channel. According to keying material is associated with the channel. According to
Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
access token for each client. New access tokens issued by the access token for each client. New access tokens issued by the
authorization server are supposed to replace previously issued access authorization server replace previously issued access tokens for the
tokens for the respective client. The resource server therefore must respective client. The resource server therefore must have a common
have a common understanding with the authorization server how access understanding with the authorization server how access tokens are
tokens are ordered. ordered. The authorization server may, e.g., specify a "cti" claim
for the access token (see Section 5.8.3 of
[I-D.ietf-ace-oauth-authz]) to employ a strict order.
Any request that the resource server receives on a DTLS channel that Any request that the resource server receives on a DTLS channel that
is tied to an access token via its keying material MUST be checked is tied to an access token via its keying material MUST be checked
against the authorization rules that can be determined with the against the authorization rules that can be determined with the
access token. The resource server MUST check for every request if access token. The resource server MUST check for every request if
the access token is still valid. If the token has expired, the the access token is still valid. If the token has expired, the
resource server MUST remove it. Incoming CoAP requests that are not resource server MUST remove it. Incoming CoAP requests that are not
authorized with respect to any access token that is associated with authorized with respect to any access token that is associated with
the client MUST be rejected by the resource server with 4.01 the client MUST be rejected by the resource server with 4.01
response. The response SHOULD include AS Request Creation Hints as response. The response SHOULD include AS Request Creation Hints as
skipping to change at page 20, line 43 skipping to change at page 21, line 22
provide similar forward-secrecy properties to using ephemeral Diffie- provide similar forward-secrecy properties to using ephemeral Diffie-
Hellman (DHE) key exchange mechanisms. For longer-lived access Hellman (DHE) key exchange mechanisms. For longer-lived access
tokens, DHE ciphersuites should be used. tokens, DHE ciphersuites should be used.
Constrained devices that use DTLS [RFC6347] are inherently vulnerable Constrained devices that use DTLS [RFC6347] are inherently vulnerable
to Denial of Service (DoS) attacks as the handshake protocol requires to Denial of Service (DoS) attacks as the handshake protocol requires
creation of internal state within the device. This is specifically creation of internal state within the device. This is specifically
of concern where an adversary is able to intercept the initial cookie of concern where an adversary is able to intercept the initial cookie
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 when the resource
server needs to keep valid access tokens until their expiry. server needs to keep valid access tokens for a long time.
Adversaries can fill up the constrained resource server's internal Adversaries could 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. To mitigate against this, the resource server
in the authorization information endpoint depends on the keying should set a time boundary until an access token that has not been
material that is used between the authorization server and the used until then will be deleted.
resource server: The resource server must ensure that it processes
only access tokens that are (encrypted and) integrity-protected by an The protection of access tokens that are stored in the authorization
authorization server that is authorized to provide access tokens for information endpoint depends on the keying material that is used
the resource server. between the authorization server and the resource server: The
resource server must ensure that it processes only access tokens that
are (encrypted and) integrity-protected by an authorization server
that is authorized to provide access tokens for 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
 End of changes. 23 change blocks. 
55 lines changed or deleted 72 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/