One document matched: draft-gerdes-core-dcaf-authorize-01.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-core-dcaf-authorize-01" 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="2013" month="October" day="21"/>
<area>Applications</area>
<workgroup>CoRE 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="I-D.ietf-core-coap"/> 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 identify the client. 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 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">
<!-- In this document, the key words "MUST", "MUST NOT", "REQUIRED", -->
<!-- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", -->
<!-- and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 -->
<!-- {{RFC2119}}. -->
<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.</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 claiming to be C is to be trusted.</t>
<t>Access information: Contains authentication information and, if
necessary, authorization information. <!-- FIXME: Difference to Access Ticket? --></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>
</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 Transm. --> | | |
| | | |
| | <== 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>This document uses JavaScript Object Notation (JSON, <xref target="RFC4627"/>) 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. <vspace blankLines='1'/>
<!-- In the last case we might want to send a 4.03 or 4.05 if the
request was received on a secure channel. Does this fit to the
authorized resource request message? -->
</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='Editor’s 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 JSON. (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+json
{
"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>
</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.</t>
<t>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>The identifier of C included in the Access Request is used to
distinguish the Clients within AM’s namespace. To decide if a Client
is allowed to access the requested resource, AS must rely on AM’s
verification of that Client’s identity because AS cannot authenticate
the Client by itself. (Refer to <xref target="trust"/> for a detailed discussion of
the trust relationship between authentication managers and
authorization servers.)</t>
<t>Note: Whenever the Resource Owner wants to specify access permissions
for an individual client, the Authorization Server must be able to
relate those permissions to that respective client using an identifier
that is globally unique.</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+json
{
"AS": coaps://as-rs.example.com/authorize",
"CI": "node-588",
"M": [ "GET", "PUT" ],
"R": "coaps://temp451.example.com/s/tempC",
"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 M are GET and PUT. The requesting client is identified as
“node-588”.</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+json”
and contains at least the fields AS, CI, M, and R. AM MUST respond
with 4.00 (Bad Request) if the type is “application/dcaf+json” 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+json 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>
</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, 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>
</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+json”
and contains at least the fields AS, CI, M, and R. AS MUST respond
with 4.00 (Bad Request) for CoAP (or 400 for HTTP) if the type is “application/dcaf+json” 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="I-D.ietf-core-coap"/> 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 JSON 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+json
Max-Age: 86400
{ "F": {
"AI": { "Role" : 3 },
"CI": "2001:db8:ab9:1234:7920:3133:ae5f:87",
"TS": "2013-07-10T10:04:12.391",
"L": 86400,
"G": "hmac_sha256"
},
"V": "w+ZeJx5MxIEkt7yBMWjX6ztSYcIBTz+sv4z98m+PUEY="
}
]]></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+json
]]></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="I-D.ietf-core-coap"/>, 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 a an Authorized Resource Request
will succeed. </t>
</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.</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>Client Identifier</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+json)">
<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
JavaScript Object Notation (JSON, <xref target="RFC4627"/>) is defined.</t>
<t>The following attributes are defined:</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 (see below).
<!-- access information? --></t>
<t hangText='CI:'>
Client Identity. A string that identifies 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 string containing an encrypted ticket Face
encoded as base64 according to Section 4 of <xref target="RFC4648"/>.</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='M:'>
Methods. The list of actions to be performed on the resource R,
encoded as an array of strings. In
an authorization request, this list contains the actions that the
initiator of the request wants to perform. In an authorization
ticket, this attribute denotes the actions that are permitted.</t>
<t hangText='R:'>
Resource. A string that denotes the absolute URI of the resource to
be accessed. As the access ticket is requested in order to establish
a DTLS connection with the server that hosts this resource, the URI
scheme typically is “coaps”.</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 string that identifies 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.</t>
<t hangText='F:'>
Ticket Face. An object containing the fields AI, CI, TS, and optionally
G, L and V.</t>
<t hangText='V:'>
Ticket Verifier. A string containing the shared secret between C and
RS, encoded as base64 according to Section 4 of <xref target="RFC4648"/>.</t>
</list></t>
<t>The exact specification of AI is out of scope for this document. AI
may, e.g., contain a single role identifier known by RS, or an array
of pairs (M, R) with M and R defined as above.</t>
<t>As AI is used to authorize resource access as defined in
<xref target="authorized-rreq"/>, RS MUST be able to interpret the contained
information.</t>
<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+json
{
"AS": "https://as-rs.example.com/a?ep=%5B2001:DB8::dcaf:1234%5D",
"CI": "2001:DB8::dcaf:1234",
"M": [ "GET" ],
"R": "coaps://temp451.example.com/s/tempC",
"TS": "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 with an application-specific role identifier, a client
identifier, 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+json
{
"F": {
"AI": { "Role" : 3 },
"CI": "2001:db8:ab9:1234:7920:3133:ae5f:87",
"TS": 2938749,
"L": 3600,
"G": "hmac_sha256"
},
"V": "zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg=="
}
]]></artwork></figure>
<t>The Face may be encrypted as illustrated in the following example.
Here, the field E carries an encrypted and base64-encoded 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": "rjtolfjyX9q7Emxgsnz+nf0xTQhe1MjzZBRoIEW4vmSVlyJdW4KDgVtW
LyBnQSVX0lmVpxUYbdNuk/5PkCOJBeex0obiEBC1UmKoJfJfjy7bLQhq
k9HuJD7cvjHNOVZtNZf5qrxt7xJSoZFe6j/SJuxGNH/72SPDrdMQeXJI
pX6vCJB698FcRDOXh/ipi9KT8YWeo/ljUMgJc+LI",
"K": "key0",
"V": "zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg=="
}
]]></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":{"Role":3},
"CI":"2001:db8:ab9:1234:7920:3133:ae5f:87",
"TS":2938749,
"L":3600,
"V":"zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg=="}
]]></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>
<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+json” 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 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+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"}
C --> AM
POST client-authorize [Mid=1235,Token="tok"]
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
"CI": "2001:DB8::c",
"M": [ "PUT" ],
"R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}
AM --> AS [Mid=23146]
POST ep/node138/a/switch2941
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
"CI": "2001:DB8::c",
"M": [ "PUT" ],
"R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}
AM <-- AS
2.05 Content [Mid=23146]
Content-Format: application/dcaf+json
{ "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] },
"CI": "2001:DB8::c",
"TS": "2013-07-04T20:17:38.002,
"G": "hmac_sha256"
},
"V": "yYVLYZZ5Nssbn0by3fqel9WK6jHdoYyNej2d/kSuBLw="
}
C <-- AM
2.05 Content [Mid=1235,Token="tok"]
Content-Format: application/dcaf+json
{ "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] },
"CI": "2001:DB8::c",
"TS": "2013-07-04T20:17:38.002",
"G": "hmac_sha256"
},
"V": "MR5TMrNngbSEAkFl0akmsdbmzF0gqxGI/d3KjwT8GxI="
}
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='"F":{"AI":{"R":"a/switch2941","M":["GET","PUT"]},
"CI": "2001:DB8::c",
"TS": "2013-07-04T20:17:38.002",
"G": "hmac_sha256"')
(C decodes the contents of V and uses the result as PSK)
ChangeCipherSpec
Finished
(RS calculates PSK from AI, CI, TS and its session key
HMAC_sha256("{\"R\":\"a/switch2941\",\"M\":[\"GET\",\"PUT\"]}"+
"2001:DB8::c"+"2013-07-04T20:17:38.002",
"secret")
= 311e5332b36781b484024165d1a926b1d6e6cc5d20ab1188fdddca8f04fc1b12
)
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+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"}
C --> AM
POST client-authorize
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
"CI": "2001:DB8::c",
"M": [ "DELETE" ],
"R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}
AM --> AS
POST ep/node138/a/switch2941
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
"CI": "2001:DB8::c",
"M": [ "DELETE" ],
"R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}
AM <-- AS
2.05 Content
Content-Format: application/dcaf+json
C <-- AM
2.05 Content
Content-Format: application/dcaf+json
]]></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+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
"CI": "2001:DB8::c",
"M": [ "GET", "PUT", "DELETE" ],
"R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}
AM <-- AS
2.05 Content
Content-Format: application/dcaf+json
{ "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] },
"CI": "2001:DB8::c",
"TS": "2013-07-04T21:33:11.930",
"G": "hmac_sha256"
},
"V": "NZ8Q3o8P4eHOzkoscaUpoRvrn5d74Cscw/aXAiNmC/k="
}
]]></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+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
"CI": "2001:DB8::c",
"M": [ "GET", "POST" ],
"R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}
AM <-- AS
2.05 Content
Content-Format: application/dcaf+json
{ "F": { "CI": "2001:DB8::c",
"TS": "2013-07-16T10:15:43.663",
"G": "hmac_sha256"
},
"V": "mCYtLG/oZIWki/mCFNJ4nxI0WMPwlDKAnXIo/ir2dtI="
}
]]></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="mt" title="dcaf+json Media Type Registration">
<t>Type name: application</t>
<t>Subtype name: dcaf+json</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="RFC4627"/>. 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+json
(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+json</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='RFC4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'>
<organization /></author>
<date year='2006' month='October' />
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4648' />
<format type='TXT' octets='35491' target='http://www.rfc-editor.org/rfc/rfc4648.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='I-D.ietf-core-coap'>
<front>
<title>Constrained Application Protocol (CoAP)</title>
<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
<organization />
</author>
<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='June' day='28' year='2013' />
<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 6LoWPAN 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. 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='Internet-Draft' value='draft-ietf-core-coap-18' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-18.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC4627'>
<front>
<title>The application/json Media Type for JavaScript Object Notation (JSON)</title>
<author initials='D.' surname='Crockford' fullname='D. Crockford'>
<organization /></author>
<date year='2006' month='July' />
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4627' />
<format type='TXT' octets='16319' target='http://www.rfc-editor.org/rfc/rfc4627.txt' />
</reference>
<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='October' day='20' year='2013' />
<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-13' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-block-13.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='October' day='15' year='2013' />
<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-11' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-observe-11.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='S' surname='Krco' fullname='Srdjan Krco'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='June' day='3' 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-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-00.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 07:08:25 |