One document matched: draft-gerdes-ace-dcaf-sitr-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.22 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-gerdes-ace-dcaf-sitr-00" category="std">
<front>
<title abbrev="ace-sitr">Server-Initiated Ticket Request</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>
<date year="2015" month="October" day="19"/>
<area>Security</area>
<workgroup>ACE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The Delegated CoAP Authorization Framework (DCAF) defines how
constrained devices can securely obtain security associations and
authorization information from their respective less constrained
devices, the Authorization Managers. In DCAF a constrained client requests an
authorization ticket from the Server Authorization Manager (SAM) by
contacting its own Client Authorization Manager (CAM). However, there
may be cases where this approach is not applicable, e.g., because the
client is not able to reach Authorization Managers in the Internet.</t>
<t>Specifically for these situations, this document defines the
Server-Initiated Ticket Request (SITR) that specifies how a
constrained server can request authorization tokens and securely
obtain security associations and authorization information for mutual
authenticated authorization with the client.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>See abstract.</t>
<section anchor="terminology" title="Terminology">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119 <xref target="RFC2119"/>.</t>
<t>Readers are required to be familiar with the terms and concepts
defined in <xref target="I-D.ietf-ace-actors"/> and
<xref target="I-D.gerdes-ace-dcaf-authorize"/>.</t>
</section>
</section>
<section anchor="protocol" title="Protocol">
<section anchor="overview" title="Overview">
<t>The figure <xref target="protocol-overview"/> depicts the Sitr protocol flow:</t>
<figure title="Protocol Overview" anchor="protocol-overview"><artwork><![CDATA[
CAM C S SAM
| | CAM Info. ----> | |
| | | |
| | | SI Acc. Req. --> |
| | | |
| | | |
| <=== (CAM/SAM Mutual Authentication and Authorization) ====> |
| | | |
| <--------------------------------------------- SIT Request |
| | | |
| SIT Grant -----------------------------------------------> |
| | | |
| | | <----- SIT Transf. |
| | | |
| | <-- CAM Inf. Resp. | |
| | | |
| | <= Authn Authz => | |
| | Auth. Res. Req. -> | |
]]></artwork></figure>
<t>The authorization flow will then look as follows: C will send a CAM
info message (maybe after first sending an unauthorized request to S
that is denied) that contains its CAM address together with the
request to this URI.</t>
<t>S will send a Server Initiated (SI) Access Request to
SAM which includes the request and URI. SAM will contact CAM and
determine if CAM has the respective permissions. The details of the
communication between CAM and SAM are not in scope for this document,
but CAM and SAM will mutually authenticate each other and then
initiate a secure communication. Then SAM sends a SIT Request to CAM
which contains
the information from the Resource Request.</t>
<t>CAM checks if SAM is authorized according to COP’s authorization
policies (mutual authorization). If this is the case, CAM creates a SI
ticket. The ticket contains keying material for the secure
communication between C and S and, if necessary, authorization
information that reflect COP’s security policies for C. CAM sends this
ticket to SAM, SAM includes server authorization information to the SI
ticket if necessary and sends the ticket to S. S keeps one part of the
ticket and sends the other part to C as a reply to C’s CAM Information
message. With their respective part of the ticket, C and S can
communicate securely.</t>
</section>
<section anchor="cam-info" title="CAM Information Message">
<t>C sends a CAM Information message to S to stimulate S to request a
ticket for C. The message is constructed as follows:</t>
<t><list style="numbers">
<t>The request method is FETCH (see <xref target="I-D.bormann-core-coap-fetch"/>).</t>
<t>The request URI is set to the URI of the requested resource.</t>
<t>The message payload contains a data structure that describes the
action and resource for which C requests an access ticket as well
as the CAM URI.</t>
</list></t>
<t>The data structure in the payload MUST contain:</t>
<t><list style="numbers">
<t>The contact information for the CAM to use: a URI that specifies
the CAM in charge of C.</t>
<t>A URI of the resource that C wants to access.</t>
<t>The actions that C wants to perform on the resource.</t>
</list></t>
<t><xref target="cam-info-message-example"/> shows an example for a CAM Information
message. (Refer to <xref target="payload-format"/> for a detailed description of
the available attributes and their semantics.)</t>
<figure title="CAM Info Message Example" anchor="cam-info-message-example"><artwork><![CDATA[
FETCH /s/tempC
Content-Format: application/dcaf+cbor
{
CAM: "coaps://sam.example.com/authorize",
SAI: ["coaps://temp451.example.com/s/tempC", 5],
TS: 168537
}
]]></artwork></figure>
<t>Note: if used with object security, the FETCH request contains CBOR
encoded message syntax structure (COSE), that conveys the
application/dcaf+cbor payload.</t>
<t>The example shows a CAM information message payload for the resource
“/s/tempC” on the Server “temp451.example.com”. Requested operations in
attribute SAI are GET and PUT.</t>
<t>The response to a CAM Information message is delivered by S back to
C in a CAM Information Response message.</t>
</section>
<section anchor="server-initiated-access-request-message" title="Server-Initiated Access Request Message">
<t>A server that receives a CAM Information message MAY use the
information in the payload of the message to request a
Server-Initiated (SI) Ticket for C. To do so, it contacts its own SAM. The
SI 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 as well
as the CAM URI.</t>
</list></t>
<t>The request URI identifies a resource at SAM for handling
authorization requests from C. The URI SHOULD be announced by SAM in
its resource directory as described in section 9 of
<xref target="I-D.gerdes-ace-dcaf-authorize"/>.</t>
<t>The message payload is constructed from the information that C has
sent in its CAM Information message (see <xref target="cam-info"/>). The request
MUST contain the attributes described in <xref target="cam-info"/>.</t>
</section>
<section anchor="server-initiated-ticket-request-message" title="Server-Initiated Ticket Request Message">
<t>When SAM receives a Server-Initiated Access Request message from S and
ROP specified authorization policies for S, SAM MUST check if the
requested actions are allowed according to these policies. If all
requested actions are forbidden, SAM MUST send a 4.03 response.</t>
<t>If no authorization policies were specified or some or all of the
requested actions are allowed according to the authorization policies,
SAM either returns a cached response or attempts to create a SI Ticket
Request message. The SI Ticket Request message MAY contain all actions
requested by C since SAM will add SAI in the Ticket Transfer Message
if ROP specified authorization policies (see <xref target="sit-transfer"/>).</t>
<t>SAM MAY return a cached response if it is known to be fresh according
to Max-Age. SAM SHOULD NOT return a cached response if it expires in
less than a minute.</t>
<t>If CAM does not send a cached response, it checks the content type of
the request payload and validates that the payload contains at least
the fields CAM and SAI. SAM MUST respond with 4.00 (Bad Request) if
the type does not belong to the allowed content-types and if any of
these fields is missing or does not conform to the format described in
<xref target="payload-format"/>.</t>
<t>If the payload is correct, SAM creates a SIT Request message
from the SI Access Request received from S as follows:</t>
<t><list style="numbers">
<t>The destination of the Ticket Request message is derived from the
“CAM” field that is specified in the Access Request message
payload (for example, if the SI Access Request contained ‘CAM:
“coaps://cam.example.com/authz”’, the destination of the Ticket
Request message is cam.example.com).</t>
<t>The request method is POST.</t>
<t>The request URI is constructed from the CAM field received in the
Access Request message payload.</t>
<t>The payload is copied from the SI Access Request sent by S.</t>
</list></t>
<t>CAM and SAM MUST be able to mutually authenticate each other,
e.g. based on a public key infrastructure and MUST be able to
communicate securely.</t>
</section>
<section anchor="si-ticket-grant-message" title="SI Ticket Grant Message">
<t>When CAM has received a SI Ticket Request message it has to evaluate
the access request information contained therein. First, it checks
whether the request payload is of a supported content type (see
<xref target="content-types"/>) and contains at least the fields CAM and SAI. CAM
MUST respond with 4.00 (Bad Request) for CoAP (or 400 for HTTP) if any
of these fields are missing or do not conform to the format described
in <xref target="payload-format"/>.</t>
<t>CAM decides whether or not access is granted to the requested resource
and then creates a SI Ticket Grant message that reflects the
result. CAM initializes the access ticket comprised of a Face and the
Client Information (CI).</t>
<t>The CI contains:</t>
<t><list style="symbols">
<t>the Client authorization information (CAI)</t>
<t>a nonce</t>
</list></t>
<t>CI MAY additionally contain:</t>
<t><list style="symbols">
<t>a lifetime</t>
<t>a CAI identifier (for revocation)</t>
<t>keying material for C (if no key derivation method is used to
generate the verifier in Face)</t>
</list></t>
<t>The Face at this point only comprises the verifier. CAM MAY generate
the verifier using the method described in section 6.2 of
<xref target="I-D.gerdes-ace-dcaf-authorize"/>. CAM MUST NOT include Server
Authorization information (SAI) in the ticket Face.</t>
<t>The CI MUST be integrity-protected on the way to C. CAM MAY
additionally protect the confidentiality of CI. If the CI contains
keying material, CAM MUST ensure the confidentiality of CI.</t>
<t>The confidentiality of Face MUST be ensured on the way to SAM.</t>
<t>The SI Ticket Grant messages is then constructed as a success response
(2.05 for CoAP, 200 for HTTP) with the ticket as content.</t>
</section>
<section anchor="sit-transfer" title="SI Ticket Transfer Message">
<t>The SI Ticket Transfer message is the response to the SI access
request and delivers the ticket to S.</t>
<t>The CAI provided by CAM in the SI Ticket Grant message provide only
the client-side permissions. If ROP defined access permissions for S,
SAM MUST add server authorization information (SAI) to Face that
reflect those policies. SAM MUST NOT include SAI that were provided by
CAM.</t>
<t>SAM MUST provide for the confidentiality and integrity of Face when
transmitting it to S. SAM MAY encrypt the CI.</t>
</section>
<section anchor="cam-information-response" title="CAM Information Response">
<t>When S receives a SI Ticket Transfer message, it MUST make sure that
it contains the Face and the CI. If Face contains SAI, S MUST validate
its authenticity and integrity. S keeps the ticket Face and sends the
CI to C. S MAY transmit the answer to C’s initial request provided in
the CAM Info message together with the CI.</t>
<t>When C receives the CAM Information Response, it MUST validate that
the CI was generated by CAM and not modified. With the information in
the CI, C can start a secure communication with S.</t>
<t>C MAY establish a security context with S using the verifier provided
in the CI, e.g., by initiating a DTLS session with the verifier as the
Pre-shared Key.</t>
</section>
</section>
<section anchor="payload-format" title="Payload Format">
<t>SITR uses the CBOR representation defined in DCAF (see section 5 of
<xref target="I-D.gerdes-ace-dcaf-authorize"/>) and additionally defines a CBOR
value for CAM:</t>
<texttable title="SITR field identifiers encoded in CBOR" anchor="cbor-keys">
<ttcol align='left'>Encoded Value</ttcol>
<ttcol align='left'>Key</ttcol>
<c>13</c>
<c>CAM</c>
</texttable>
</section>
<section anchor="content-types" title="Content Types">
<t>The supported content types are:</t>
<t><list style="symbols">
<t>“application/dcaf+cbor”</t>
<t>“application/cose+cbor”</t>
</list></t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>None</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>For solutions where the server requests the ticket for the client,
most of the workload (send a message to the authorization manager,
wait for the answer, keep state in the meantime) is on the server
which makes it susceptible to DOS attacks. Therefore, as with all
solutions state based on client requests, these solutions MUST NOT be
used except in conjunction with appropriate mitigation. Where
applicable, it is recommended to use DCAF instead, where the client
has to request the ticket.</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The author would like to thank Bert Greevenbosch, Olaf Bergmann and
Carsten Bormann for their valuable input and feedback.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='I-D.gerdes-ace-dcaf-authorize'>
<front>
<title>Delegated CoAP Authentication and Authorization Framework (DCAF)</title>
<author initials='S' surname='Gerdes' fullname='Stefanie Gerdes'>
<organization />
</author>
<author initials='O' surname='Bergmann' fullname='Olaf Bergmann'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='September' day='10' year='2015' />
<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>
<seriesInfo name='Internet-Draft' value='draft-gerdes-ace-dcaf-authorize-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-gerdes-ace-dcaf-authorize-03.txt' />
</reference>
<reference anchor='I-D.bormann-core-coap-fetch'>
<front>
<title>CoAP FETCH Method</title>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='October' day='19' year='2015' />
<abstract><t>Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. The present proposal adds a new CoAP method, FETCH, to perform the equivalent of a GET with a request body. This specification is inspired by I-D.snell-search-method, which updates the definition and semantics of the HTTP SEARCH request method previously defined by RFC5323. However, there is no intention to limit FETCH to search-type operations, and the resulting properties may not be the same as those of HTTP SEARCH. For now, we therefore prefer to discuss the proposal under a different name, for which we have chosen the GET synonym FETCH.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-bormann-core-coap-fetch-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-bormann-core-coap-fetch-00.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='I-D.ietf-ace-actors'>
<front>
<title>An architecture for authorization in constrained environments</title>
<author initials='S' surname='Gerdes' fullname='Stefanie Gerdes'>
<organization />
</author>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<author initials='G' surname='Selander' fullname='Goran Selander'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='October' day='19' year='2015' />
<abstract><t>Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-ace-actors-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-ace-actors-02.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:17:21 |