Internet DRAFT - draft-gerdes-ace-dcaf-examples
draft-gerdes-ace-dcaf-examples
ACE Working Group S. Gerdes
Internet-Draft O. Bergmann
Intended status: Informational C. Bormann
Expires: January 7, 2016 Universitaet Bremen TZI
July 06, 2015
Examples for Using DCAF with less constrained devices
draft-gerdes-ace-dcaf-examples-00
Abstract
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.
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.
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Gerdes, et al. Expires January 7, 2016 [Page 1]
Internet-Draft dcaf-examples July 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Example 1: Posting Sensor Values on a Website using OpenID
Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
See abstract.
2. Terminology
o Readers should be familiar with the concepts introduced in
[I-D.gerdes-ace-dcaf-authorize]
To reduce the confusion between OpenID and DCAF services, we are
using the following terminology:
o Server Authorization Manager (SAM): An entity that prepares and
endorses authentication and authorization data for a Server.
o Client Authorization Manager (CAM): An entity that prepares and
endorses authentication and authorization data for a Client.
o Server (S): An endpoint that hosts and represents a resource.
Gerdes, et al. Expires January 7, 2016 [Page 2]
Internet-Draft dcaf-examples July 2015
o Client (C): An endpoint that attempts to access a resource on the
Server.
3. Example 1: Posting Sensor Values on a Website using OpenID Connect
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.
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).
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.
This example illustrates the authentication and authorization using
the OpenID Connect Authorization Code Flow as described in section
3.1 of [OpenID-Connect].
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 [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.
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
Gerdes, et al. Expires January 7, 2016 [Page 3]
Internet-Draft dcaf-examples July 2015
After authenticating Sarah and requesting her permission (for details
please consult sections 3.1.2.3 and 3.1.2.4 of [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.
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.
Figure 1 illustrates the resulting message flow.
(Please refer to PDF version to see this picture.)
Figure 1: Authentication and Authorization Flow
4. Security Considerations
TBD
5. IANA Considerations
None
6. References
6.1. Normative References
[I-D.gerdes-ace-dcaf-authorize]
Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
Authentication and Authorization Framework (DCAF)", draft-
gerdes-ace-dcaf-authorize-02 (work in progress), March
2015.
6.2. Informative References
[OpenID-Connect]
Sakimura, N., Bradley, J., Jones, M., de Madeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014.
Gerdes, et al. Expires January 7, 2016 [Page 4]
Internet-Draft dcaf-examples July 2015
Authors' Addresses
Stefanie Gerdes
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63906
Email: gerdes@tzi.org
Olaf Bergmann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63904
Email: bergmann@tzi.org
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Gerdes, et al. Expires January 7, 2016 [Page 5]
