draft-ietf-ace-dtls-authorize-10.txt   draft-ietf-ace-dtls-authorize-11.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: November 14, 2020 Universitaet Bremen TZI Expires: December 20, 2020 Universitaet Bremen TZI
G. Selander G. Selander
Ericsson AB Ericsson AB
L. Seitz L. Seitz
Combitech Combitech
May 13, 2020 June 18, 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-10 draft-ietf-ace-dtls-authorize-11
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 November 14, 2020. This Internet-Draft will expire on December 20, 2020.
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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . 18
6. Secure Communication with an Authorization Server . . . . . . 18 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 . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . 21
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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
authorization to access protected resources hosted by the resource authorization to access protected resources hosted by the resource
server. Also, the client and the resource server are provided by the server. Also, the client and the resource server are provided by the
skipping to change at page 6, line 43 skipping to change at page 6, line 43
by the resource owner (RO) concerning the client and the resource by the resource owner (RO) concerning the client and the resource
server that relate to this keying material. server that relate to this keying material.
The client and the authorization server MUST use their respective The client and the authorization server MUST use their respective
keying material for all exchanged messages. How the security keying material for all exchanged messages. How the security
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 Section 6 specifies how communication with the authorization Section 6 specifies how communication with the authorization server
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 and the resource server use RawPublicKey
authentication, the procedure is as follows: After the client and the authentication, the procedure is as follows: After the client and the
authorization server mutually authenticated each other and validated authorization server mutually authenticated each other and validated
each other's authorization, the client sends a token request to the each other's authorization, the client sends a token request to the
authorization server's token endpoint. The client MUST add a authorization server's token endpoint. The client MUST add a
"req_cnf" object carrying either its raw public key or a unique "req_cnf" object carrying either its raw public key or a unique
identifier for a public key that it has previously made known to the identifier for a public key that it has previously made known to the
skipping to change at page 9, line 42 skipping to change at page 9, line 42
the resource server is the intended destination (i.e., the audience) the resource server is the intended destination (i.e., the audience)
of the token, and if the token was issued by an authorized of the token, and if the token was issued by an authorized
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]. The resource server MUST use its own raw public key in [RFC8747].
the DTLS handshake with the client. If the resource server has
several raw public keys, it must already know which key it is
supposed to use with this client. How this is achieved is not part
of this profile.
The resource server MUST use the keying material that the The raw public key used in the DTLS handshake with the client MUST
authorizations server has specified in the "cnf" parameter in the belong to the resource server. If the resource server has several
access token for the DTLS handshake with the client. Thus, the raw public keys, it needs to determine which key to use. The
handshake only finishes if the client and the resource server are authorization server can help with this decision by including a "cnf"
able to use their respective keying material. parameter in the access token that is associated with this
communication. In this case, the resource server MUST use the
information from the "cnf" field to select the proper keying
material.
Thus, the handshake only finishes if the client and the resource
server are able to use their respective keying material.
3.3. PreSharedKey Mode 3.3. PreSharedKey Mode
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
skipping to change at page 10, line 40 skipping to change at page 10, line 43
detect unauthorized changes. If the token contains confidential data detect unauthorized changes. If the token contains confidential data
such as the symmetric key, the confidentiality of the token MUST also such as the symmetric key, the confidentiality of the token MUST also
be protected. Depending on the requested token type and algorithm in be protected. Depending on the requested token type and algorithm in
the access token request, the authorization server adds access the access token request, the authorization server adds access
Information to the response that provides the client with sufficient Information to the response that provides the client with sufficient
information to setup a DTLS channel with the resource server. The information to setup a DTLS channel with the resource server. The
authorization server adds a "cnf" parameter to the access information authorization server adds a "cnf" parameter to the access information
carrying a "COSE_Key" object that informs the client about the shared carrying a "COSE_Key" object that informs the client about the shared
secret that is to be used between the client and the resource server. secret that is to be used between the client and the resource server.
To convey the same secret to the resource server, the authorization To convey the same secret to the resource server, the authorization
server either includes it directly in the access token by means of server can include it directly in the access token by means of the
the "cnf" claim or it provides sufficient information to enable the "cnf" claim or provide sufficient information to enable the resource
resource server to derive the key from the access token using key server to derive the shared secret from the access token. As an
derivation. alternative, the resource server MAY use token introspection to
retrieve the keying material for this access token directly from the
authorization server.
An example access token request for an access token with a symmetric An example access token request for an access token with a symmetric
proof-of-possession key is illustrated in Figure 5. proof-of-possession key is illustrated in Figure 5.
POST coaps://as.example.com/token POST coaps://as.example.com/token
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
audience : "smokeSensor1807", audience : "smokeSensor1807",
} }
skipping to change at page 12, line 49 skipping to change at page 12, line 49
used to protect the communication between the authorization server used to protect the communication between the authorization server
and the resource server. and the resource server.
Knowledge of the symmetric key shared with the client must not reveal Knowledge of the symmetric key shared with the client must not reveal
any information about the key derivation key or other secret keys any information about the key derivation key or other secret keys
shared between the authorization server and resource server. shared between the authorization server and resource server.
In order to generate a new symmetric key to be used by client and In order to generate a new symmetric key to be used by client and
resource server, the authorization server generates a new key resource server, the authorization server generates a new key
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. The authorization server then uses the key authorization server for this resource server. The authorization
derivation key shared with the resource server to derive the server then uses the key derivation key shared with the resource
symmetric key as specified below. Instead of providing the keying server to derive the symmetric key as specified below. Instead of
material in the access token, the authorization server includes the providing the keying material in the access token, the authorization
key identifier in the "kid" parameter, see Figure 7. This key server includes the key identifier in the "kid" parameter, see
identifier enables the resource server to calculate the symmetric key Figure 7. This key identifier enables the resource server to
used for the communication with the client using the key derivation calculate the symmetric key used for the communication with the
key and a KDF to be defined by the application, for example HKDF-SHA- client using the key derivation key and a KDF to be defined by the
256. The key identifier picked by the authorization server needs to application, for example HKDF-SHA-256. The key identifier picked by
be unique for each access token where a unique symmetric key is the authorization server needs to be unique for each access token
required. where a 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 13, line 44 skipping to change at page 13, line 44
] ]
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 decrypted access_token as transferred from the
authorization server to the resource server. authorization server to the resource server. The decrypted access
token usually denotes a CWT claim set represented as CBOR map.
To ensure uniqueness of the derived shared secret, the authorization Use of a unique (per resource server) "kid" and the use of a key
server SHOULD generate a sufficiently random kid value and include derivation IKM that is unique per authorization server/resource
the claims "iat" and either "exp" or "exi" in the access token. server pair as specified above will ensure that the derived key is
not shared across multiple clients. However, to additionally provide
variation in the derived key across different tokens used by the same
client, it is additionally RECOMMENDED to include the "iat" claim and
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
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
skipping to change at page 15, line 9 skipping to change at page 15, line 12
As an alternative to the access token upload, the client can provide As an alternative to the access token upload, the client can provide
the most recent access token in the "psk_identity" field of the the most recent access token in the "psk_identity" field of the
ClientKeyExchange message. To do so, the client MUST treat the ClientKeyExchange message. To do so, the client MUST treat the
contents of the "access_token" field from the AS-to-Client response contents of the "access_token" field from the AS-to-Client response
as opaque data as specified in Section 4.2 of [RFC7925] and not as opaque data as specified in Section 4.2 of [RFC7925] and not
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
process the contents of the "psk_identity" field as access token that parse the contents of the "psk_identity" field as CBOR data structure
is stored with the authorization information endpoint, before and process the contents as following:
continuing the DTLS handshake. If the contents of the "psk_identity"
do not yield a valid access token for the requesting client, the o If the data contains a "cnf" field with a "COSE_Key" structure
resource server aborts the DTLS handshake with an "illegal_parameter" with a "kid", the resource server continues the DTLS handshake
alert. with the stored key associated with this kid.
o If the data comprises additional CWT information, this information
must be stored as access token for this DTLS association before
continuing with the DTLS handshake.
If the contents of the "psk_identity" do not yield sufficient
information to select a valid access token for the requesting client,
the resource server aborts the DTLS handshake with an
"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 assumes that the access token is a PoP token as
described in [I-D.ietf-ace-oauth-authz] unless specifically stated described in [I-D.ietf-ace-oauth-authz] unless specifically stated
otherwise. Therefore, the access token is bound to a symmetric PoP otherwise. Therefore, the access token is bound to a symmetric PoP
key that is used as shared secret between the client and the resource key that is used as shared secret between the client and the resource
server. The resource server may use token introspection [RFC7662] on server. The resource server may use token introspection [RFC7662] on
skipping to change at page 15, line 46 skipping to change at page 16, line 15
3.4. Resource Access 3.4. Resource Access
Once a DTLS channel has been established as described in Section 3.2 Once a DTLS channel has been established as described in Section 3.2
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 section keying material is associated with the channel. According to
5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one access Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
token for each client. New access tokens issued by the authorization access token for each client. New access tokens issued by the
server are supposed to replace previously issued access tokens for authorization server are supposed to replace previously issued access
the respective client. The resource server therefore must have a tokens for the respective client. The resource server therefore must
common understanding with the authorization server how access tokens have a common understanding with the authorization server how access
are ordered. tokens are ordered.
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 MAY include AS Request Creation Hints as response. The response SHOULD include AS Request Creation Hints as
described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz].
The resource server MUST only accept an incoming CoAP request as The resource server MUST only accept an incoming CoAP request as
authorized if the following holds: authorized if the following holds:
1. The message was received on a secure channel that has been 1. The message was received on a secure channel that has been
established using the procedure defined in this document. established using the procedure defined in this document.
2. The authorization information tied to the sending client is 2. The authorization information tied to the sending client is
valid. valid.
skipping to change at page 16, line 49 skipping to change at page 17, line 19
1. with response code 4.03 (Forbidden) when the resource URI 1. with response code 4.03 (Forbidden) when the resource URI
specified in the request is not covered by the authorization specified in the request is not covered by the authorization
information, and information, and
2. with response code 4.05 (Method Not Allowed) when the resource 2. with response code 4.05 (Method Not Allowed) when the resource
URI specified in the request covered by the authorization URI specified in the request covered by the authorization
information but not the requested action. information but not the requested action.
The client MUST ascertain that its keying material is still valid The client MUST ascertain that its keying material is still valid
before sending a request or processing a response. If the client before sending a request or processing a response. If the client
gets an error response containing AS Request Creation Hints (cf. recently has updated the access token (see Section 4), it must be
Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its prepared that its request is still handled according to the previous
requests, it SHOULD request a new access token from the authorization authorization rules as there is no strict ordering between access
server in order to continue communication with the resource server. token uploads and resource access messages. See also Section 7.2 for
a discussion of access token processing.
If the client gets an error response containing AS Request Creation
Hints (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response
to its requests, it SHOULD request a new access token from the
authorization server in order to continue communication with the
resource server.
Unauthorized requests that have been received over a DTLS session Unauthorized requests that have been received over a DTLS session
SHOULD be treated as non-fatal by the resource server, i.e., the DTLS SHOULD be treated as non-fatal by the resource server, i.e., the DTLS
session SHOULD be kept alive until the associated access token has session SHOULD be kept alive until the associated access token has
expired. expired.
4. Dynamic Update of Authorization Information 4. Dynamic Update of Authorization Information
Resource servers must only use a new access token to update the Resource servers must only use a new access token to update the
authorization information for a DTLS session if the keying material authorization information for a DTLS session if the keying material
skipping to change at page 18, line 42 skipping to change at page 19, line 14
after the last access token associated with this association has after the last access token associated with this association has
expired. expired.
As specified in Section 5.8.3 of [I-D.ietf-ace-oauth-authz], the As specified in Section 5.8.3 of [I-D.ietf-ace-oauth-authz], the
resource server MUST notify the client with an error response with resource server MUST notify the client with an error response with
code 4.01 (Unauthorized) for any long running request before code 4.01 (Unauthorized) for any long running request before
terminating the association. terminating the association.
6. Secure Communication with an Authorization Server 6. Secure Communication with an Authorization Server
As specified in the ACE framework (sections 5.6 and 5.7 of As specified in the ACE framework (Sections 5.6 and 5.7 of
[I-D.ietf-ace-oauth-authz]), the requesting entity (the resource [I-D.ietf-ace-oauth-authz]), the requesting entity (the resource
server and/or the client) and the authorization server communicate server and/or the client) and the authorization server communicate
via the token endpoint or introspection endpoint. The use of CoAP via the token endpoint or introspection endpoint. The use of CoAP
and DTLS for this communication is RECOMMENDED in this profile, other and DTLS for this communication is RECOMMENDED in this profile, other
protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be
used instead. used instead.
How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the
authorization server are established is out of scope for this authorization server are established is out of scope for this
profile. profile.
If other means of securing the communication with the authorization If other means of securing the communication with the authorization
server are used, the communication security requirements from server are used, the communication security requirements from
Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable. Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable.
7. Security Considerations 7. Security Considerations
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. As it follows this framework's general [I-D.ietf-ace-oauth-authz]. As it follows this framework's general
approach, the general security considerations from section 6 of approach, the general security considerations from Section 6 of
[I-D.ietf-ace-oauth-authz] also apply to this profile. [I-D.ietf-ace-oauth-authz] also apply to this profile.
The authorization server must ascertain that the keying material for The authorization server must ascertain that the keying material for
the client that it provides to the resource server actually is the client that it provides to the resource server actually is
associated with this client. Malicious clients may hand over access associated with this client. Malicious clients may hand over access
tokens containing their own access permissions to other entities. tokens containing their own access permissions to other entities.
This problem cannot be completely eliminated. Nevertheless, in RPK This problem cannot be completely eliminated. Nevertheless, in RPK
mode it should not be possible for clients to request access tokens mode it should not be possible for clients to request access tokens
for arbitrary public keys, since that would allow the client to relay for arbitrary public keys: if the client can cause the authorization
tokens without the need to share its own credentials with others. server to issue a token for a public key without proving possession
The authorization server therefore at some point needs to validate of the corresponding private key, this allows for identity misbinding
that the client can actually use the private key corresponding to the attacks where the issued token is usable by an entity other than the
client's public key. intended one. The authorization server therefore at some point needs
to validate that the client can actually use the private key
corresponding to the client's public key.
When using pre-shared keys provisioned by the authorization server, When using pre-shared keys provisioned by the authorization server,
the security level depends on the randomness of PSK, and the security the security level depends on the randomness of PSK, and the security
of the TLS cipher suite and key exchange algorithm. As this of the TLS cipher suite and key exchange algorithm. As this
specification targets at constrained environments, message payloads specification targets at constrained environments, message payloads
exchanged between the client and the resource server are expected to exchanged between the client and the resource server are expected to
be small and rare. CoAP [RFC7252] mandates the implementation of be small and rare. CoAP [RFC7252] mandates the implementation of
cipher suites with abbreviated, 8-byte tags for message integrity cipher suites with abbreviated, 8-byte tags for message integrity
protection. For consistency, this profile requires implementation of protection. For consistency, this profile requires implementation of
the same cipher suites. For application scenarios where the cost of the same cipher suites. For application scenarios where the cost of
skipping to change at page 22, line 7 skipping to change at page 22, line 18
authorization server must have obtained a common understanding how authorization server must have obtained a common understanding how
this resource server is identified to ensure that the client obtains this resource server is identified to ensure that the client obtains
access token and keying material for the correct resource server. If access token and keying material for the correct resource server. If
the client is provided with a raw public key for the resource server, the client is provided with a raw public key for the resource server,
it must be ascertained to which resource server (which identifier and it must be ascertained to which resource server (which identifier and
authorization information) the key is associated. All authorization authorization information) the key is associated. All authorization
information and keying material must be kept up to date. information and keying material must be kept up to date.
8. Privacy Considerations 8. Privacy Considerations
This privacy considerations from section 7 of the This privacy considerations from Section 7 of the
[I-D.ietf-ace-oauth-authz] apply also to this profile. [I-D.ietf-ace-oauth-authz] apply also to this profile.
An unprotected response to an unauthorized request may disclose An unprotected response to an unauthorized request may disclose
information about the resource server and/or its existing information about the resource server and/or its existing
relationship with the client. It is advisable to include as little relationship with the client. It is advisable to include as little
information as possible in an unencrypted response. When a DTLS information as possible in an unencrypted response. When a DTLS
session between an authenticated client and the resource server session between an authenticated client and the resource server
already exists, more detailed information MAY be included with an already exists, more detailed information MAY be included with an
error response to provide the client with sufficient information to error response to provide the client with sufficient information to
react on that particular error. react on that particular error.
skipping to change at page 24, line 5 skipping to change at page 24, line 19
[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>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
<https://www.rfc-editor.org/info/rfc7251>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
skipping to change at page 25, line 5 skipping to change at page 25, line 22
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012, DOI 10.17487/RFC6655, July 2012,
<https://www.rfc-editor.org/info/rfc6655>. <https://www.rfc-editor.org/info/rfc6655>.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
<https://www.rfc-editor.org/info/rfc7251>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
 End of changes. 24 change blocks. 
72 lines changed or deleted 99 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/