One document matched: draft-gerdes-ace-dcaf-authorize-00.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>
<rfc ipr="trust200902" docName="draft-gerdes-ace-dcaf-authorize-00" category="std">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="DCAF">Delegated CoAP Authentication and Authorization Framework (DCAF)</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>
<date year="2014" month="July" day="04"/>
<area>Applications</area>
<workgroup>ACE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This specification defines a protocol for delegating client
authentication and authorization in a constrained environment for
establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes.
The protocol relies on DTLS to
transfer authorization information and shared secrets for symmetric
cryptography between entities in a constrained network. A
resource-constrained node can use this protocol to delegate
authentication of communication peers and 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>The Constrained Application Protocol (CoAP) <xref target="RFC7252"/> is
a transfer protocol similar to HTTP which is designed for the special
requirements of constrained environments. A serious problem with
constrained devices is the realization of secure communication. The
devices only have limited resources such as memory, stable storage (such as disk space) and
transmission capacity and often lack input/output devices such as
keyboards or displays. Therefore, they are not readily capable of
using common protocols. Especially authentication mechanisms are
difficult to realize, because the lack of stable storage severely limits
the number of keys the system can store. Moreover, CoAP has no mechanism to
distinguish access rights for different clients (authorization).</t>
<t>The DCAF architecture is designed to relieve the constrained nodes
from managing keys for numerous devices by introducing authorization
servers which conduct the authentication and authorization for their
nodes. To achieve this, access tokens are used. A device which
wants to access a constrained node’s resource first has to gain
permission in the form of a token from the node’s authorization
server.</t>
<t>As fine-grained authorization is not always needed on constrained
devices, DCAF supports an implicit authorization mode where no
authorization information is exchanged.</t>
<!-- Note: DCAF's goal is to provide access control to a resource of a
constrained device. If the access to a resource is restricted somehow,
either by granting access rights to all authenticated clients or by a
more sophisticated authorization approach, it is necessary to be able
to doubtlessly verify the client's claim. To ensure the security of the
authorization information it is beneficial to intertwine
authentication and authorization mechanism. -->
<t>The main goals of DCAF are the setup of a Datagram Transport Layer
Security (DTLS) <xref target="RFC6347"/> channel with symmetric pre-shared
keys (PSK) <xref target="RFC4279"/> and to
securely transmit authorization tickets.</t>
<section anchor="features" title="Features">
<t><list style="symbols">
<t>Utilize DTLS communication with pre-shared keys.</t>
<t>Authenticated exchange of authorization information.</t>
<t>Simplified authentication on constrained nodes by handing the more
sophisticated authentication over to less-constrained devices.</t>
<t>Simplified authorization mechanism for cases where implicit
authorization is sufficient.</t>
<t>Using only symmetric encryption on constrained nodes.</t>
</list></t>
<!-- Kerberos: RFC4120: -->
</section>
<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>
<section anchor="roles" title="Roles">
<t>Resource Server (RS): A constrained device that hosts resources the Client wants to access.</t>
<t>Client (C): A device that wants to access resources on the Resource Server.</t>
<t>Authorization Server (AS): The node that conducts authentication and authorization for a Resource Server. An Authorization Server can be responsible for a single or multiple devices or even for a whole network. A Resource Server can have multiple Authorization Servers.</t>
<t>Authentication Manager (AM): The node that conducts authentication
on behalf of the Client.</t>
<t>Resource Owner: The principal that owns the resource and controls its access permissions.</t>
</section>
<section anchor="other-terms" title="Other Terms">
<t>Access ticket: Contains the authentication and, if necessary, the
authorization information needed to access a resource. A Ticket consists
of the Ticket Face and the Ticket Verifier</t>
<t>Authorization information: Contains all information needed by RS to
decide if C is privileged to access a resource in a specific way.</t>
<t>Authentication information: Contains all information needed by RS to
decide if the entity in possession of a certain key is verified by the
authorization server.</t>
<t>Access information: Contains authentication information and, if
necessary, authorization information. <!-- FIXME: Difference to Access Ticket? --></t>
<t>Ticket Face: The part of the ticket which is generated for the
Resource Server. It contains the authorization information and all
information needed by the Resource Server to verify that it was
granted by AS.</t>
<t>Ticket Verifier: The part of the ticket which is generated for the
Client. It enables the client to verify that it is communicating with
an appropriate RS.</t>
<t>Explicit authorization: The Authorization Server informs the Resource
Server in detail which privileges are granted to the Client.</t>
<t>Implicit authorization: The Authorization Server informs the Resource
Server that the Client is authorized to access any resource on RS in
any way, without specifying the
privileges in detail.</t>
<!-- TODO: It might be useful if RS can have own authorization
information. Maybe a simple set of fallback-information when no AS is
available or more sophisticated ai if RS is not quite so
constrained. -->
</section>
</section>
</section>
<section anchor="system-overview" title="System Overview">
<t>Within the DCAF Architecture each Resource Server (RS) has one or more
Authorization Servers (AS) which conduct the authentication and
authorization for RS. RS and AS share a symmetric key
which has to be exchanged initially to provide for a secure
channel. The mechanism used for this is not in the scope of this
document.</t>
<t>To gain access to a specific resource on a Resource Server, a
client (C) has to request an access ticket from one of the
Authorization Servers serving RS either directly or, if it is a constrained
device, using its Authentication Manager (AM).
In the following, we always discuss the AM role separately, even if that is
co-located within a (more powerful) C.</t>
<t>If AS decides that C is allowed to access the resource, it generates a
DTLS pre-shared key (PSK) for the communication between C and RS and
wraps it into an access ticket. For explicit access control,
AS adds the detailed access permissions to the ticket in a way that RS
can interpret. After
presenting the ticket to RS, C and RS can communicate securely.</t>
<t>To be able to provide for the authentication and authorization
services, the Authorization Servers have to fulfill several
requirements:</t>
<t><list style="symbols">
<t>An AS must have enough stable storage (such as disk space) to store
the necessary number of credentials (matching the number of clients
and Resource Servers).</t>
<t>An AS must possess means for user interaction, for example directly
or indirectly connected input/output devices like keyboard and
display, to allow for configuration of authorization information by
the Resource Owner.</t>
<t>An AS must have enough processing power to handle the authorization
requests for all RS devices it is responsible for.</t>
</list></t>
<!-- *TODO: Requirements from {{draft-seitz-core-sec-usecases}}* -->
<!-- *TODO: Scalability* -->
<!-- *TODO: Does this architecture generate more traffic than direct authentication with the client?* -->
</section>
<section anchor="protocol" title="Protocol">
<t>The DCAF protocol comprises three parts:</t>
<t><list style="numbers">
<t>transfer of authentication and, if necessary, authorization
information between C and RS;</t>
<t>transfer of access requests and the
respective ticket grants between C and AM; and</t>
<t>transfer of access requests and the
respective ticket grants between AS and AM.</t>
</list></t>
<!-- In most network topologies, at least two of the three sub-protocols -->
<!-- will be present, depending on the actual roles that each device -->
<!-- impersonates. In simple scenarios, AS(C) and AS(RS) might be -->
<!-- identical, i.e. C and RS use the same authorization server. In this -->
<!-- case, no AS-to-AS communication is required. Moreover, if C is capable -->
<!-- of mutual authentication with AS(RS), it could act as AS(C). -->
<section anchor="overview" title="Overview">
<t>In <xref target="protocol-overview"/>, a DCAF protocol flow is depicted (messages
in square brackets are optional):</t>
<figure title="Protocol Overview" anchor="protocol-overview"><artwork><![CDATA[
AM C RS AS
| <== DTLS chan. ==> | | <== DTLS chan. ==> |
| | [Resource Req.-->] | |
| | | |
| | [<-- AS Info.] | |
| | | |
| <-- Access Req. | | |
| | | |
| <===== TLS/DTLS channel (AM/AS Mutual Authentication) =====> |
| | | |
| Ticket Request ------------------------------------------> |
| | | |
| <------------------------------------------ Ticket Grant |
| | | |
| Ticket Transf. --> | | |
| | | |
| | <== DTLS chan. ==> | |
| | Auth. Res. Req. -> | |
]]></artwork></figure>
<t>To determine the Authorization Server in charge of a resource
hosted at the Resource Server (RS), the Client (C) MAY send an initial
Unauthorized Resource Request message to RS.
RS then denies the request and sends the address of its Authorization
Server (AS) back to the Client.</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"/>) that
lists RS’s resources as discussed in <xref target="rd"/>.</t>
<t>Once C knows AS’ address, it can
send a request for authorization to AS using its own Authentication
Manager (AM). AS authenticates AM, who serves as a trusted introducer
for C, and decides if C
is allowed to communicate with RS and access the requested resource.
If it is, AS
generates an access ticket for C. The ticket contains keying material
for the establishment of a secure channel and, if necessary, a
representation of the permissions C has for the resource.
C keeps one part of the access ticket and presents the other part
to RS to prove its right to access. With their respective
parts of the ticket, C and RS are able to establish
a secure channel.</t>
<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 simultaneously convey
authorization information specific for this communication relationship
to RS.</t>
<t><list style="hanging">
<t hangText='Note:'>
Special implementation considerations apply when one single entity
takes the role of more than one actors. <xref target="combined"/> gives
additional advice on some of these usage scenarios.</t>
</list></t>
<t>This document uses Concise Binary Object Representation (CBOR, <xref target="RFC7049"/>) to
express authorization information as set of attributes passed in CoAP
payloads. Notation and encoding options are discussed in
<xref target="payload-format"/>.</t>
</section>
<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 as Unauthorized Resource Request message when any of the
following holds:</t>
<t><list style="symbols">
<t>The request has been received on an insecure channel.</t>
<t>RS has no valid access information for the sender of the
request regarding the requested action on that resource.</t>
<t>RS has valid access information 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.</t>
<t>Unauthorized Resource Request messages MUST be denied with a client error
response. In this response, the Resource Server MUST provide
proper AS Information to enable the Client to request an
access ticket 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 ticket for C. If RS has authorization
information for C but not for the resource that C has requested, RS
MUST reject the request with a 4.03 (Forbidden). If RS has
authorization information for C but they do 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 the 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 Message">
<t>The AS Information Message 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 Authorization Server. The AS
information is a set of attributes containing an absolute URI (see Section 4.3 of <xref target="RFC3986"/>) that specifies the
Authorization Server in charge of RS.</t>
<t>The message MAY also contain a timestamp generated by RS. <!-- (RS wants either his own timestamp or a timestamp generated by AS(RS) back in the end to make sure the information it gets is fresh)--></t>
<t><xref target="as-info-payload"/> shows an example for an AS Information message
payload using CBOR diagnostic notation. (Refer to <xref target="payload-format"/> for a detailed
description of the available attributes and their semantics.)</t>
<figure title="AS Information Payload Example" anchor="as-info-payload"><artwork><![CDATA[
4.01 Unauthorized
Content-Format: application/dcaf+cbor
{AS: "coaps://as-rs.example.com/authorize", TS: 168537}
]]></artwork></figure>
<t>In this example, the attribute AS points the receiver of this message
to the URI “coaps://as-rs.example.com/authorize” 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 time stamp on its own time
scale that is used as a nonce for replay attack prevention. Refer
to <xref target="face"/> for more details concerning the usage of time stamps to
ensure freshness of access tickets.</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 Payload Example encoded in CBOR" anchor="as-info-cbor"><artwork><![CDATA[
a2 # map(2)
00 # unsigned(0) (=AS)
78 23 # text(35)
636f6170733a2f2f61732d72732e6578
616d706c652e636f6d2f617574686f72
697a65 # "coaps://as-rs.example.com/authorize"
05 # unsigned(5) (=TS)
1a 00029259 # unsigned(168537)
]]></artwork></figure>
</section>
<section anchor="access-request" title="Access Request">
<t>To retrieve an access ticket for the resource that C wants to
access, C sends an Access Request to its authentication manager
AM. The Access Request is constructed as follows:</t>
<t><list style="numbers">
<t>The request method is POST.</t>
<t>The request URI is set as described below.</t>
<t>The message payload contains a data structure that describes the
action and resource for which C requests an access ticket.</t>
</list></t>
<t>The request URI identifies a resource at AM for handling
authorization requests from C. The URI SHOULD be announced by AM in
its resource directory as described in <xref target="rd"/>.</t>
<t><list style="hanging">
<t hangText='Note:'>
Where capacity limitations of C do not allow for resource directory
lookups, the request URI in Access Requests could be
hard-coded during provisioning or set in a specific device
configuration profile.</t>
</list></t>
<t>The message payload is constructed from the AS information
that RS has returned in its AS Information message (see
<xref target="as-info"/>) and information that C provides to describe its intended
request(s). The
Access Request MUST contain the following attributes:</t>
<t><list style="numbers">
<t>Contact information for the AS to use.
<!-- 1. An identifier of C that can be used by AS to distinguish Access Requests from different Clients. --></t>
<t>An absolute URI of the resource that C wants to access.</t>
<t>The actions that C wants to perform on the resource.
<!-- Can we omit the actions if they are not needed? Maybe
not, C cannot know if RS needs them or not. They would have to
negotiate that --></t>
<t>Any time stamp generated by RS.</t>
</list></t>
<t>An example Access Request from C to AM is depicted in
<xref target="authorization-message-example"/>. (Refer to <xref target="payload-format"/> for a detailed
description of the available attributes and their semantics.)</t>
<figure title="Access Request Message Example" anchor="authorization-message-example"><artwork><![CDATA[
POST client-authorize
Content-Format: application/dcaf+cbor
{
AS: "coaps://as-rs.example.com/authorize",
AI: ["coaps://temp451.example.com/s/tempC", 5],
TS: 168537
}
]]></artwork></figure>
<t>The example shows an Access Request message payload for the resource
“/s/tempC” on the Resource Server “temp451.example.com”. Requested operations in
attribute AR are GET and PUT.</t>
<t>The attributes AS (that denotes the Authorization Server to use) and
TS (a nonce generated by RS) are taken from the AS Information
message from RS.</t>
<t>The response to an Authorization Request is delivered by AM back to
C in a Ticket Transfer message.</t>
</section>
<section anchor="ticket-req" title="Ticket Request Message">
<t>When AM receives an Access Request message from C it MAY
return a cached response if it is known to be fresh. Otherwise, it
checks whether the request payload is of type “application/dcaf+cbor
and contains at least the fields AS and AI. AM MUST respond
with 4.00 (Bad Request) if the type is “application/dcaf+cbor and any
of these fields is missing or does not conform to the format described
in <xref target="payload-format"/>. Content formats other than
application/dcaf+cbor are out of scope of this specification.</t>
<t>When the payload is correct, AM creates a Ticket Request message
from the Access Request received from C as follows:</t>
<t><list style="numbers">
<t>The destination of the Ticket Request message is derived from the
authority information in the URI contained in field “AS” of the
Access Request message payload.</t>
<t>The request method is POST.</t>
<t>The request URI is constructed from the AS field received in the
Access Request message payload.</t>
<t>The payload is copied from the Access Request sent by C.</t>
<t>A label that describes the Client is added to the payload</t>
</list></t>
<t>To send the Ticket Request message to AS
a secure channel between AM
and AS MUST be used. Depending on the URI scheme used in the
AS field of the Access Request message payload (the less-constrained
devices AM and AS do not necessarily use coap to communicate with each
other), this could be,
e.g., a DTLS channel (for “coaps”) or a TLS connection (for
“https”). AM and AS MUST be able to mutually authenticate each other,
e.g. based on a public key infrastructure. (Refer to <xref target="trust"/> for a detailed
discussion of the trust relationship between authentication managers
and authorization servers.)</t>
<t>The descriptive label of C included in the Ticket Request is used to
distinguish the clients within AS’s namespace and MUST NOT be used for
authenticating the client.</t>
</section>
<section anchor="ticket-grant-message" title="Ticket Grant Message">
<t>When AS has received a Ticket Request message it has to evaluate
the access request information contained therein. First, it
checks whether the request payload is of type “application/dcaf+cbor”
and contains at least the fields AS, D, and AI. AS MUST respond
with 4.00 (Bad Request) for CoAP (or 400 for HTTP) if the type is “application/dcaf+cbor” and any
of these fields is missing or does not conform to the format described
in <xref target="payload-format"/>.
<!--
Don't we need a more general description here? We want to be able to
support other methods beside json. AS must check if the request
message contains all mandatory information depicted in {{ticket-req}}
(i.e. the contact information for AS (is it even meant for this AS?,
an identifier of C, the absolute URI of the resource and the actions C
wants to perform on the resource.
--></t>
<t>AS decides whether or not access is granted to the requested
resource and then creates a Ticket Grant message that reflects the
result.
To grant access to the requested resource, AS creates an
access ticket comprised of a Face and a Verifier as described in
<xref target="face"/>.</t>
<t>The Ticket Grant message then is constructed as a success response
indicating attached content, i.e. 2.05 for CoAP, or 200 for HTTP,
respectively. The payload of the Ticket Grant message is a data
structure that contains the result of the access request. When
access is granted, the data structure contains the
ticket’s Face, the Verifier and the Session Key Generation Method.</t>
<t>The Ticket Grant message MAY provide cache-control options to enable
intermediaries to cache the response. The message MAY be cached
according to the rules defined in <xref target="RFC7252"/> to facilitate
ticket retrieval when C has crashed and wants to recover the DTLS
session with RS.
<!-- Check that this stuff actually is cache-able. --></t>
<t>AS sets Max-Age according to the ticket lifetime in its response
(Ticket Grant Message).</t>
<t><xref target="ticket-grant"/> shows an example Ticket Grant message using CoAP. The
Face/Verifier information is transferred as a CBOR data structure as
specified in <xref target="payload-format"/>. The Max-Age option tells the
receiving AM how long this ticket will be valid.</t>
<figure title="Example Ticket Grant Message" anchor="ticket-grant"><artwork><![CDATA[
2.05 Content
Content-Format: application/dcaf+cbor
Max-Age: 86400
{ F: {
AI: [ "/s/tempC", 7 ],
D: "2001:db8:ab9:1234:7920:3133:ae5f:87",
TS: 0("2013-07-10T10:04:12.391"),
L: 86400,
G: hmac_sha256
},
V: h'b2dd4e409c2d36a7423da3c87e571999
0b778ebd2c7d3730729a7fcde26c7201'
}
]]></artwork></figure>
<t>A Ticket Grant message that declines any operation on the requested
resource is illustrated in <xref target="ticket-reject"/>. As no ticket needs
to be issued, an empty payload is included with the response.</t>
<figure title="Example Ticket Grant Message With Reject" anchor="ticket-reject"><artwork><![CDATA[
2.05 Content
Content-Format: application/dcaf+cbor
]]></artwork></figure>
</section>
<section anchor="ticket-transfer" title="Ticket Transfer Message">
<t>A Ticket Transfer message delivers the access information
sent by AS in a Ticket Grant message to the requesting client C.
The Ticket Transfer message is the response to
the Access Request message sent from C to AM
and includes any access information from AS contained in the
Ticket Grant message.</t>
</section>
<section anchor="dtls-channel" title="DTLS Channel Setup Between C and RS">
<t>Using the information contained in a positive response to its
Access Request (i.e. a Ticket Transfer message that contains
a Face and a Verifier), 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"/>, with the
following additional requirements:</t>
<t><list style="numbers">
<t>C sets the psk_identity field of the ClientKeyExchange message
to the ticket Face received in the Ticket Transfer message.</t>
<t>C uses the ticket Verifier as PSK when constructing the premaster
secret.</t>
</list></t>
<t>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>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>
<t>Note3: The ticket is constructed by AS such that RS can derive the
authorization information as well as the PSK (refer to
<xref target="key-generation"/> for details).</t>
</section>
<section anchor="authorized-rreq" title="Authorized Resource Request Message">
<t>Successful establishment of the DTLS channel between C and RS ties the
authorization information contained in the psk_identity field to this
channel. Any request that RS receives on this channel is checked
against these authorization rules. Incoming CoAP requests that are not
Authorized Resource Requests MUST be rejected by RS with 4.01
response as described in <xref target="rreq"/>.</t>
<t>RS SHOULD treat an incoming CoAP request as Authorized Resource
Request 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 <xref target="dtls-channel"/>.</t>
<t>The authorization information tied to the secure channel 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>Note that the authorization information is not restricted to a single
resource URI. For example, role-based authorization can be used to
authorize a collection of semantically connected resources
simultaneously. Implicit authorization also provides access rights
to authenticated clients for all actions on all resources that RS
offers. As a result, C can use the same DTLS channel not only
for subsequent requests for the same resource (e.g. for block-wise
transfer as defined in <xref target="I-D.ietf-core-block"/> or refreshing
observe-relationships <xref target="I-D.ietf-core-observe"/>) but also for requests
to distinct resources.</t>
<t>Incoming CoAP requests received on a secure channel according to the
procedure defined in <xref target="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>Since AS may limit the set of requested actions in its Ticket Grant
message, C cannot know a priori if an Authorized Resource Request
will succeed.</t>
</section>
<section anchor="update" title="Dynamic Update of Authorization Information">
<t>Once a security association exists between a Client and a Resource
Server, the Client can update the Authorization Information stored at
the Resource Server at any time. To do so, the Client creates a new
Access Request for the intended action on the respective resource and
sends this request to its Authentication Manager which relays this
request to the Resource Server’s Authorization Server as described in
<xref target="access-request"/>.</t>
<t><list style="hanging">
<t hangText='Note:'>
Requesting a new Access Ticket also can be a Client’s reaction on a
4.03 or 4.05 error that it has received in response to an Authorized
Resource Request.</t>
</list></t>
<t><xref target="update-overview"/> depicts the message flow where C requests a new
Access Tickets 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[
AM C RS AS
| <== DTLS chan. ==> | <== DTLS chan. ==> | <== DTLS chan. ==> |
| | | |
| | [Unauth. R. Req->] | |
| | [<- 4.0x+AS Info.] | |
| | | |
| <-- Access Req. | | |
| | | |
| <===== TLS/DTLS channel (AM/AS Mutual Authentication) =====> |
| | | |
| Ticket Request ------------------------------------------> |
| | | |
| <------------------------------------------ Ticket Grant |
| | | |
| Ticket Transf. --> | | |
| | | |
| | <== Update AI ===> | |
]]></artwork></figure>
<t>Processing the Ticket Request is done at the Authorization Server as
specified in <xref target="ticket-grant-message"/>, i.e. the AS checks
whether or not the requested operation is permitted by the Resource
Owner’s policy, and then return a Ticket Grant message with the result
of this check. If access is granted, the Ticket Grant message contains
an Access Ticket comprised of a public Ticket Face and a private
Ticket Verifier. This authorization payload is relayed by the
Authorization Manager to the Client in a Ticket Transfer Message
as defined in <xref target="ticket-transfer"/>.</t>
<t>The major difference between dynamic update of Authorization
Information and the initial handshake is the handling of a Ticket
Transfer message by the Client that is described in <xref target="ticket-handle"/>.</t>
<section anchor="ticket-handle" title="Handling of Ticket Transfer Messages">
<t>If the security association with RS still exists and RS
has indicated support for session renegotiation according to
<xref target="RFC5746"/>, the ticket Face SHOULD be used to renegotiate the
existing DTLS session. In this case, the ticket Face is used as
psk_identity as defined in <xref target="dtls-channel"/>. Otherwise, the Client
MUST perform a new DTLS handshake according to <xref target="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 contents of
the ticket Face.</t>
<t><list style="hanging">
<t hangText='Note:'>
No mutual authentication between C and RS is required for dynamic
updates when a DTLS channel exists that has been established as
defined in <xref target="dtls-channel"/>. RS only needs to verify the
authenticity and integrity of the ticket Face issued by AS which is
achieved by having performed a successful DTLS handshake with the
ticket Face as psk_identity. This could even be done within the
existing DTLS session by tunneling a CoDTLS
<xref target="I-D.schmertmann-dice-codtls"/> handshake.</t>
</list></t>
</section>
</section>
</section>
<section anchor="ticket" title="Ticket">
<t>Access tokens in DCAF are tickets that
consist of two parts, namely the Face and the Verifier.
The Face goes to RS, the Verifier goes to the Client. The Face and the
Verifier are parts of the same ticket.</t>
<t>RS only needs the information contained in the Ticket Face to authorize the
client and make sure that AS generated the Ticket Face (RS cannot
make authorization decisions by itself and hence needs AS to do it). No
additional information about the Client is needed. RS keeps the Ticket
Face as long as it is valid.</t>
<section anchor="face" title="Face">
<t>Face is the part of the ticket generated for RS. Face MUST contain all
information needed for authorized access to a resource:</t>
<t><list style="symbols">
<t>Authorization Information</t>
<t>Descriptive label</t>
<t>A timestamp generated by AS</t>
</list></t>
<t>Optionally, Face MAY also contain:</t>
<t><list style="symbols">
<t>A lifetime (optional)</t>
<t>A DTLS pre-shared key (optional)
<!-- end of list --></t>
</list></t>
<t>RS MUST verify the integrity of Face, i.e. the information contained
in Face stems from AS and was not manipulated by anyone else.</t>
<t>Face MUST contain a timestamp to verify that the contained information
is fresh. As constrained devices may not have a clock, timestamps MAY
be generated using the clock ticks since the last reboot. To
circumvent synchronization problems the timestamp MAY be generated by
RS and included in the first AS Information
message. Alternatively, AS MAY generate the timestamp. In this
case, AS and RS MUST use a time synchronization mechanism to make
sure that RS interprets the timestamp correctly.</t>
<t>Face MAY be encrypted. If Face contains a DTLS PSK, the
whole content of Face MUST be encrypted.</t>
<t>Note: The integrity of Face can be ensured by various means. Face may be
encrypted by AS with a key it shares with RS. Alternatively, RS
can use a mechanism to generate the DTLS PSK which includes Face
and is only able to calculate the correct key with the correct Face
(refer to <xref target="key-generation"/> for details).</t>
</section>
<section anchor="verifier" title="Verifier">
<t>The Verifier part of the ticket is generated for C. It contains the
DTLS PSK for C. The Verifier MUST NOT be transmitted over
insecure channels.</t>
</section>
<section anchor="revocation" title="Revocation">
<t>The existence of access tickets SHOULD be limited in time. <!-- FIXME: say why -->
This can be achieved either by explicit Revocation Messages
to invalidate a ticket or implicitly by attaching a lifetime
to the ticket.</t>
<section anchor="time" title="Lifetime">
<t>Tickets MAY have a lifetime. AS is responsible for defining the
ticket lifetime. If AS sets a lifetime for a ticket, AS and RS
MUST use a time synchronization method to ensure that RS is able to
interpret the lifetime correctly. RS SHOULD end the DTLS connection to
C if the lifetime of a ticket has run out and it MUST NOT accept new
requests. RS MUST NOT accept tickets with an invalid lifetime.</t>
<t>Note: Defining reasonable ticket lifetimes is difficult to
accomplish. How long a client needs to access a resource depends
heavily on the application scenario and may be difficult to decide for
AS.</t>
</section>
<section anchor="revocation-messages" title="Revocation Messages">
<t>AS MAY revoke tickets by sending a ticket revocation message to
RS. If RS receives a ticket revocation message, it MUST end the DTLS
connection to C and MUST NOT accept any further requests from C.</t>
<t>If ticket revocation messages are used, RS MUST check regularly if
AS is still available. If RS cannot contact AS, it MUST end
all DTLS connections and reject any further requests from C.</t>
<t>Note: The loss of the connection between RS and AS prevents all
access to RS. This might especially be a severe problem if AS is
responsible for several Resource Servers or even a whole network.</t>
</section>
</section>
</section>
<section anchor="payload-format" title="Payload Format and Encoding (application/dcaf+cbor)">
<t>Various messages types of the DCAF protocol carry payloads to express
authorization information and parameters for generating the DTLS PSK
to be used by C and RS. In this section, a representation in
Concise Binary Object Representation (CBOR, <xref target="RFC7049"/>) is defined.</t>
<t>DCAF data structures are defined as CBOR maps that contain key value
pairs. For efficient encoding, the keys defined in this document are
represented as unsigned integers in CBOR, i. e. major type 0. For
improved reading, we use symbolic identifiers to represent the
corresponding encoded values as defined in <xref target="cbor-keys"/>.</t>
<texttable title="DCAF field identifiers encoded in CBOR" anchor="cbor-keys">
<ttcol align='left'>Encoded Value</ttcol>
<ttcol align='left'>Key</ttcol>
<c>0b000_00000</c>
<c>AS</c>
<c>0b000_00001</c>
<c>AI</c>
<c>0b000_00010</c>
<c>D</c>
<c>0b000_00011</c>
<c>E</c>
<c>0b000_00100</c>
<c>K</c>
<c>0b000_00101</c>
<c>TS</c>
<c>0b000_00110</c>
<c>L</c>
<c>0b000_00111</c>
<c>G</c>
<c>0b000_01000</c>
<c>F</c>
<c>0b000_01001</c>
<c>V</c>
</texttable>
<t>The following list describes the semantics of the keys defined
in DCAF.</t>
<t><list style="hanging">
<t hangText='AS:'>
Authorization Server. This attribute denotes the authorization
server that is in charge of the resource specified in attribute
R. The attribute’s value is a string that contains an absolute URI
according to Section 4.3 of <xref target="RFC3986"/>.</t>
<t hangText='AI:'>
Authorization Information. A data structure used to convey
authorization information from AS to RS and to describe the
permissions requested from AS in a Ticket Request. The AI attribute
contains an AIF object as defined in <xref target="I-D.bormann-core-ace-aif"/>.</t>
<t hangText='D:'>
Description. A descriptive label of the initiator of the
authorization request. This label MAY be a fully qualified domain
name, an IP address, or any other character literal that is used by
the Authorization Server to decide whether or not access is granted
to the requesting entity.</t>
<t hangText='E:'>
Encrypted Ticket Face. A binary string containing an encrypted ticket Face.</t>
<t hangText='K:'>
Key. A string that identifies the shared key between RS and AS
that can be used to decrypt the contents of E. If the attribute E
is present and no attribute K has been specified, the default is
to use the current session key for the secured channel between RS
and AS.</t>
<t hangText='TS:'>
Time Stamp. An optional time stamp that indicates the instant when
the access ticket request was formed. This attribute can be used by
the resource server in an AS Information message to convey a
time stamp in its local time scale (e.g. when it does not have a
real time clock with synchronized global time). When the attribute’s
value is encoded as a string, it MUST contain a valid UTC timestamp
without time zone information. When encoded as integer, TS contains
a system timestamp relative to the local time scale of its
generator, usually RS.</t>
<t hangText='L:'>
Lifetime. A lifetime of the ticket. When encoded as a string, L MUST
denote the ticket’s expiry time as a valid UTC timestamp without
time zone information. When encoded as an integer, L MUST denote the
ticket’s validity period in seconds relative to TS.</t>
<t hangText='G:'>
DTLS PSK Generation Method. A numeric identifier for the method that
RS MUST use to derive the DTLS PSK from the ticket Face. This
attribute MUST NOT be used when attribute V is present within the
contents of F. This specification uses symbolic identifiers for
improved readability. The corresponding numeric values encoded in
CBOR are defined in <xref target="cbor-g"/>. A registry for these codes is
defined in <xref target="cbor-g-iana"/>.</t>
<t hangText='F:'>
Ticket Face. An object containing the fields AI, D, TS, and optionally
G, L and V.</t>
<t hangText='V:'>
Ticket Verifier. A binary string containing the shared secret between C and
RS.</t>
</list></t>
<texttable title="CBOR encoding for DTLS PSK Key Generation Methods" anchor="cbor-g">
<ttcol align='left'>Encoded Value</ttcol>
<ttcol align='left'>Mnemonic</ttcol>
<ttcol align='left'>Support</ttcol>
<c>0b000_00000</c>
<c>hmac_sha256</c>
<c>mandatory</c>
<c>0b000_00001</c>
<c>hmac_sha384</c>
<c>optional</c>
<c>0b000_00010</c>
<c>hmac_sha512</c>
<c>optional</c>
</texttable>
<section anchor="examples" title="Examples">
<t>The following example specifies an Authorization Server that will be
accessed using HTTP over TLS. The request URI is set to
“/a?ep=%5B2001:DB8::dcaf:1234%5D” (hence denoting the endpoint address
to authorize). TS denotes a local timestamp in UTC.</t>
<figure><artwork><![CDATA[
POST /a?ep=%5B2001:DB8::dcaf:1234%5D HTTP/1.1
Host: as-rs.example.com
Content-Type: application/dcaf+cbor
{AS: "https://as-rs.example.com/a?ep=%5B2001:DB8::dcaf:1234%5D",
D: "2001:DB8::dcaf:1234",
AI: ["coaps://temp451.example.com/s/tempC", 1],
TS: 0("2013-07-14T11:58:22.923")}
]]></artwork></figure>
<t>The following example shows a ticket for the distributed key
generation method (cf. <xref target="key-derivation"/>), comprised of a Face (F)
and a Verifier (V). The Face data structure contains authorization
information AI, a client
descriptor, a timestamp using the local time scale of RS, and a
lifetime relative to RS’s time scale.</t>
<t>The DTLS PSK Generation Method is set to hmac_sha256 denoting
that the distributed key derivation is used as defined in
<xref target="key-derivation"/> with SHA-256 as HMAC function.</t>
<t>The Verifier V contains a shared secret to be used as DTLS PSK
between C and RS.</t>
<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/dcaf+cbor
{
F: {
AI: [ "/s/tempC", 1 ],
D: "2001:db8:ab9:1234:7920:3133:ae5f:87",
TS: 2938749,
L: 3600,
G: hmac_sha256
},
V: h'93b9448d4380304d5a574fc50b944958
55bbd5ba1422cc09fde61665aa519cf9'
}
]]></artwork></figure>
<t>The Face may be encrypted as illustrated in the following example.
Here, the field E carries an encrypted Face data structure that
contains the same information as the previous example, and an
additional Verifier. Encryption was done with a secret shared by
AS and RS. (This example uses AES128_CCM with the secret { 0x00,
0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b,
0x0c, 0x0d, 0x0e, 0x0f } and RS’s timestamp { 0x00, 0x2C, 0xD7, 0x7D
} as nonce.) Line breaks have been inserted to improve readability.</t>
<t>The attribute K describes the identity of the key to be used by RS to
decrypt the contents of attribute E. Here, The value “key0” in this
example is used to indicate that the shared session key between RS and
AS was used for encrypting E.</t>
<figure><artwork><![CDATA[
{
E: h'2e1c0c0ae1915711f1073f34e44bfc81
12167f5bdbd8801d07686615b0b434
cdca7a5453d0d582565e2f236948235d
d353cef1114d64d138949f7ab01b92f0
b6f2caccce3a43cb0a32f270a82cde0a
98250e6ac2b79a26fb47c09ef4cb366f
1aa38017cd8b891a6d796fa684294a60
64f3665527c5890b65a33af73a5c66ef
66cbb9e28ea30c89',
K: "key0",
V: h'93b9448d4380304d5a574fc50b944958
55bbd5ba1422cc09fde61665aa519cf9'
}
]]></artwork></figure>
<t>The decrypted contents of E are depicted below (whitespace has been
added to improve readability). The presence of the attribute V
indicates that the DTLS PSK Transfer is used to convey the session key
(cf. <xref target="key-transfer"/>).</t>
<figure><artwork><![CDATA[
{
F: {
AI: [ "/s/tempC", 1 ],
D: "2001:db8:ab9:1234:7920:3133:ae5f:87",
TS: 2938749,
L: 3600,
G: hmac_sha256
},
V: h'93b9448d4380304d5a574fc50b944958
55bbd5ba1422cc09fde61665aa519cf9'
}
]]></artwork></figure>
</section>
</section>
<section anchor="key-generation" title="DTLS PSK Generation Methods">
<t>One goal of the DCAF protocol is to provide for a DTLS PSK shared between C and RS. AS and RS MUST negotiate the method for the DTLS PSK generation.</t>
<section anchor="key-transfer" title="DTLS PSK Transfer">
<t>The DTLS PSK is generated by AS and transmitted to C and RS using a secure channel.</t>
<t>The DTLS PSK transfer method is defined as follows:</t>
<t><list style="symbols">
<t>AS generates the DTLS PSK using an algorithm of its choice</t>
<t>AS MUST include a representation of the DTLS PSK in Face and
encrypt it together with all other information in Face with a key
K(AS,RS) it shares with RS. How AS and RS exchange
K(AS,RS) is not in the scope of this document. AS and RS
MAY use their preshared key as K(AS,RS).</t>
<t>AS MUST include a representation of the DTLS PSK in the Verifier.</t>
<t>As AS and C do not have a shared secret, the Verifier MUST
be transmitted to C using encrypted channels.</t>
<t>RS MUST decrypt Face using K(AS,RS)</t>
</list></t>
</section>
<section anchor="key-derivation" title="Distributed Key Derivation">
<t>AS generates a DTLS PSK for C which is transmitted using a secure channel. RS generates its own version of the DTLS PSK using the information contained in Face (see also <xref target="face"/>).</t>
<t>The distributed key derivation method is defined as follows:</t>
<t><list style="symbols">
<t>AS and RS both generate the DTLS PSK using the information.
included in Face. They use an HMAC algorithm on Face with a shared
key. The result serves as the DTLS PSK. How AS and RS
negotiate the used HMAC algorithm is not in the scope of this
document. They MAY however use the HMAC algorithm they use for their
DTLS connection.</t>
<t>AS MUST include a representation of the DTLS PSK in the Verifier.</t>
<t>As AS and C do not have a shared secret, the Verifier MUST
be transmitted to C using encrypted channels.</t>
<t>AS MUST NOT include a representation of the DTLS PSK in Face.</t>
<t>AS MUST NOT encrypt Face.</t>
</list></t>
</section>
</section>
<section anchor="authorization-configuration" title="Authorization Configuration">
<t>For the protocol defined in this document, proper configuration of
AS is crucial. The principal who owns the resources hosted by RS
(i.e. the Resource Owner) needs to define permissions for the
resources. The data representation of these permissions are not in the
scope of this document.</t>
</section>
<section anchor="trust" title="Trust Relationships">
<t>C trusts AM, and RS trusts AS.
Obviously, AM trusts C with the specific permissions it hands over to
it.
How this trust is established, is not in the scope of this document. It may be achieved by using a bootstrapping mechanism similar to <xref target="bergmann12"/>.</t>
<t>Additionally, AS and AM need to have a trust relationship established. Its establishment is also not in the scope of this document. It fulfills the following conditions:</t>
<t><list style="numbers">
<t>AS has means to authenticate AM (e.g. it has a certificate of AM or a PKI in which AM is included) and vice versa</t>
<t>As far as AS needs to rely on the different clients of AM to
receive different permissions, it can be sure that AM correctly
identifies these clients towards AS and does not leak tickets that have
been generated for a specific client C to another client.</t>
</list></t>
<!-- end of list -->
<!--
* to authorize individual devices, AS MUST be able to identify the devices (resource owner Must name them)
otherwise, AS may rely on AM that the request is allowed
-->
<t>AS trusts C indirectly because it trusts AM and AM vouches for C. The DCAF Protocol does not provide any means for AS to validate that a resource requests stems from C.</t>
<t>C indirectly trusts AS with some potentially confidential information, and that AS
correctly represents RS, because AM trusts AS.</t>
<t>AM trusts RS indirectly because it trusts AS and AS vouches for RS.</t>
<t>C implicitly trusts RS with some potentially confidential information
because it trusts AM and because RS can prove that it shares a key with AS.</t>
<figure><artwork><![CDATA[
AM <--------------------> AS
/|\ /|\
| |
\|/ \|/
C ..................... RS
]]></artwork></figure>
</section>
<section anchor="rd" title="Listing Authorization Server Information in a Resource Directory">
<t>CoAP utilizes the Web Linking format <xref target="RFC5988"/> to facilitate
discovery of services in an M2M environment. <xref target="RFC6690"/> defines
specific link parameters that can be used to describe resources to be
listed in a resource directory <xref target="I-D.ietf-core-resource-directory"/>.</t>
<section anchor="rt-auth-request" title="The “auth-request” Link Relation">
<t>This section defines a resource type “auth-request” that can be used
by clients to retrieve the request URI for a server’s authorization
service. When used with the parameter rt in a web link, “auth-request”
indicates that the corresponding target URI can be used in a POST
message to request authorization for the resource and action that are
described in the request payload.</t>
<t>The Content-Format “application/dcaf+cbor with numeric identifier
TBD1 defined in this specification MAY be used to express
access requests and their responses.</t>
<t>The following example shows the web link used by AM in this
document to relay incoming Authorization Request messages to AS.
(Whitespace is included only for readability.)</t>
<figure><artwork><![CDATA[
<client-authorize>;rt="auth-request";ct=TBD1
;title="Contact Remote Authorization Server"
]]></artwork></figure>
<t>The resource directory that hosts the resource descriptions of RS
could list the following description. In this example, the URI
“ep/node138/a/switch2941” is relative to the resource context
“coaps://as-rs.example.com/”, i.e. the authorization server AS.</t>
<figure><artwork><![CDATA[
<ep/node138/a/switch2941>;rt="auth-request";ct=TBD1;ep="node138"
;title="Request Client Authorization"
;anchor="coaps://as-rs.example.com/"
]]></artwork></figure>
</section>
</section>
<section anchor="examples-1" title="Examples">
<t>This section gives a number of short examples with message flows for
the initial Unauthorized Resource Request and the subsequent retrieval
of a ticket
from AS. The notation here follows the role conventions defined in
<xref target="roles"/>. The payload format is encoded as proposed in
<xref target="payload-format"/>. The IP address of AS is 2001:DB8::1, the IP address
of RS is 2001:DB8::dcaf:1234, and C’s IP address is 2001:DB8::c.</t>
<section anchor="access-granted" title="Access Granted">
<t>This example shows an Unauthorized PUT request from C to RS that is
answered with an AS Information message. C then sends a POST
request to AM with a description of its intended request. AM
forwards this request to AS using CoAP over a DTLS-secured
channel. The response from AS contains an access ticket that is
relayed back to AM.</t>
<figure><artwork><![CDATA[
C --> RS
PUT a/switch2941 [Mid=1234]
Content-Format: application/senml+json
{"e": [{"bv": "1"}]}
C <-- RS
4.01 Unauthorized [Mid=1234]
Content-Format: application/dcaf+cbor
{AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941"}
C --> AM
POST client-authorize [Mid=1235,Token="tok"]
Content-Format: application/dcaf+cbor
{
AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
AI: ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 4]
}
AM --> AS [Mid=23146]
POST ep/node138/a/switch2941
Content-Format: application/dcaf+cbor
{
AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
D: "2001:DB8::c",
AI: ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 4]
}
AM <-- AS
2.05 Content [Mid=23146]
Content-Format: application/dcaf+cbor
{ F: {
AI: ["a/switch2941", 5],
D: "2001:DB8::c",
TS: 0("2013-07-04T20:17:38.002"),
G: hmac_sha256
},
V: h'50f18bf1d6f084eb0fd9d2ee6ec882d8
a87ef66a332c86a45bff8f67fe19bc47'
}
C <-- AM
2.05 Content [Mid=1235,Token="tok"]
Content-Format: application/dcaf+cbor
{ F: {
AI: ["a/switch2941", 5],
D: "2001:DB8::c",
TS: 0("2013-07-04T20:17:38.002"),
G: hmac_sha256
},
V: h'50f18bf1d6f084eb0fd9d2ee6ec882d8
a87ef66a332c86a45bff8f67fe19bc47'
}
C --> RS
ClientHello (TLS_PSK_WITH_AES_128_CCM_8)
C <-- RS
ServerHello (TLS_PSK_WITH_AES_128_CCM_8)
ServerHelloDone
C --> RS
ClientKeyExchange
psk_identity=0x6146a4624149826c612f737769746368
0x323934310561446b323030313a444238
0x3a3a63625453c077323031332d30372d
0x30345432303a31373a33382e30303261
0x476b686d61635f736861323536
(C decodes the contents of V and uses the result as PSK)
ChangeCipherSpec
Finished
(RS calculates PSK from AI, D, TS and its session key
HMAC_sha256(0x6146a4624149826c612f737769746368
0x323934310561446b323030313a444238
0x3a3a63625453c077323031332d30372d
0x30345432303a31373a33382e30303261
0x476b686d61635f736861323536,
0x66736563726574)
= 0x0e70158e...
)
C <-- RS
ChangeCipherSpec
Finished
]]></artwork></figure>
<!-- openssl dgst -sha256 -hmac $(cat secret) -binary <msg >hmac1.txt -->
</section>
<section anchor="access-denied" title="Access Denied">
<t>This example shows a denied Authorization request for the DELETE
operation.</t>
<figure><artwork><![CDATA[
C --> RS
DELETE a/switch2941
C <-- RS
4.01 Unauthorized
Content-Format: application/dcaf+cbor
{AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941"}
C --> AM
POST client-authorize
Content-Format: application/dcaf+cbor
{
AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
AI: ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 8]
}
AM --> AS
POST ep/node138/a/switch2941
Content-Format: application/dcaf+cbor
{
AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
D: "2001:DB8::c",
AI: ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 8]
}
AM <-- AS
2.05 Content
Content-Format: application/dcaf+cbor
C <-- AM
2.05 Content
Content-Format: application/dcaf+cbor
]]></artwork></figure>
</section>
<section anchor="access-restricted" title="Access Restricted">
<t>This example shows a denied Authorization request for the operations
GET, PUT, and DELETE. AS grants access for PUT only.</t>
<figure><artwork><![CDATA[
AM --> AS
POST ep/node138/a/switch2941
Content-Format: application/dcaf+cbor
{
AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
D: "2001:DB8::c",
AI: ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 13]
}
AM <-- AS
2.05 Content
Content-Format: application/dcaf+cbor
{ F: {
AI: ["a/switch2941", 5],
D: "2001:DB8::c",
TS: 0("2013-07-04T21:33:11.930"),
G: hmac_sha256
},
V: h'f5628265ec99349d2b1f3a1020223793
7098512d555f085a775f1ae6a9c66950'
}
]]></artwork></figure>
</section>
<section anchor="implicit-authorization" title="Implicit Authorization">
<t>This example shows an Authorization request using implicit
authorization. AM initially requests the actions GET and POST
on the resource “coaps://[2001:DB8::dcaf:1234]/a/switch2941”.
AS returns a ticket that has no AI field in its ticket Face,
hence implicitly authorizing C.</t>
<figure><artwork><![CDATA[
AM --> AS
POST ep/node138/a/switch2941
Content-Format: application/dcaf+cbor
{
AS: "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
D: "2001:DB8::c",
AI: ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 3]
}
AM <-- AS
2.05 Content
Content-Format: application/dcaf+cbor
{ F: {
D: "2001:DB8::c",
TS: 0("2013-07-16T10:15:43.663"),
G: hmac_sha256
},
V: h'6d30f6162b54cd50c8b7421674d46150
1baba2a34c0a86a7aacc0cfe3c2f2643'
}
]]></artwork></figure>
</section>
</section>
<section anchor="combined" title="Specific Usage Scenarios">
<t>The general DCAF architure outlined in <xref target="overview"/> illustrates the
various actors who participate in the message exchange for
authenticated authorization. The message types defined in this
document cover the most general case where all four actors are
separate entities that may or may not reside on the same device.</t>
<t>Special implementation considerations apply when one single entity
takes the role of more than one actor. This section gives advice on
the most common usage scenarios where the Authentication
Manager and Client, the Authorization Server and Resource Server or
the Authentication Manager and Authorization Server
reside on the same (less-constrained) device and have a means of
secure communication outside the scope of this document.</t>
<section anchor="combined-authentication-manager-and-client" title="Combined Authentication Manager and Client">
<t>When AM and C reside on the same (less-constrained) device, the Access
Request and Ticket Transfer messages can be substituted by other
means of secure communication. <xref target="am-c-combined"/> shows a simplified
message exchange for a combined AM+C device.</t>
<figure title="Combined Authentication Manager and Client" anchor="am-c-combined"><artwork><![CDATA[
AM+C RS AS
| | <== DTLS chan. ==> |
| [Resource Req.-->] | |
| | |
| [<-- AS Info.] | |
| | |
| <==== TLS/DTLS chan. (Mutual Auth) ===> |
| | |
| Ticket Request ---------------------> |
| | |
| <--------------------- Ticket Grant |
| | |
| <== DTLS chan. ==> | |
| Auth. Res. Req. -> | |
]]></artwork></figure>
<section anchor="creating-the-ticket-request-message" title="Creating the Ticket Request Message">
<t>When AM+C receives an AS Information message as a reaction to an
Unauthorized Request message, it creates a Ticket Request message as
follows:</t>
<t><list style="numbers">
<t>The destination of the Ticket Request message is derived from the
authority information in the URI contained in field “AS” of the
AS Information message payload.</t>
<t>The request method is POST.</t>
<t>The request URI is constructed from the AS field received in the
AS Information message payload.</t>
<t>The payload contains the AS field from the AS Information message,
an absolute URI of the resource that AM+C wants to access, the the
actions that AM+C wants to perform on the resource, and any time
stamp generated by RS that was transferred with the AS Information
message.</t>
<t>A label that describes AM+C is added to the payload.</t>
</list></t>
</section>
<section anchor="processing-the-ticket-grant-message" title="Processing the Ticket Grant Message">
<t>Based on the Ticket Grant message, AM+C is able to establish a DTLS
channel with RS. To do so, AM+C sets the psk_identity field of the
DTLS ClientKeyExchange message to the ticket Face received in the
Ticket Grant message and uses the ticket Verifier as PSK when
constructing the premaster secret.</t>
</section>
</section>
<section anchor="combined-authentication-manager-and-authorization-server" title="Combined Authentication Manager and Authorization Server">
<t>In certain scenarios, AM and AS may be combined to a single entity
that knows both, C and RS, and decides if their actions are
authorized. Therefore, no explicit communication between AM and AS is
necessary, resulting in omission of the Ticket Request and Ticket
Grant messages. <xref target="am-as-combined"/> depicts the resulting message
sequence in this simplified architecture.</t>
<figure title="Combined Authentication Manager and Authorization Server" anchor="am-as-combined"><artwork><![CDATA[
C AM+AS RS
| <== DTLS chan. ==> | <== DTLS chan. ==> |
| | |
| [Resource Req.----------------------->] |
| | |
| [<--------------------- AS Information] |
| | |
| Access Request --> | |
| | |
| <-- Ticket Transf. | |
| | |
| <=========== DTLS channel ===========> |
| | |
| Authorized Resource Request ----------> |
]]></artwork></figure>
<section anchor="processing-the-access-request-message" title="Processing the Access Request Message">
<t>When receiving an Access Request message, AM+AS performs the checks
specified in <xref target="ticket-req"/> and returns a 4.00 (Bad Request) response
in case of failure. Otherwise, if the checks have succeeded, AM+AS
evaluates the contents of Access Request message as described in
<xref target="ticket-grant-message"/>.</t>
<t>The decision on the access request is performed by AM+AS with respect
to the stored policies. When the requested action is permitted on the
respective resource, AM+AS generates an access ticket as outlined in
<xref target="face"/> and creates a Ticket Transfer message to convey the access
ticket to the Client.</t>
</section>
<section anchor="creating-the-ticket-transfer-message" title="Creating the Ticket Transfer Message">
<t>A Ticket Transfer message is constructed as a 2.05 response with the
access ticket contained in its payload. The response MAY contain a
Max-Age option to indicate the ticket’s lifetime to the receiving
Client.</t>
<t>This specification defines a CBOR data representation for the access
ticket as illustrated in <xref target="ticket-grant-message"/>.</t>
</section>
</section>
<section anchor="combined-authorization-server-and-resource-server" title="Combined Authorization Server and Resource Server">
<t>If AS and RS are colocated in one entity (AS+RS), the main objective is to
allow AM to delegate access to C. Accordingly, the authorization
information could be replaced by a nonce internal to AS+RS. (TBD.)</t>
<figure title="Combined Authorization Server and Resource Server" anchor="as-rs-combined"><artwork><![CDATA[
AM C AS+RS
| <== DTLS chan. ==> | |
| | [Resource Req.-->] |
| | |
| | [<-- AS Info.] |
| | |
| <-- Access Req. | |
| | |
| <========= TLS/DTLS channel =========> |
| | |
| Ticket Request ---------------------> |
| | |
| <--------------------- Ticket Grant |
| | |
| Ticket Transf. --> | |
| | |
| | <== DTLS chan. ==> |
| | Auth. Res. Req. -> |
]]></artwork></figure>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>As this protocol builds on transitive trust between authorization
servers as mentioned in <xref target="trust"/>, AS has no direct means to validate
that a resource request originates from C. It has to trust AM that it
correctly vouches for C and that it does not give authorization tickets meant for C to another client nor disclose the contained session key.</t>
<t>The Authorization Server also could constitute a single point of failure.
If the Authorization Server fails, the resources on all Resource
Servers it is responsible for cannot be accessed any more. Thus,
it is crucial for large networks to use Authorization Servers in a redundant setup.</t>
<!-- As already mentioned in {{trust}}, AS(RS) has no means to validate that a resource request really stems from C. It has to trust AS(C) that it really is responsible for C and that it does not give authorization tickets meant for C to another client. -->
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>The following registrations are done following the procedure specified
in <xref target="RFC6838"/>.</t>
<t>Note to RFC Editor: Please replace all occurrences of “&SELF;” with
the RFC number of this specification.</t>
<section anchor="cbor-g-iana" title="DTLS PSK Key Generation Methods">
<t>A sub-registry for the values indicating the PSK key generation method
as contents of the field G in a payload of type application/dcaf+cbor
is defined. Values in this sub-registry are numeric integers encoded
in Concise Binary Object Notation (CBOR, <xref target="RFC7049"/>). This document
follows the notation of <xref target="RFC7049"/> for binary values, i.e. a number
starts with the prefix “0b”. The major type is separated from the actual
numeric value by an underscore to emphasize the value’s internal
structure.</t>
<t>Initial entries in this sub-registry are as follows:</t>
<texttable title="DTLS PSK Key Generation Methods" anchor="iana-g">
<ttcol align='left'>Encoded Value</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0b000_00000</c>
<c>hmac_sha256</c>
<c>&SELF;</c>
<c>0b000_00001</c>
<c>hmac_sha384</c>
<c>&SELF;</c>
<c>0b000_00010</c>
<c>hmac_sha512</c>
<c>&SELF;</c>
</texttable>
<t>New methods can be added to this
registry based on designated expert review according to <xref target="RFC5226"/>.</t>
<t>(TBD: criteria for expert review.)</t>
</section>
<section anchor="mt" title="dcaf+cbor Media Type Registration">
<t>Type name: application</t>
<t>Subtype name: dcaf+cbor</t>
<t>Required parameters: none</t>
<t>Optional parameters: none</t>
<t>Encoding considerations: Must be encoded as using a subset of the
encoding allowed in <xref target="RFC7049"/>. Specifically, only the primitive data
types String and Number are allowed. The type Number is restricted to
unsigned integers (i.e., no negative numbers, fractions or exponents are allowed).
Encoding MUST be UTF-8. These restrictions simplify implementations on
devices that have very limited memory capacity.</t>
<t>Security considerations: TBD</t>
<t>Interoperability considerations: TBD</t>
<t>Published specification: &SELF;</t>
<t>Applications that use this media type: TBD</t>
<t>Additional information:</t>
<t>Magic number(s): none</t>
<t>File extension(s): dcaf</t>
<t>Macintosh file type code(s): none</t>
<t>Person & email address to contact for further information: TBD</t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: None</t>
<t>Author: TBD</t>
<t>Change controller: IESG</t>
</section>
<section anchor="coap-content-format-registration" title="CoAP Content Format Registration">
<t>This document specifies a new media type application/dcaf+cbor
(cf. <xref target="mt"/>). For use with CoAP, a numeric Content-Format identifier
is to be registered in the “CoAP Content-Formats” sub-registry within
the “CoRE Parameters” registry.</t>
<t>Note to RFC Editor: Please replace all occurrences of “RFC-XXXX” with
the RFC number of this specification.</t>
<texttable>
<ttcol align='right'>Media type</ttcol>
<ttcol align='left'>Encoding</ttcol>
<ttcol align='left'>Id.</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>application/dcaf+cbor</c>
<c>-</c>
<c>TBD1</c>
<c>&SELF;</c>
</texttable>
<!-- LocalWords: Datagram CoAP CoRE DTLS DCAF DCAF's introducer URI
-->
<!-- LocalWords: namespace Verifier JSON timestamp timestamps PSK
-->
<!-- LocalWords: decrypt UTC decrypted whitespace preshared HMAC
-->
</section>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<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. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<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.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='214067' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='RFC4279'>
<front>
<title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)</title>
<author initials='P.' surname='Eronen' fullname='P. Eronen'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<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' />
<format type='TXT' octets='32160' target='http://www.rfc-editor.org/rfc/rfc4279.txt' />
</reference>
<reference anchor='RFC6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'>
<organization /></author>
<date year='2013' month='January' />
<abstract>
<t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t></abstract></front>
<seriesInfo name='BCP' value='13' />
<seriesInfo name='RFC' value='6838' />
<format type='TXT' octets='72942' target='http://www.rfc-editor.org/rfc/rfc6838.txt' />
</reference>
<reference anchor='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' />
<format type='TXT' octets='33790' target='http://www.rfc-editor.org/rfc/rfc5746.txt' />
</reference>
<reference anchor='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' />
<format type='TXT' octets='73546' target='http://www.rfc-editor.org/rfc/rfc6347.txt' />
</reference>
<reference anchor='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' />
<format type='TXT' octets='134062' target='http://www.rfc-editor.org/rfc/rfc7049.txt' />
</reference>
<reference anchor='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' />
<format type='TXT' octets='258789' target='http://www.rfc-editor.org/rfc/rfc7252.txt' />
</reference>
<reference anchor='RFC5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. 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='26' />
<seriesInfo name='RFC' value='5226' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC5988'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
<organization /></author>
<date year='2010' month='October' />
<abstract>
<t>This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5988' />
<format type='TXT' octets='46834' target='http://www.rfc-editor.org/rfc/rfc5988.txt' />
</reference>
<reference anchor='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' />
<format type='TXT' octets='17052' target='http://www.rfc-editor.org/rfc/rfc6655.txt' />
</reference>
<reference anchor='RFC6690'>
<front>
<title>Constrained RESTful Environments (CoRE) Link Format</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'>
<organization /></author>
<date year='2012' month='August' />
<abstract>
<t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6690' />
<format type='TXT' octets='47720' target='http://www.rfc-editor.org/rfc/rfc6690.txt' />
</reference>
<reference anchor="bergmann12" >
<front>
<title>Secure Bootstrapping of Nodes in a CoAP Network</title>
<author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
<organization></organization>
</author>
<author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
<organization></organization>
</author>
<author initials="S." surname="Schaefer" fullname="Silke Schaefer">
<organization></organization>
</author>
<author initials="F." surname="Junge" fullname="Florian Junge">
<organization></organization>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization></organization>
</author>
<date year="2012" month="April"/>
</front>
<seriesInfo name="IEEE" value="Wireless Communications and Networking Conference Workshops (WCNCW)"/>
</reference>
<reference anchor='I-D.ietf-core-block'>
<front>
<title>Blockwise transfers in CoAP</title>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
<organization />
</author>
<date month='July' day='04' year='2014' />
<abstract><t>CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-core-block-15' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-block-15.txt' />
</reference>
<reference anchor='I-D.ietf-core-observe'>
<front>
<title>Observing Resources in CoAP</title>
<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
<organization />
</author>
<date month='June' day='30' year='2014' />
<abstract><t>CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best- effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-core-observe-14' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-observe-14.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='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<author initials='S' surname='Krco' fullname='Srdjan Krco'>
<organization />
</author>
<date month='December' day='11' year='2013' />
<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 resources 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-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-01.txt' />
</reference>
<reference anchor='I-D.schmertmann-dice-codtls'>
<front>
<title>CoDTLS: DTLS handshakes over CoAP</title>
<author initials='L' surname='Schmertmann' fullname='Lars Schmertmann'>
<organization />
</author>
<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='February' day='14' year='2014' />
<abstract><t>The Datagram Transport Layer Security protocol, DTLS, is usually transported over UDP. In Constrained Node Networks, there may be considerable limitations on the packet delivery rates and on practically usable packet sizes. Applications often can control the size and retransmission requirements of their data packets, but the DTLS handshake is out of scope for such application optimizations. This specification defines how to perform a DTLS handshake on top of the CoAP protocol. The resulting DTLS connection may then be used for instance for transporting CoAP, or as a source of keying material. The latter case is particularly interesting if the CoAP exchanges transporting the DTLS handshake messages traverse CoAP proxies.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-schmertmann-dice-codtls-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-schmertmann-dice-codtls-00.txt' />
</reference>
<reference anchor='I-D.bormann-core-ace-aif'>
<front>
<title>An Authorization Information Format (AIF) for ACE</title>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='January' day='17' year='2014' />
<abstract><t>Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. On the ACE mailing list, an activity to create specifications for such authenticated authorization for constrained devices is contemplated. One potential work item is an Authorization Information Format (AIF). This document provides a strawman for such a format that is intended to enable further discussion of the objectives for its development.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-bormann-core-ace-aif-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-bormann-core-ace-aif-00.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:00:46 |