rfc9202v3.txt   rfc9202.txt 
skipping to change at line 153 skipping to change at line 153
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in [RFC9200] and [RFC9201]. described in [RFC9200] and [RFC9201].
The authorization information (authz-info) resource refers to the The authorization information (authz-info) resource refers to the
authorization information endpoint, as specified in [RFC9200]. The authorization information endpoint, as specified in [RFC9200]. The
term claim is used in this document with the same semantics as in term claim is used in this document with the same semantics as in
[RFC9200], i.e., it denotes information carried in the access token [RFC9200], i.e., it denotes information carried in the access token
or returned from introspection. or returned from introspection.
Throughout this document, examples for CBOR data items are expressed
in CBOR extended diagnostic notation as defined in Section 8 of
[RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"), unless
noted otherwise. We often use diagnostic notation comments to
provide a textual representation of the numeric parameter names and
values.
2. Protocol Overview 2. Protocol Overview
The CoAP-DTLS profile for ACE specifies the transfer of The CoAP-DTLS profile for ACE specifies the transfer of
authentication information and, if necessary, authorization authentication information and, if necessary, authorization
information between the client (C) and the resource server (RS) information between the client (C) and the resource server (RS)
during setup of a DTLS session for CoAP messaging. It also specifies during setup of a DTLS session for CoAP messaging. It also specifies
how the client can use CoAP over DTLS to retrieve an access token how the client can use CoAP over DTLS to retrieve an access token
from the authorization server (AS) for a protected resource hosted on from the authorization server (AS) for a protected resource hosted on
the resource server. As specified in Section 6.7 of [RFC9200], use the resource server. As specified in Section 6.7 of [RFC9200], use
of DTLS for one or both of these interactions is completely of DTLS for one or both of these interactions is completely
skipping to change at line 310 skipping to change at line 317
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 / 33 : / client_credentials / 2, / grant_type / 33 : / client_credentials / 2,
/ audience / 5 : "tempSensor4711", / audience / 5 : "tempSensor4711",
/ req_cnf / 4 : { / req_cnf / 4 : {
/ COSE_Key / 1 : { / COSE_Key / 1 : {
/ kty / 1 : / EC2 / 2, / kty / 1 : / EC2 / 2,
/ crv / -1 : / P-256 / 1, / crv / -1 : / P-256 / 1,
/ x / -2 : h'e866c35f4c3c81bb96a1...', / x / -2 : h'e866c35f4c3c81bb96a1/.../',
/ y / -3 : h'2e25556be097c8778a20...' / y / -3 : h'2e25556be097c8778a20/.../'
} }
} }
} }
Figure 3: Access Token Request Example for RPK Mode Figure 3: Access Token Request Example for RPK Mode
The example shows an access token request for the resource identified The example shows an access token request for the resource identified
by the string "tempSensor4711" on the authorization server using a by the string "tempSensor4711" on the authorization server using a
raw public key. raw public key.
skipping to change at line 367 skipping to change at line 374
process the Max-Age option in the CoAP response, which has a default process the Max-Age option in the CoAP response, which has a default
value of 60 seconds (Section 5.6.1 of [RFC7252]). The authorization value of 60 seconds (Section 5.6.1 of [RFC7252]). The authorization
server SHOULD adjust the Max-Age option such that it does not exceed server SHOULD adjust the Max-Age option such that it does not exceed
the expires_in parameter to avoid stale responses. 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 / 1 : b64'SlAV32hkKG... / access_token / 1 : b64'SlAV32hk'/...
(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 / 2 : 3600, / expires_in / 2 : 3600,
/ rs_cnf / 41 : { / rs_cnf / 41 : {
/ COSE_Key / 1 : { / COSE_Key / 1 : {
/ kty / 1 : / EC2 / 2, / kty / 1 : / EC2 / 2,
/ crv / -1 : / P-256 / 1, / crv / -1 : / P-256 / 1,
/ x / -2 : h'd7cc072de2205bdc1537...', / x / -2 : h'd7cc072de2205bdc1537/.../',
/ y / -3 : h'f95e1d4b851a2cc80fff...' / y / -3 : h'f95e1d4b851a2cc80fff/.../'
} }
} }
} }
Figure 4: Access Token Response Example for RPK Mode Figure 4: Access Token Response Example for RPK Mode
3.2.2. DTLS Channel Setup between the Client and Resource Server 3.2.2. DTLS Channel Setup between the 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
skipping to change at line 515 skipping to change at line 522
response containing a new access token (truncated to improve response containing a new access token (truncated to improve
readability) and information for the client, including the symmetric readability) and information for the client, including the symmetric
key in the cnf claim. The information is transferred as a CBOR data key in the cnf claim. The information is transferred as a CBOR data
structure as specified in [RFC9200]. structure as specified in [RFC9200].
2.01 Created 2.01 Created
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Max-Age: 85800 Max-Age: 85800
Payload: Payload:
{ {
/ access_token / 1 : h'd08343a10... / access_token / 1 : h'd08343a1/...
(remainder of CWT omitted for brevity) (remainder of CWT omitted for brevity)/',
/ token_type / 34 : / PoP / 2, / token_type / 34 : / PoP / 2,
/ expires_in / 2 : 86400, / expires_in / 2 : 86400,
/ ace_profile / 38 : / coap_dtls / 1, / ace_profile / 38 : / coap_dtls / 1,
/ cnf / 8 : { / cnf / 8 : {
/ COSE_Key / 1 : { / COSE_Key / 1 : {
/ kty / 1 : / symmetric / 4, / kty / 1 : / symmetric / 4,
/ kid / 2 : h'3d027833fc6267ce', / kid / 2 : h'3d027833fc6267ce',
/ k / -1 : h'73657373696f6e6b6579' / k / -1 : h'73657373696f6e6b6579'
} }
} }
skipping to change at line 748 skipping to change at line 755
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 cnf claim the psk_identity field. If key derivation is used, the cnf claim
MUST contain a kid parameter to be used by the server as the IKM for MUST contain a kid parameter to be used by the server as the IKM for
key derivation, as described above. key derivation, as described above.
3.4. Resource Access 3.4. Resource Access
Once a DTLS channel has been established, as described in Sections Once a DTLS channel has been established as described in either
3.2 and 3.3, respectively, the client is authorized to access Sections 3.2 or 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 that is hosted by the resource server. info resource that is 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.10.1 of [RFC9200], there should be only one access token Section 5.10.1 of [RFC9200], there should be only one access token
for each client. New access tokens issued by the authorization for each client. New access tokens issued by the authorization
server SHOULD replace previously issued access tokens for the server SHOULD replace previously issued access tokens for the
skipping to change at line 964 skipping to change at line 971
suite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported. The suite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported. The
access tokens and the corresponding shared secrets generated by the access tokens and the corresponding shared secrets generated by the
authorization server are expected to be sufficiently short-lived to authorization server are expected to be sufficiently short-lived to
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 cipher suites should be used, i.e., cipher suites of the tokens, DHE cipher suites should be used, i.e., cipher suites of the
form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*. form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*.
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 to Denial of Service (DoS) attacks, as the handshake protocol
requires creation of an internal state within the device. This is requires creation of internal state within the device. This is
specifically of concern where an adversary is able to intercept the specifically of concern where an adversary is able to intercept the
initial cookie exchange and interject forged messages with a valid initial cookie exchange and interject forged messages with a valid
cookie to continue with the handshake. A similar issue exists with cookie to continue with the handshake. A similar issue exists with
the unprotected authorization information endpoint when the resource the unprotected authorization information endpoint when the resource
server needs to keep valid access tokens for a long time. server needs to keep valid access tokens for a long time.
Adversaries could 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 intercepted or otherwise retrieved storage for a very long time with intercepted or otherwise retrieved
valid access tokens. To mitigate against this, the resource server valid access tokens. To mitigate against this, the resource server
should set a time boundary until an access token that has not been should set a time boundary until an access token that has not been
used until then will be deleted. used until then will be deleted.
 End of changes. 8 change blocks. 
11 lines changed or deleted 18 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/