One document matched: draft-gerdes-ace-dtls-authorize-00.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-gerdes-ace-dtls-authorize-00" category="std">
<front>
<title abbrev="CoAP-DTLS">Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
<author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63906</phone>
<email>gerdes@tzi.org</email>
</address>
</author>
<author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63904</phone>
<email>bergmann@tzi.org</email>
</address>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email>
</address>
</author>
<author initials="G." surname="Selander" fullname="Göran Selander">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farögatan 6</street>
<city>Kista</city>
<code>164 80</code>
<country>Sweden</country>
</postal>
<email>goran.selander@ericsson.com</email>
</address>
</author>
<author initials="L." surname="Seitz" fullname="Ludwig Seitz">
<organization>SICS Swedish ICT AB</organization>
<address>
<postal>
<street>Scheelevägen 17</street>
<city>Lund</city>
<code>223 70</code>
<country>Sweden</country>
</postal>
<email>ludwig@sics.se</email>
</address>
</author>
<date year="2016" month="October" day="31"/>
<area>Security</area>
<workgroup>ACE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This specification defines a profile for delegating client
authentication and authorization in a constrained environment by
establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes.
The protocol relies on DTLS for communication security
between entities in a constrained network. A
resource-constrained node can use this protocol to delegate
management of authorization
information to a trusted host with less severe limitations regarding
processing power and memory.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>This specification defines a profile of the ACE framework
<xref target="I-D.ietf-ace-oauth-authz"/>. In this profile, a client and a resource server
use CoAP <xref target="RFC7252"/> over DTLS <xref target="RFC6347"/> to communicate. The client uses an
access token, bound to a key (the proof-of-possession key) to authorize its
access to the resource server. DTLS provides communication security,
proof of possession, and server authentication. Optionally the client and the
resource server may also use CoAP over DTLS to communicate with the
authorization server. This specification supports the DTLS PSK handshake
<xref target="RFC4279"/> and the DTLS handshake with Raw Public Keys (RPK) <xref target="RFC7250"/>.</t>
<t>The DTLS PSK handshake <xref target="RFC4279"/> provides the proof-of-possession for the key
tied to the access token. Furthermore the psk_identity parameter in the DTLS
PSK handshake is used to transfer the access token from the client to the
resource server.</t>
<t>The DTLS RPK handshake <xref target="RFC7250"/> requires client authentication to provide
proof-of-possession for the key tied to the access token. Here the access token
needs to be transferred to the resource server before the handshake is initiated,
as described in <eref target="https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#section-8.1">section 8.1 of draft-ietf-ace-oauth-authz.</eref></t>
<t><list style="hanging">
<t hangText='Note: While the scope of this draft is on client and resource server'>
communicating using CoAP over DTLS, it is expected that it applies
also to CoAP over TLS, possibly with minor modifications. However,
that is out of scope for this version of the draft.</t>
</list></t>
<section anchor="terminology" title="Terminology">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119 <xref target="RFC2119"/>.</t>
<t>Readers are expected to be familiar with the terms and concepts
described in <xref target="I-D.ietf-ace-oauth-authz"/>.</t>
</section>
</section>
<section anchor="overview" title="Protocol Overview">
<t>The CoAP-DTLS profile for ACE specifies the transfer of authentication
and, if necessary, authorization information between C and RS during
setup of a DTLS session for CoAP messaging. It also specifies how a
Client can use CoAP over DTLS to retrieve an Access Token from AS for
a protected resource hosted on RS.</t>
<t>This profile requires a Client (C) to retrieve an Access Token for the
resource(s) it wants to access on a Resource Server (RS) as specified
in <xref target="I-D.ietf-ace-oauth-authz"/>. <xref target="at-retrieval"/> shows the
typical message flow in this scenario (messages
in square brackets are optional):</t>
<figure title="Retrieving an Access Token" anchor="at-retrieval"><artwork><![CDATA[
C RS AS
| [-- Resource Request --->] | |
| | |
| [<----- AS Information --] | |
| | |
| --- Token Request ----------------------------> |
| | |
| <---------------------------- Access Token ----- |
| + RS Information |
]]></artwork></figure>
<t>To determine the AS in charge of a resource hosted at the RS, C MAY
send an initial Unauthorized Resource Request message to RS. RS then
denies the request and sends the address of its AS back to C.</t>
<t>Instead of the initial Unauthorized Resource Request message, C MAY
look up the desired resource in a
resource directory (cf. <xref target="I-D.ietf-core-resource-directory"/>).</t>
<t>Once C knows AS’s address, it can send an Access Token request to
the /token endpoint at the AS as specified in <xref target="I-D.ietf-ace-oauth-authz"/>.
If C wants to use the CoAP RawPublicKey mode as
described in <eref target="https://tools.ietf.org/html/rfc7252#section-9">Section 9 of RFC 7252</eref>
it MUST provide a key or key identifier within a <spanx style="verb">cnf</spanx> object in the
token request.
If AS decides that the request is to be authorized it
generates an access token response for C containing a <spanx style="verb">profile</spanx> parameter
with the value <spanx style="verb">coap_dtls</spanx> to indicate that this profile MUST be used for communication between C and RS.
Is also adds a <spanx style="verb">cnf</spanx> parameter with additional data for the establishment of a
secure DTLS channel between C and RS. The semantics of the ‘cnf’ parameter depend on the type of key used between C and RS, see <xref target="rpk-mode"/> and <xref target="psk-mode"/>.</t>
<t>The Access Token returned by AS then can be used by C to establish a
new DTLS session with RS. When C intends to use asymmetric
cryptography in the DTLS handshake with RS, C MUST upload the Access Token to
the <spanx style="verb">/authz-info</spanx> resource on RS before starting the DTLS handshake, as
described in <eref target="https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#section-8.1">section 8.1 of draft-ietf-ace-oauth-authz</eref>. If only symmetric cryptography is used between C and RS, the Access Token MAY instead be transferred in the DTLS ClientKeyExchange message
(see <xref target="psk-dtls-channel"/>).</t>
<t><xref target="protocol-overview"/> depicts the common protocol flow for the
DTLS profile after C has retrieved the Access Token from AS.</t>
<figure title="Protocol overview" anchor="protocol-overview"><artwork><![CDATA[
C RS AS
| [--- Access Token ------>] | |
| | |
| <== DTLS channel setup ==> | |
| | |
| == Authorized Request ===> | |
| | |
| <=== Protected Resource == | |
]]></artwork></figure>
<t>The following sections specify how CoAP is used to interchange
access-related data between RS and AS so that AS can
provide C and RS with sufficient information to establish a secure
channel, and convey
authorization information specific for this communication relationship
to RS.</t>
<t>Depending on the desired CoAP security mode, the Client-to-AS request,
AS-to-Client response and DTLS session establishment carry slightly
different information. <xref target="rpk-mode"/> addresses the use of raw public
keys while <xref target="psk-mode"/> defines how pre-shared keys are used in this
profile.</t>
<section anchor="rreq" title="Unauthorized Resource Request Message">
<t>The optional Unauthorized Resource Request message is a request for a resource
hosted by RS for which no proper authorization is granted. RS MUST
treat any CoAP request for a resource other than <spanx style="verb">/authz-info</spanx>
as Unauthorized Resource Request message when any of the
following holds:</t>
<t><list style="symbols">
<t>The request has been received on an unprotected channel.</t>
<t>RS has no valid access token for the sender of the
request regarding the requested action on that resource.</t>
<t>RS has a valid access token for the sender of the
request, but this does not allow the requested action on the requested
resource.</t>
</list></t>
<t>Note: These conditions ensure that RS can handle requests autonomously
once access was granted and a secure channel has been established
between C and RS. The resource <spanx style="verb">/authz-info</spanx> is publicly accessible
to be able to upload new access tokens to RS (cf. <xref target="I-D.ietf-ace-oauth-authz"/>).</t>
<t>Unauthorized Resource Request messages MUST be denied with a client error
response. In this response, the Resource Server SHOULD provide
proper AS Information to enable the Client to request an
access token from RS’s Authorization Server as described in <xref target="as-info"/>.</t>
<t>The response code MUST be 4.01 (Unauthorized) in case the sender of
the Unauthorized Resource Request message is not authenticated, or if
RS has no valid access token for C. If RS has an access token for C
but not for the resource that C has requested, RS
MUST reject the request with a 4.03 (Forbidden). If RS has
an access token for C but it does not cover the action C
requested on the resource, RS MUST reject the request with a 4.05
(Method Not Allowed).</t>
<t><list style="hanging">
<t hangText='Note:'>
The use of the response codes 4.03 and 4.05 is intended to prevent
infinite loops where a dumb Client optimistically tries to access
a requested resource with any access token received from AS.
As malicious clients could pretend to be C to determine C’s
privileges, these detailed response codes must be used only when a
certain level of security is already available which can be achieved
only when the Client is authenticated.</t>
</list></t>
</section>
<section anchor="as-info" title="AS Information">
<t>The AS Information is sent by RS as a response to an
Unauthorized Resource Request message (see <xref target="rreq"/>) to point the sender of the
Unauthorized Resource Request message to RS’s AS. The AS
information is a set of attributes containing an absolute URI (see
Section 4.3 of <xref target="RFC3986"/>) that specifies the AS in charge of RS.</t>
<t><list style="hanging">
<t hangText='TBD: We might not want to add more parameters in the AS information because'>
this would not only reveal too much information about RS’s
capabilities to unauthorized peers but also be of little value as C
cannot really trust that information anyway.</t>
</list></t>
<t>The message MAY also contain a nonce generated by RS to ensure freshness
in case that the RS and AS do not have synchronized clocks.</t>
<t><xref target="as-info-payload"/> shows an example for an AS Information message
payload using CBOR <xref target="RFC7049"/> diagnostic notation.</t>
<figure title="AS Information payload example" anchor="as-info-payload"><artwork><![CDATA[
4.01 Unauthorized
Content-Format: application/ace+cbor
{AS: "coaps://as.example.com/token",
nonce: h'e0a156bb3f'}
]]></artwork></figure>
<t>In this example, the attribute AS points the receiver of this message
to the URI “coaps://as.example.com/token” to request access
permissions. The originator of the AS Information payload
(i.e., RS) uses a local clock that is loosely synchronized with a time
scale common between RS and AS (e.g., wall clock time). Therefore, it has included a parameter <spanx style="verb">nonce</spanx> for replay attack prevention (c.f. <xref target="nonce"/>).</t>
<t><list style="hanging">
<t hangText='Note: There is an ongoing discussion how freshness of access tokens'>
can be achieved in constrained environments. This specification for
now assumes that RS and AS do not have a common understanding of time that
allows RS to achieve its security objectives without explicitly adding
a nonce.</t>
</list></t>
<t>The examples in this document are written in CBOR diagnostic notation
to improve readability. <xref target="as-info-cbor"/> illustrates the binary
encoding of the message payload shown in <xref target="as-info-payload"/>.</t>
<figure title="AS Information example encoded in CBOR" anchor="as-info-cbor"><artwork><![CDATA[
a2 # map(2)
00 # unsigned(0) (=AS)
78 1c # text(28)
636f6170733a2f2f61732e657861
6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
05 # unsigned(5) (=nonce)
45 # bytes(5)
e0a156bb3f
]]></artwork></figure>
</section>
<section anchor="resource-access" title="Resource Access">
<t>Once a DTLS channel has been established as described in <xref target="rpk-mode"/> and <xref target="psk-mode"/>, respectively,
C is authorized to access resources covered by the Access Token it has
uploaded to the <spanx style="verb">/authz-info</spanx> resource hosted by RS.</t>
<t>On the server side (i.e., RS), successful establishment of the DTLS
channel binds C to the access token, functioning as a proof-of-possession associated key. Any request that RS receives on this channel MUST be checked against these authorization rules that are associated with the identity of C. Incoming CoAP requests that are not authorized
with respect to any Access Token that is associated with C MUST be
rejected by RS with 4.01 response as described in <xref target="rreq"/>.</t>
<t><list style="hanging">
<t hangText='Note: The identity of C is determined by the authentication process'>
during the DTLS handshake. In the asymmetric case, the public key
will define C’s identity, while in the PSK case, C’s identity is
defined by the session key generated by AS for this communication.</t>
</list></t>
<t>RS SHOULD treat an incoming CoAP request as authorized
if the following holds:</t>
<t><list style="numbers">
<t>The message was received on a secure channel that has been
established using the procedure defined in this document.</t>
<t>The authorization information tied to the sending peer is valid.</t>
<t>The request is destined for RS.</t>
<t>The resource URI specified in the request is covered by the
authorization information.</t>
<t>The request method is an authorized action on the resource with
respect to the authorization information.</t>
</list></t>
<t>Incoming CoAP requests received on a secure DTLS channel
MUST be rejected</t>
<t><list style="numbers">
<t>with response code 4.03 (Forbidden) when the resource URI specified
in the request is not covered by the authorization information, and</t>
<t>with response code 4.05 (Method Not Allowed) when the resource URI
specified in the request covered by the authorization information but
not the requested action.</t>
</list></t>
<t>C cannot always know a priori if a Authorized Resource Request
will succeed. If C repeatedly gets AS Information messages (cf. <xref target="as-info"/>) as response
to its requests, it SHOULD request a new Access Token from AS in order to
continue communication with RS.</t>
</section>
<section anchor="update" title="Dynamic Update of Authorization Information">
<t>The Client can update the authorization information stored at
RS at any time. To do so, the Client requests from AS a new Access Token
for the intended action on the respective resource and uploads
this Access Token to the <spanx style="verb">/authz-info</spanx> resource on RS.</t>
<t><xref target="update-overview"/> depicts the message flow where C requests a new
Access Token after a security association between C and RS has been
established using this protocol.</t>
<figure title="Overview of Dynamic Update Operation" anchor="update-overview"><artwork><![CDATA[
C RS AS
| <===== DTLS channel =====> | |
| + Access Token | |
| | |
| --- Token Request ----------------------------> |
| | |
| <---------------------------- New Access Token - |
| + RS Information |
| | |
| --- Update /authz-info --> | |
| New Access Token | |
| | |
| == Authorized Request ===> | |
| | |
| <=== Protected Resource == | |
]]></artwork></figure>
</section>
</section>
<section anchor="rpk-mode" title="RawPublicKey Mode">
<t>To retrieve an access token for the resource that C wants to access, C
requests an Access Token from AS. C MUST add a <spanx style="verb">cnf</spanx> object
carrying either its raw public key or a unique identifier for a
public key that it has previously made known to AS.</t>
<t>An example Access Token request from C to RS is depicted in
<xref target="rpk-authorization-message-example"/>.</t>
<figure title="Access Token Request Example for RPK Mode" anchor="rpk-authorization-message-example"><artwork><![CDATA[
POST coaps://as.example.com/token
Content-Format: application/cbor
{
grant_type: client_credentials,
aud: "tempSensor4711",
cnf: {
COSE_Key: {
kty: EC2,
crv: P-256,
x: h'TODOX',
y: h'TODOY'
}
}
}
]]></artwork></figure>
<t>The example shows an Access Token request for the resource identified
by the audience string “tempSensor4711” on the AS using a raw public key.</t>
<t>When AS authorizes a request, it will return an Access Token and a
<spanx style="verb">cnf</spanx> object in the AS-to-Client response. Before C initiates the DTLS
handshake with RS, it MUST send a <spanx style="verb">POST</spanx> request containing the new
Access Token to the <spanx style="verb">/authz-info</spanx> resource hosted by RS. If this
operation yields a positive response, C SHOULD proceed to establish a
new DTLS channel with RS. To use raw public key mode, C MUST pass the
same public key that was used for constructing the Access Token with
the SubjectPublicKeyInfo structure in the DTLS handshake as specified
in <xref target="RFC7250"/>.</t>
<t><list style="hanging">
<t hangText='Note:'>
According to <xref target="RFC7252"/>, CoAP implementations MUST support the
ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251"/>
and the NIST P-256 curve. C is therefore expected to offer at least
this ciphersuite to RS.</t>
</list></t>
<t>The Access Token is constructed by AS such that RS can associate the
Access Token with the Client’s public key. If CBOR web tokens
<xref target="I-D.ietf-ace-cbor-web-token"/> are used as recommended in
<xref target="I-D.ietf-ace-oauth-authz"/>, the AS MUST include a <spanx style="verb">COSE_Key</spanx> object
in the <spanx style="verb">cnf</spanx> claim of the Access Token. This <spanx style="verb">COSE_Key</spanx> object MAY
contain a reference to a key for C that is already known by RS (e.g.,
from previous communication). If the AS has no certain knowledge that
the Client’s key is already known to RS, the Client’s public key MUST
be included in the Access Token’s <spanx style="verb">cnf</spanx> parameter.</t>
</section>
<section anchor="psk-mode" title="PreSharedKey Mode">
<t>To retrieve an access token for the resource that C wants to access, C
MAY include a <spanx style="verb">cnf</spanx> object carrying an identifier for a symmetric key
in its Access Token request to AS. This identifier can be used by AS
to determine the session key to construct the proof-of-possession
token and therefore MUST specify a symmetric key that was previously
generated by AS as a session key for the communication between C and
RS.</t>
<t>Depending on the requested token type and algorithm in the Access
Token request, AS adds RS Information to the response that provides C
with sufficient information to setup a DTLS channel with RS. For
symmetric proof-of-possession keys
(c.f. <xref target="I-D.ietf-ace-oauth-authz"/>), C must ensure that the Access
Token request is sent over a secure channel that guarantees
authentication, message integrity and confidentiality. This could be,
e.g., a DTLS channel (for “coaps”) or an OSCOAP
<xref target="I-D.ietf-core-object-security"/> exchange (for “coap”).</t>
<t>When AS authorizes C it returns an AS-to-Client response with the
profile parameter set to <spanx style="verb">coap_dtls</spanx> and a <spanx style="verb">cnf</spanx> parameter carrying a
<spanx style="verb">COSE_Key</spanx> object that contains the symmetric session key to be used
between C and RS as illustrated in <xref target="at-response"/>.</t>
<!-- msg1 -->
<figure title="Example Access Token response" anchor="at-response"><artwork><![CDATA[
2.01 Created
Content-Format: application/cbor
Location-Path: /token/asdjbaskd
Max-Age: 86400
{
access_token: b64'SlAV32hkKG ...
(remainder of CWT omitted for brevity;
token_type: pop,
alg: HS256,
expires_in: 86400,
profile: coap_dtls,
cnf: {
COSE_Key: {
kty: symmetric,
k: h'73657373696f6e6b6579'
}
}
}
]]></artwork></figure>
<t>In this example, AS returns a 2.01 response containing a new Access
Token. The information is transferred as a CBOR data structure as
specified in <xref target="I-D.ietf-ace-oauth-authz"/>. The Max-Age option tells
the receiving Client how long this token will be valid.</t>
<t>A response that declines any operation on the requested
resource is constructed according to <eref target="https://tools.ietf.org/html/rfc6749#section-5.2">Section 5.2 of RFC 6749</eref>, (cf. Section 6.3 of <xref target="I-D.ietf-ace-oauth-authz"/>).</t>
<figure title="Example Access Token response with reject" anchor="token-reject"><artwork><![CDATA[
4.00 Bad Request
Content-Format: application/cbor
{
error: invalid_request
}
]]></artwork></figure>
<section anchor="psk-dtls-channel" title="DTLS Channel Setup Between C and RS">
<t>When C receives an Access Token from AS, it checks if the payload
contains an <spanx style="verb">access_token</spanx> parameter and a <spanx style="verb">cnf</spanx> parameter. With this
information C can initiate establishment of a new DTLS channel with
RS. To use DTLS with pre-shared keys, C follows the PSK key exchange
algorithm specified in Section 2 of <xref target="RFC4279"/> using the key conveyed
in the <spanx style="verb">cnf</spanx> parameter of the AS response as PSK when constructing the
premaster secret.</t>
<t>In PreSharedKey mode, the knowledge of the session key by C and RS is
used for mutual authentication between both peers. Therefore, RS must
be able to determine the session key from the Access Token. Following
the general ACE authorization framework, C can upload the Access Token
to RS’s <spanx style="verb">/authz-info</spanx> resource before starting the DTLS
handshake. Alternatively, C MAY provide the most recent base64-encoded
Access Token in the <spanx style="verb">psk_identity</spanx> field of the ClientKeyExchange
message.</t>
<t>If RS receives a ClientKeyExchange message that contains a
<spanx style="verb">psk_identity</spanx> with a length greater zero, it MUST base64-decode its
contents and process it in the same way as an Access Token that has
been uploaded to its <spanx style="verb">/authz-info</spanx> resource. If the contents of the
<spanx style="verb">psk_identity</spanx> contained a syntactically valid Access Token, RS
continues processing the ClientKeyExchange message. Otherwise, the
DTLS session setup is terminated with an <spanx style="verb">illegal_parameter</spanx> DTLS
alert message.</t>
<t><list style="hanging">
<t hangText='Note1: As RS cannot provide C with a meaningful PSK identity hint in'>
response to C’s ClientHello message, RS SHOULD NOT send a
ServerKeyExchange message.</t>
<t hangText='Note2:'>
According to <xref target="RFC7252"/>, CoAP implementations MUST support the
ciphersuite TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655"/>. C is
therefore expected to offer at least this ciphersuite to RS.</t>
</list></t>
<t>This specification assumes that the Access Token is a PoP token as
described in <xref target="I-D.ietf-ace-oauth-authz"/> unless specifically stated
otherwise. Therefore, the Access Token is bound to a symmetric PoP key
that is used as session key between C and RS.</t>
<t>While C can retrieve the session key from the contents of the <spanx style="verb">cnf</spanx>
parameter in the AS-to-Client response, RS uses the information contained
in the <spanx style="verb">cnf</spanx> claim of the Access Token to determine the actual session
key. Usually, this is done by including a <spanx style="verb">COSE_Key</spanx> object carrying
either a key that has been encrypted with a shared secret between AS
and RS, or a key identifier that can be used by RS to lookup the
session key.</t>
<t>Instead of the <spanx style="verb">COSE_Key</spanx> object, AS MAY include a <spanx style="verb">COSE_Encrypt</spanx>
structure to enable RS to calculate the session key from the Access
Token. The <spanx style="verb">COSE_Encrypt</spanx> structure MUST use the <spanx style="emph">Direct Key with KDF</spanx>
method as described in <eref target="https://tools.ietf.org/html/draft-ietf-cose-msg-23#section-12.1.2">Section 12.1.2 of draft-ietf-cose-msg</eref>.
The AS MUST include a Context information structure carrying a
PartyU <spanx style="verb">nonce</spanx> parameter carrying the nonce that has been used by AS
to construct the session key.</t>
<t>This specification mandates that at least the key derivation algorithm
<spanx style="verb">HKDF SHA-256</spanx> as defined in <xref target="I-D.ietf-cose-msg"/> MUST be supported.
This key derivation function is the default when no <spanx style="verb">alg</spanx>
field is included in the <spanx style="verb">COSE_Encrypt</spanx> structure for RS.</t>
</section>
<section anchor="updating-authorization-information" title="Updating Authorization Information">
<t>Usually, the authorization information that RS keeps for C is updated
by uploading a new Access Token as described in <xref target="update"/>.</t>
<t>If the security association with RS still exists and RS has indicated
support for session renegotiation according to <xref target="RFC5746"/>, the new
Access Token MAY be used to renegotiate the existing DTLS session. In
this case, the Access Token is used as <spanx style="verb">psk_identity</spanx> as defined in
<xref target="psk-dtls-channel"/>. The Client MAY also perform a new DTLS handshake
according to <xref target="psk-dtls-channel"/> that replaces the existing DTLS session.</t>
<t>After successful completion of the DTLS handshake RS updates the
existing authorization information for C according to the
new Access Token.</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TODO</t>
<section anchor="unprotected-as-information" title="Unprotected AS Information">
<t>Initially, no secure channel exists to protect the communication
between C and RS. Thus, C cannot determine if the AS information
contained in an unprotected response from RS to an unauthorized
request (c.f. <xref target="as-info"/>) is authentic. It is therefore advisable to
provide C with a (possibly hard-coded) list of trustworthy
authorization servers. AS information responses referring to a URI not
listed there would be ignored.</t>
</section>
<section anchor="nonce" title="Use of Nonces for Replay Protection">
<t>RS may add a nonce to the AS Information message sent as a response to
an unauthorized request to ensure freshness of an Access Token
subsequently presented to RS. While a timestamp of some granularity
would be sufficient to protect against replay attacks, using
randomized nonce is preferred to prevent disclosure of information
about RS’s internal clock characteristics.</t>
</section>
<section anchor="privacy" title="Privacy">
<t>An unprotected response to an unauthorized request (c.f. <xref target="as-info"/>)
may disclose information about RS and/or its existing relationship
with C. It is advisable to include as little information as possible
in an unencrypted response. When a DTLS session between C and RS
already exists, more detailed information may be included with an
error response to provide C with sufficient information to react on
that particular error.</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC3986' target='http://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
<reference anchor='RFC4279' target='http://www.rfc-editor.org/info/rfc4279'>
<front>
<title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)</title>
<author initials='P.' surname='Eronen' fullname='P. Eronen' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<date year='2005' month='December' />
<abstract><t>This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4279'/>
<seriesInfo name='DOI' value='10.17487/RFC4279'/>
</reference>
<reference anchor='RFC5746' target='http://www.rfc-editor.org/info/rfc5746'>
<front>
<title>Transport Layer Security (TLS) Renegotiation Indication Extension</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='M.' surname='Ray' fullname='M. Ray'><organization /></author>
<author initials='S.' surname='Dispensa' fullname='S. Dispensa'><organization /></author>
<author initials='N.' surname='Oskov' fullname='N. Oskov'><organization /></author>
<date year='2010' month='February' />
<abstract><t>Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5746'/>
<seriesInfo name='DOI' value='10.17487/RFC5746'/>
</reference>
<reference anchor='RFC6347' target='http://www.rfc-editor.org/info/rfc6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>
</reference>
<reference anchor='RFC7252' target='http://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>
<reference anchor='I-D.ietf-ace-oauth-authz'>
<front>
<title>Authentication and Authorization for Constrained Environments (ACE)</title>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<author initials='G' surname='Selander' fullname='Goeran Selander'>
<organization />
</author>
<author initials='E' surname='Wahlstroem' fullname='Erik Wahlstroem'>
<organization />
</author>
<author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<date month='October' day='31' year='2016' />
<abstract><t>This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-ace-oauth-authz-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-04.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC6655' target='http://www.rfc-editor.org/info/rfc6655'>
<front>
<title>AES-CCM Cipher Suites for Transport Layer Security (TLS)</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<author initials='D.' surname='Bailey' fullname='D. Bailey'><organization /></author>
<date year='2012' month='July' />
<abstract><t>This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6655'/>
<seriesInfo name='DOI' value='10.17487/RFC6655'/>
</reference>
<reference anchor='RFC7049' target='http://www.rfc-editor.org/info/rfc7049'>
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<date year='2013' month='October' />
<abstract><t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t></abstract>
</front>
<seriesInfo name='RFC' value='7049'/>
<seriesInfo name='DOI' value='10.17487/RFC7049'/>
</reference>
<reference anchor='RFC7250' target='http://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>
<reference anchor='RFC7251' target='http://www.rfc-editor.org/info/rfc7251'>
<front>
<title>AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<author initials='D.' surname='Bailey' fullname='D. Bailey'><organization /></author>
<author initials='M.' surname='Campagna' fullname='M. Campagna'><organization /></author>
<author initials='R.' surname='Dugal' fullname='R. Dugal'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.</t></abstract>
</front>
<seriesInfo name='RFC' value='7251'/>
<seriesInfo name='DOI' value='10.17487/RFC7251'/>
</reference>
<reference anchor='I-D.ietf-core-object-security'>
<front>
<title>Object Security of CoAP (OSCOAP)</title>
<author initials='G' surname='Selander' fullname='Goeran Selander'>
<organization />
</author>
<author initials='J' surname='Mattsson' fullname='John Mattsson'>
<organization />
</author>
<author initials='F' surname='Palombini' fullname='Francesca Palombini'>
<organization />
</author>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<date month='October' day='20' year='2016' />
<abstract><t>This memo defines Object Security of CoAP (OSCOAP), a method for application layer protection of message exchanges with the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE) format. OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure binding between CoAP request and response messages. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-core-object-security-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-object-security-00.txt' />
</reference>
<reference anchor='I-D.ietf-core-resource-directory'>
<front>
<title>CoRE Resource Directory</title>
<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
<organization />
</author>
<author initials='M' surname='Koster' fullname='Michael Koster'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<author initials='P' surname='Stok' fullname='Peter Van der Stok'>
<organization />
</author>
<date month='October' day='31' year='2016' />
<abstract><t>In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-core-resource-directory-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-09.txt' />
</reference>
<reference anchor='I-D.ietf-ace-cbor-web-token'>
<front>
<title>CBOR Web Token (CWT)</title>
<author initials='E' surname='Wahlstroem' fullname='Erik Wahlstroem'>
<organization />
</author>
<author initials='M' surname='Jones' fullname='Michael Jones'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
<organization />
</author>
<date month='July' day='7' year='2016' />
<abstract><t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. CWT is a profile of the JSON Web Token (JWT) that is optimized for constrained devices. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/ value pair consisting of a claim name and a claim value.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-ace-cbor-web-token-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-ace-cbor-web-token-01.txt' />
</reference>
<reference anchor='I-D.ietf-cose-msg'>
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials='J' surname='Schaad' fullname='Jim Schaad'>
<organization />
</author>
<date month='October' day='18' year='2016' />
<abstract><t>Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-cose-msg-23' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-cose-msg-23.txt' />
</reference>
</references>
<!-- LocalWords: Datagram CoAP CoRE DTLS introducer URI
-->
<!-- LocalWords: namespace Verifier JSON timestamp timestamps PSK
-->
<!-- LocalWords: decrypt UTC decrypted whitespace preshared HMAC
-->
<!-- Local Variables: -->
<!-- coding: utf-8 -->
<!-- ispell-local-dictionary: "american" -->
<!-- End: -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:11:38 |