idnits 2.17.1 draft-gerdes-ace-a2a-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 (March 09, 2015) is 3335 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-01 == Outdated reference: A later version (-05) exists of draft-gerdes-ace-actors-02 Summary: 0 errors (**), 0 flaws (~~), 3 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 Universitaet Bremen TZI 4 Intended status: Informational March 09, 2015 5 Expires: September 10, 2015 7 Managing the Authorization to Authorize in the Lifecycle of a 8 Constrained Device 9 draft-gerdes-ace-a2a-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 During the lifecycle of a constrained device, responsibility for 21 managing authorization policies for the constrained device may change 22 several times. To ensure the security of the constrained devices, 23 the authorization to authorize must be transferred to the new 24 principal in a secure way. 26 The Delegated CoAP Authorization Framework (DCAF) specifies how 27 resource-constrained nodes can delegate defined authentication- and 28 authorization-related tasks to less-constrained devices called 29 Authorization Managers, thus limiting the hardware requirements of 30 the security solution for the constrained devices. 32 This document defines how DCAF can be used to manage the 33 Authorization Manager of a constrained device and introduces a 34 flexible authorization solution for the whole lifecycle of a 35 constrained device. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 10, 2015. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Authorization to Authorize . . . . . . . . . . . . . . . . . 3 74 4. Assigning a new Authorization Manager . . . . . . . . . . . . 4 75 5. Authorization Transitions in the Lifecycle of Constrained 76 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 5.1. Manufacturing . . . . . . . . . . . . . . . . . . . . . . 5 78 5.2. Commissioning . . . . . . . . . . . . . . . . . . . . . . 6 79 5.3. Decommissioning . . . . . . . . . . . . . . . . . . . . . 6 80 5.4. Handover and Maintenance . . . . . . . . . . . . . . . . 6 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 85 8.2. Informative References . . . . . . . . . . . . . . . . . 7 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 88 1. Introduction 90 As shown in [I-D.gerdes-ace-actors], constrained devices can benefit 91 from being closely coupled to a less constrained device, the 92 Authorization Manager (AM). The AM helps its constrained devices 93 with authentication and authorization tasks. The delegated CoAP 94 Authentication and Authorization Framework (DCAF) 95 [I-D.gerdes-ace-dcaf-authorize] defines the communication flow 96 between client, server and their respective Authorization Managers, 97 thus relieving constrained nodes from managing keys for numerous 98 devices while ensuring that the constrained devices are able to 99 enforce the authorization policies of their principals. 101 Since the constrained devices strongly rely on their Authorization 102 Managers for security-related tasks, the connection between the 103 constrained device and its respective AM needs to be especially 104 protected. This is particularly difficult at transitions between 105 different phases in the lifecycle of a constrained device. These 106 transitions often comprise a change of the device ownership and 107 therefore might often entail that the principal that controls the 108 authorization policies changes. One way of transferring this 109 authorization to authorize is to change which Authorization Manager 110 is responsible for a constrained device. 112 This document defines how DCAF can be used to manage the 113 Authorization Manager of a constrained device and introduces a 114 flexible authorization solution for the whole lifecycle of a 115 constrained device. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 o Readers should be familiar with the terminology introduced in 124 [I-D.gerdes-ace-actors] 126 3. Authorization to Authorize 128 AM helps its constrained device to determine the authorization of 129 another device, e.g. if it is allowed to access an item of interest 130 or to provide information about such an item. Some security-related 131 tasks must be conducted by the constrained device itself, such as 132 message authentication and the enforcement of authorization policies. 133 However, the information needed for these tasks are provided by the 134 AM which represents the principal's will to the constrained device. 135 Principals can easily configure the AM since it has the necessary 136 user interface. In particular, AM provides authorization information 137 to the constrained device: It is authorized to define authorizations. 139 The constrained device shares a symmetric key with its AM. We call 140 this key K_AM. The constrained device uses this key to determine if 141 the authorization information was provided by the AM. 143 K_AM is stored in a resource which we call AM-Key, e.g. /am/key. The 144 key belongs to a URI which is the address of the Authorization 145 Manager. The URI is stored in resource that we call AM-URI, e.g. 146 /am/uri. 148 The AM-key resource needs special protection because the entity which 149 controls K_AM is in control of the constrained device. Therefore, 150 the AM-key resource MUST be access-protected and SHOULD be write- 151 only. 153 4. Assigning a new Authorization Manager 155 To assign a new AM to a constrained device, the AM-key resource must 156 be changed. In this case, the constrained device always acts as the 157 Server, even if it is generally used as a client. The client in this 158 communication SHOULD be the new AM. 160 To change the value of a resource representation, a ticket is needed. 161 DCAF tickets consist of two parts, the ticket face and the verifier. 162 While the client uses the verifier as a session key, the Server can 163 derive the session key from the ticket face and the AM-key. 165 To change the AM-key (/am/key) and AM-URI (/am/uri) resources, the 166 client needs a ticket that authorizes it to use PUT on these 167 resources. There are three possibilities for a client to get this 168 ticket: 170 o request a ticket from the former AM. 172 o use a preconfigured ticket. 174 o use a copy of the old AM-key to create the ticket. 176 With the help of the ticket, client and server establish a DTLS 177 session. The new K_AM and the URI of the new AM can then be securely 178 transmitted to the Server. 180 The new K_AM MUST NOT be disclosed to others. If the authorization 181 ticket is requested from the former AM, the client MUST NOT include 182 the new K_AM in the Access Request Message. 184 If the client is not the new AM, the new K_AM MUST be transmitted to 185 the new AM and removed from the client. 187 5. Authorization Transitions in the Lifecycle of Constrained Devices 189 The lifecycle of a constrained device consists of several phases. 190 The device is created in the manufacturing phase. Devices are then 191 sold to customers who introduce them to their networks during the 192 commissioning phase. In the operation phase, constrained devices 193 fullfill their purpose in life, sometimes alternated with a 194 maintenance phase. Some devices are sold during their lifetime and 195 need to be decommissioned and recommissioned in the handover phase. 196 At the end of the device's lifecycle, the device is decommissioned in 197 the decommissioning phase. 199 Apart from the operation phase, mechanisms for changing the 200 authorization to authorize are needed in every phase of the 201 lifecycle. 203 5.1. Manufacturing 205 In the manufacturing phase, the manufacturer can choose one of the 206 following options for the initial key provisioning: 208 o Provisioning with AM service: K_AM is provisioned to the new 209 device and the manufacturer provides an Authorization Manager 210 service. 212 o Provisioning only: K_AM is provisioned to the new device but the 213 manufacturer does not provide an Authorization Manager service. 215 o No provisioning: No K_AM is provisioned to the newly manufactured 216 device. 218 In the provisioning with AM service case, the manufacturer provides 219 an own AM service. Future principals can use the AM service if they 220 don't want to maintain an own AM. The manufacturer sets the AM-URI 221 resource to the URI of the manufacturer's AM and writes the initial 222 K_AM into the AM-key resource. Additionally, K_AM is provided to the 223 Authorization Manager. Each constrained device SHOULD be provisioned 224 with an individual unique key. 226 In the provisioning only case, the manufacturer does not provide an 227 AM service. The AM-key resource is set to the initial K_AM. The AM- 228 URI resource is left empty. K_AM has to be made available to the new 229 principal, e.g. by encoding it into a QR code and printing it onto a 230 sheet of paper which is delivered with the device, or onto the device 231 itself. K_AM SHOULD be kept secret. 233 In the no provisioning case, the AM-key resource is not initialized 234 and MUST be unprotected. The new principal will then be able to 235 write an AM-key into this resource without the need for an 236 authorization ticket. 238 5.2. Commissioning 240 In the commissioning phase, the principal of the device has changed. 241 The new principal needs to be able to take over the control over the 242 device by defining authorization policies. To achieve this, 243 principals will either use the Authorization Manager service of the 244 manufacturer (if available) or need to assign a new Authorization 245 Manager to the device (see also Section 4). 247 To assign a new Authorization Manager, the procedure described in 248 Section 4 is used. 250 5.3. Decommissioning 252 If a device is discarded or sold, the principal of the device 253 changes. To make sure that nobody who gets hold of the device 254 afterwards is able to misuse it, permissions for the device must be 255 revoked. 257 The principal removes authorizations for the constrained device from 258 the AM. Since the AM is used to negotiate tickets for new 259 connections with other devices, the decommissioned device will not be 260 able to request new connections afterwards. 262 Already existing tickets and session keys have to be removed from the 263 decommissioned device. In particular, for Servers the ticket faces 264 and derived session keys need to be erased, for Clients the Verifiers 265 must be deleted. 267 5.4. Handover and Maintenance 269 During the lifecycle of a constrained device, Authorization Managers 270 sometimes need to be exchanged for maintenance reasons or because the 271 device is sold. In both cases, the relationship between the former 272 AM and the constrained device must be broken. 274 The exchange of the AM consists of a decomissioning as described in 275 Section 5.3 followed by a commissioning as described in Section 5.2. 276 Before the decommissioning, one of the mechanisms described in 277 Section 4 for the commissioning MUST be used to create an 278 authorization ticket for assigning the new AM. 280 6. Security Considerations 282 o What do we do if the key for changing the AM is lost? 284 o K_AM must be protected. The entity that has K_AM is in control of 285 the constrained device. 287 o It might be difficult to protect a preconfigured K_AM. 289 o If the PSK is printed onto the device, everyone who has access to 290 the device can use it. 292 o If a new AM-key is transmitted this transmission must be protected 293 very well. 295 7. IANA Considerations 297 None 299 8. References 301 8.1. Normative References 303 [I-D.gerdes-ace-dcaf-authorize] 304 Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP 305 Authentication and Authorization Framework (DCAF)", draft- 306 gerdes-ace-dcaf-authorize-01 (work in progress), February 307 2015. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 8.2. Informative References 314 [I-D.gerdes-ace-actors] 315 Gerdes, S., "Actors in the ACE Architecture", draft- 316 gerdes-ace-actors-02 (work in progress), October 2014. 318 Author's Address 320 Stefanie Gerdes 321 Universitaet Bremen TZI 322 Postfach 330440 323 Bremen D-28359 324 Germany 326 Phone: +49-421-218-63906 327 Email: gerdes@tzi.org