One document matched: draft-gerdes-ace-dcaf-examples-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-examples-00" category="info">

  <front>
    <title abbrev="dcaf-examples">Examples for Using DCAF with less constrained devices</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="2015" month="July" day="06"/>

    <area>Security</area>
    <workgroup>ACE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Constrained nodes are devices which are limited in terms of
processing power, memory, non-volatile storage and transmission
capacity. Due to these constraints, commonly used security protocols
are not easily applicable. Nevertheless, an authentication and
authorization solution is needed to ensure the security of these
devices.</t>

<t>The Delegated CoAP Authorization Framework (DCAF) specifies how
resource-constrained nodes can delegate defined authentication- and
authorization-related tasks to less-constrained devices called
Authorization Managers, thus limiting the hardware requirements of the
security solution for the constrained devices.</t>

<t>To realize the vision of “one Internet for all”, constrained devices
need to securely establish trust relationships with less constrained
devices. This document lists examples for using DCAF with less
constrained devices.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>See abstract.</t>

</section>
<section anchor="terminology" title="Terminology">

<t><list style="symbols">
  <t>Readers should be familiar with the concepts introduced in
<xref target="I-D.gerdes-ace-dcaf-authorize"/></t>
</list></t>

<t>To reduce the confusion between OpenID and DCAF services, we are using
the following terminology:</t>

<t><list style="symbols">
  <t>Server Authorization Manager (SAM): An entity that prepares and
endorses authentication and authorization data for a Server.</t>
  <t>Client Authorization Manager (CAM): An entity that prepares and
endorses authentication and authorization data for a Client.</t>
  <t>Server (S): An endpoint that hosts and represents a resource.</t>
  <t>Client (C): An endpoint that attempts to access a resource on the Server.</t>
</list></t>

</section>
<section anchor="example-1-posting-sensor-values-on-a-website-using-openid-connect" title="Example 1: Posting Sensor Values on a Website using OpenID Connect">

<t>To illustrate this example, we assume the following scenario: Sarah
has a constrained device that is equipped with a temperature
sensor. During a heat wave, she wants her device to continuously post
the current room temperature in her office in the blog of her social
media account to inform others of her working conditions. She wants to
use OpenID Connect to log into CAM and establish a trust relationship
between the temperature sensor and her blog.</t>

<t>The temperature sensor that is acting as a CoAP client (C) in this
scenario is associated with a Client Authorization Manager (CAM) that
helps C with authentication and authorization and provides a user
interface to Sarah for configuring C. The blog on her social media
account acts as a DCAF server (S).</t>

<t>In this first example, Sarah is registered with an OpenID provider
(OP) that CAM accepts for
authentication and which additionally acts as an Authorization Server (AS)
for her social media service. Moreover, AS is compatible with DCAF and
acts as a DCAF server authorization manager (SAM). For requesting
access to the blog, OP defines the scope parameter
coaps://blog.socialmedia.example.com. Sarah uses the browser on her
smartphone as a User Agent (UA) to initiate the authentication and
authorization process.</t>

<t>This example illustrates the authentication and authorization using
the OpenID Connect Authorization Code Flow as described in section 3.1
of <xref target="OpenID-Connect"/>.</t>

<t>Sarah uses her UA to request CAM to configure C to access her blog.
To authenticate Sarah, CAM generates an Authentication Request
(cf. section 3.1.2.1 of <xref target="OpenID-Connect"/>). Since CAM needs to obtain
authorization for accessing Sarah’s Blog for C, it also adds the scope
parameter coaps://blog.socialmedia.example.com. CAM sends the
Authentication Request to Sarah’s UA, thereby triggering it to send an
Authentication Request to OP’s Authorization Endpoint.</t>

<figure><artwork><![CDATA[
HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
  response_type=code
  &scope=openid%20coaps://blog.socialmedia.example.com
  &client_id=s6BhdRkqt3
  &state=af0ifjsldkj
  &redirect_uri=https%3A%2F%2Fcam.example.org%2Flogin
]]></artwork></figure>

<t>After authenticating Sarah and requesting her permission (for details
please consult sections 3.1.2.3 and 3.1.2.4 of <xref target="OpenID-Connect"/>),
the OP sends back a successful Authentication Response that contains
the parameter code. The code can then be used by CAM to send a Token
Request to the Token Endpoint which responds with an ID token, an
access token and a refresh token. CAM uses the ID token and access
token to authenticate Sarah. The refresh token is then used to request an
additional access token for accessing the blog.</t>

<t>CAM sends the refresh token to the Token Endpoint with the scope
coaps://blog.socialmedia.example.com. The Token Endpoint validates the
refresh token and makes sure that the requested scope does fit to the
original grant. The Token Endpoint speaks both DCAF and OAuth and acts
as SAM. It generates a ticket including a verifier and sends it back
to CAM. CAM transmits the ticket to its client and instructs it to
access the blog. The client then uses the ticket to establish a DTLS
connection with the blog.</t>

<t><xref target="flow"/> illustrates the resulting message flow.</t>

<figure title="Authentication and Authorization Flow" anchor="flow"><artwork><![CDATA[
(Please refer to PDF version to see this picture.)
]]></artwork></figure>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>TBD</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>None</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<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='March' day='9' 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-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-gerdes-ace-dcaf-authorize-02.txt' />
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="OpenID-Connect" >
  <front>
    <title>OpenID Connect Core 1.0</title>
    <author initials="N." surname="Sakimura" fullname="Nat Sakimura">
      <organization></organization>
    </author>
    <author initials="J." surname="Bradley" fullname="John Bradley">
      <organization></organization>
    </author>
    <author initials="M." surname="Jones" fullname="Michael B. Jones">
      <organization></organization>
    </author>
    <author initials="B." surname="de Madeiros" fullname="Breno de Madeiros">
      <organization></organization>
    </author>
    <author initials="C." surname="Mortimore" fullname="Chuck Mortimore">
      <organization></organization>
    </author>
    <date year="2014" month="November" day="08"/>
  </front>
</reference>


    </references>



  </back>
</rfc>