idnits 2.17.00 (12 Aug 2021) /tmp/idnits60531/draft-gerdes-ace-dcaf-examples-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2015) is 2504 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-gerdes-ace-dcaf-authorize-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Gerdes 3 Internet-Draft O. Bergmann 4 Intended status: Informational C. Bormann 5 Expires: January 7, 2016 Universitaet Bremen TZI 6 July 06, 2015 8 Examples for Using DCAF with less constrained devices 9 draft-gerdes-ace-dcaf-examples-00 11 Abstract 13 Constrained nodes are devices which are limited in terms of 14 processing power, memory, non-volatile storage and transmission 15 capacity. Due to these constraints, commonly used security protocols 16 are not easily applicable. Nevertheless, an authentication and 17 authorization solution is needed to ensure the security of these 18 devices. 20 The Delegated CoAP Authorization Framework (DCAF) specifies how 21 resource-constrained nodes can delegate defined authentication- and 22 authorization-related tasks to less-constrained devices called 23 Authorization Managers, thus limiting the hardware requirements of 24 the security solution for the constrained devices. 26 To realize the vision of "one Internet for all", constrained devices 27 need to securely establish trust relationships with less constrained 28 devices. This document lists examples for using DCAF with less 29 constrained devices. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 7, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 3. Example 1: Posting Sensor Values on a Website using OpenID 68 Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 73 6.2. Informative References . . . . . . . . . . . . . . . . . 4 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 See abstract. 80 2. Terminology 82 o Readers should be familiar with the concepts introduced in 83 [I-D.gerdes-ace-dcaf-authorize] 85 To reduce the confusion between OpenID and DCAF services, we are 86 using the following terminology: 88 o Server Authorization Manager (SAM): An entity that prepares and 89 endorses authentication and authorization data for a Server. 91 o Client Authorization Manager (CAM): An entity that prepares and 92 endorses authentication and authorization data for a Client. 94 o Server (S): An endpoint that hosts and represents a resource. 96 o Client (C): An endpoint that attempts to access a resource on the 97 Server. 99 3. Example 1: Posting Sensor Values on a Website using OpenID Connect 101 To illustrate this example, we assume the following scenario: Sarah 102 has a constrained device that is equipped with a temperature sensor. 103 During a heat wave, she wants her device to continuously post the 104 current room temperature in her office in the blog of her social 105 media account to inform others of her working conditions. She wants 106 to use OpenID Connect to log into CAM and establish a trust 107 relationship between the temperature sensor and her blog. 109 The temperature sensor that is acting as a CoAP client (C) in this 110 scenario is associated with a Client Authorization Manager (CAM) that 111 helps C with authentication and authorization and provides a user 112 interface to Sarah for configuring C. The blog on her social media 113 account acts as a DCAF server (S). 115 In this first example, Sarah is registered with an OpenID provider 116 (OP) that CAM accepts for authentication and which additionally acts 117 as an Authorization Server (AS) for her social media service. 118 Moreover, AS is compatible with DCAF and acts as a DCAF server 119 authorization manager (SAM). For requesting access to the blog, OP 120 defines the scope parameter coaps://blog.socialmedia.example.com. 121 Sarah uses the browser on her smartphone as a User Agent (UA) to 122 initiate the authentication and authorization process. 124 This example illustrates the authentication and authorization using 125 the OpenID Connect Authorization Code Flow as described in section 126 3.1 of [OpenID-Connect]. 128 Sarah uses her UA to request CAM to configure C to access her blog. 129 To authenticate Sarah, CAM generates an Authentication Request (cf. 130 section 3.1.2.1 of [OpenID-Connect]). Since CAM needs to obtain 131 authorization for accessing Sarah's Blog for C, it also adds the 132 scope parameter coaps://blog.socialmedia.example.com. CAM sends the 133 Authentication Request to Sarah's UA, thereby triggering it to send 134 an Authentication Request to OP's Authorization Endpoint. 136 HTTP/1.1 302 Found 137 Location: https://server.example.com/authorize? 138 response_type=code 139 &scope=openid%20coaps://blog.socialmedia.example.com 140 &client_id=s6BhdRkqt3 141 &state=af0ifjsldkj 142 &redirect_uri=https%3A%2F%2Fcam.example.org%2Flogin 144 After authenticating Sarah and requesting her permission (for details 145 please consult sections 3.1.2.3 and 3.1.2.4 of [OpenID-Connect]), the 146 OP sends back a successful Authentication Response that contains the 147 parameter code. The code can then be used by CAM to send a Token 148 Request to the Token Endpoint which responds with an ID token, an 149 access token and a refresh token. CAM uses the ID token and access 150 token to authenticate Sarah. The refresh token is then used to 151 request an additional access token for accessing the blog. 153 CAM sends the refresh token to the Token Endpoint with the scope 154 coaps://blog.socialmedia.example.com. The Token Endpoint validates 155 the refresh token and makes sure that the requested scope does fit to 156 the original grant. The Token Endpoint speaks both DCAF and OAuth 157 and acts as SAM. It generates a ticket including a verifier and 158 sends it back to CAM. CAM transmits the ticket to its client and 159 instructs it to access the blog. The client then uses the ticket to 160 establish a DTLS connection with the blog. 162 Figure 1 illustrates the resulting message flow. 164 (Please refer to PDF version to see this picture.) 166 Figure 1: Authentication and Authorization Flow 168 4. Security Considerations 170 TBD 172 5. IANA Considerations 174 None 176 6. References 178 6.1. Normative References 180 [I-D.gerdes-ace-dcaf-authorize] 181 Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP 182 Authentication and Authorization Framework (DCAF)", draft- 183 gerdes-ace-dcaf-authorize-02 (work in progress), March 184 2015. 186 6.2. Informative References 188 [OpenID-Connect] 189 Sakimura, N., Bradley, J., Jones, M., de Madeiros, B., and 190 C. Mortimore, "OpenID Connect Core 1.0", November 2014. 192 Authors' Addresses 194 Stefanie Gerdes 195 Universitaet Bremen TZI 196 Postfach 330440 197 Bremen D-28359 198 Germany 200 Phone: +49-421-218-63906 201 Email: gerdes@tzi.org 203 Olaf Bergmann 204 Universitaet Bremen TZI 205 Postfach 330440 206 Bremen D-28359 207 Germany 209 Phone: +49-421-218-63904 210 Email: bergmann@tzi.org 212 Carsten Bormann 213 Universitaet Bremen TZI 214 Postfach 330440 215 Bremen D-28359 216 Germany 218 Phone: +49-421-218-63921 219 Email: cabo@tzi.org