idnits 2.17.1 draft-gerdes-ace-a2a-01.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 (September 11, 2015) is 3149 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 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-00 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 September 11, 2015 5 Expires: March 14, 2016 7 Managing the Authorization to Authorize in the Lifecycle of a 8 Constrained Device 9 draft-gerdes-ace-a2a-01 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 Resource-constrained nodes benefit from delegating defined 27 authentication- and authorization-related tasks to less-constrained 28 devices called Authorization Managers, thus limiting the hardware 29 requirements of the security solution for the constrained devices. 31 This document defines how security relationships between constrained 32 nodes and their Authorization Managers can be established and managed 33 in a RESTful way, thus providing for a flexible authorization 34 solution for the whole lifecycle of a constrained node. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 14, 2016. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Authorization to Authorize . . . . . . . . . . . . . . . . . 3 73 4. Assigning a new Authorization Manager . . . . . . . . . . . . 4 74 5. Authorization Transitions in the Lifecycle of Constrained 75 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 5.1. Manufacturing . . . . . . . . . . . . . . . . . . . . . . 5 77 5.2. Commissioning . . . . . . . . . . . . . . . . . . . . . . 6 78 5.3. Decommissioning . . . . . . . . . . . . . . . . . . . . . 6 79 5.4. Handover . . . . . . . . . . . . . . . . . . . . . . . . 6 80 5.5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 6 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 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.ietf-ace-actors], constrained nodes can benefit from 91 being closely coupled to a less constrained node called Authorization 92 Server or Authorization Manager (AM). The AM helps its constrained 93 node with authentication and authorization tasks. Authorization 94 solutions such as the delegated CoAP Authentication and Authorization 95 Framework (DCAF) [I-D.gerdes-ace-dcaf-authorize] define the 96 communication flow between client, server and their respective 97 Authorization Managers, thus relieving constrained nodes from 98 managing keys for numerous devices while ensuring that the 99 constrained devices are able to enforce the authorization policies of 100 their principals. 102 Since the constrained devices strongly rely on their Authorization 103 Managers for security-related tasks, the connection between the 104 constrained device and its respective AM needs to be especially 105 protected. This is particularly difficult at transitions between 106 different phases in the lifecycle of a constrained device. These 107 transitions often comprise a change of the device ownership and 108 therefore might often entail that the principal that controls the 109 authorization policies changes. One way of transferring this 110 authorization to authorize is to change which Authorization Manager 111 is responsible for a constrained device. 113 This document defines how the security relationship between a 114 constrained node and its Authorization Manager can be managed in a 115 RESTful way, thus providing for a flexible authorization solution for 116 the whole lifecycle of a constrained device. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 o Readers should be familiar with the concepts and terminology 125 introduced in [I-D.ietf-ace-actors] and 126 [I-D.gerdes-ace-dcaf-authorize] 128 3. Authorization to Authorize 130 The Authorization Manager helps its constrained node to determine the 131 authorization of another node, e.g. if it is allowed to access an 132 item of interest or to provide information about such an item. 133 Principals can easily configure authorization information on the AM 134 since it has the necessary user interface. AM provides the 135 authorization information to the constrained node: It is authorized 136 to define authorizations. 138 The constrained node needs keying material to determine if the 139 authorization information was really provided by its AM. We call 140 this keying material K_AM. Depending on the authorization solution, 141 symmetric or asymmetric keys can be used. For symmetric solutions, 142 the constrained node and the AM share a key. For asymmetric 143 solutions, K_AM is AM's public key. 145 K_AM is stored in a resource which we call AM-Key, e.g. /am/key. The 146 key belongs to a URI which is the address of the AM. The URI is 147 stored in resource that we call AM-URI, e.g. /am/uri. 149 The AM-key resource needs special protection because the entity which 150 controls K_AM is in control of the constrained node. Therefore, the 151 AM-key resource MUST be access-protected and SHOULD be write-only. 153 4. Assigning a new Authorization Manager 155 To assign a new AM to a constrained node, the AM-key resource must be 156 changed. In this case, the constrained node always acts as the 157 server, even if it is otherwise 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 To change the AM-key (/am/key) and AM-URI (/am/uri) resources, the 162 client needs a ticket that authorizes it to use PUT on these 163 resources. There are three possibilities for a client to get this 164 ticket: 166 o request a ticket from the former AM. 168 o use a preconfigured ticket. 170 With the help of the ticket, the constrained device can determine 171 that request is authorized. In DCAF, it can additionally be used to 172 establish a DTLS session between client and server. The new K_AM and 173 the URI of the new AM can then be securely transmitted to the Server. 175 The new K_AM MUST NOT be disclosed to others. If the authorization 176 ticket is requested from the former AM, the client MUST NOT include 177 the new K_AM in the Access Request Message. 179 If the client is not the new AM, the new K_AM MUST be transmitted to 180 the new AM and removed from the client. 182 5. Authorization Transitions in the Lifecycle of Constrained Nodes 184 The lifecycle of a constrained node can be roughly divided into six 185 phases. The device is created in the manufacturing phase. Devices 186 are then sold to customers who introduce them to their networks 187 during the commissioning phase. In the operation phase, constrained 188 nodes fullfill their purpose in life, sometimes alternated with a 189 maintenance phase. Some nodes are sold during their lifetime and 190 need to be decommissioned and recommissioned in the handover phase. 191 At the end of the node's lifecycle, the node is decommissioned in the 192 decommissioning phase. 194 Apart from the operation phase, mechanisms for changing the 195 authorization to authorize are needed in every phase of the 196 lifecycle. 198 5.1. Manufacturing 200 In the manufacturing phase, the manufacturer can choose one of the 201 following options for the initial key provisioning: 203 o Provisioning with AM service: K_AM is provisioned to the new node 204 and the manufacturer provides an Authorization Manager service. 206 o Provisioning only: K_AM is provisioned to the new node but the 207 manufacturer does not provide an Authorization Manager service. 209 o No provisioning: No K_AM is provisioned to the newly manufactured 210 node. 212 In the provisioning with AM service case, the manufacturer provides 213 an own AM service. Future principals can use the AM service to 214 request a ticket for their own AM or might even continue to use the 215 manufacturer's AM if they don't want to maintain their own. The 216 node's AM-URI resource is set to the URI of the manufacturer's AM. 217 Additionally, the manufacturer configures the K_AM keying material on 218 the AM and the constrained node. Depending on the used solution 219 shared symmetric keys or asymmetric key pairs are used. For 220 symmetric solutions, a shared secret must be generated and provided 221 to constrained node and AM. Each constrained node SHOULD be 222 provisioned with an individual unique key. For asymmetric solutions, 223 key pairs must be generated on the constrained node and the AM. The 224 AM's public key is stored as K_AM in the AM-key resource. 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 node has changed. 241 The new principal needs to be able to take over the control over the 242 node by defining authorization policies. To achieve this, principals 243 will either use the Authorization Manager service of the manufacturer 244 (if available) or need to assign a new Authorization Manager to the 245 node (see also Section 4). 247 To assign a new Authorization Manager, the procedure described in 248 Section 4 is used. 250 The constrained node MUST end all existing communications and delete 251 all Tickets that were issued by the former AM. 253 5.3. Decommissioning 255 If a device is discarded or sold, the principal of the node changes. 256 To make sure that nobody who gets hold of the device afterwards is 257 able to misuse it, permissions for the node must be revoked. 259 The constrained node must be deregistered from the AM. AM MUST NOT 260 issue any new tickets for the constrained node and SHOULD revoke 261 tickets on communication partners of this node. 263 Already existing tickets and session keys have to be removed from the 264 decommissioned node. 266 5.4. Handover 268 A change of ownership of a node often entails that the relationship 269 between the former AM and the constrained node must be canceled. 271 The exchange of the AM consists of a decomissioning as described in 272 Section 5.3 followed by a commissioning as described in Section 5.2. 273 Before the decommissioning, one of the mechanisms described in 274 Section 4 for the commissioning MUST be used to create an 275 authorization ticket for assigning the new AM. 277 5.5. Maintenance 279 During the lifecycle of a constrained node, Authorization Managers 280 sometimes need to be exchanged, e.g. because they are replaced by a 281 newer model. In this case, the former AM should issue a ticket for 282 the new AM before it is decommissioned. The AM-Key SHOULD be deleted 283 from the old AS to prevent it from issuing new tickets before the AM- 284 Key is changed. Old tickets issued by the AM do not need to be 285 revoked. 287 6. Security Considerations 289 o What do we do if the key for changing the AM is lost? 291 o K_AM must be protected. The entity that has K_AM is in control of 292 the constrained node. 294 o It might be difficult to protect a preconfigured K_AM. 296 o If the PSK is printed onto the device, everyone who has access to 297 the device can use it. 299 o If a new AM-key is transmitted this transmission must be protected 300 very well. 302 7. IANA Considerations 304 None 306 8. References 308 8.1. Normative References 310 [I-D.gerdes-ace-dcaf-authorize] 311 Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP 312 Authentication and Authorization Framework (DCAF)", draft- 313 gerdes-ace-dcaf-authorize-02 (work in progress), March 314 2015. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 318 RFC2119, March 1997, 319 . 321 8.2. Informative References 323 [I-D.ietf-ace-actors] 324 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 325 architecture for authorization in constrained 326 environments", draft-ietf-ace-actors-00 (work in 327 progress), August 2015. 329 Author's Address 330 Stefanie Gerdes 331 Universitaet Bremen TZI 332 Postfach 330440 333 Bremen D-28359 334 Germany 336 Phone: +49-421-218-63906 337 Email: gerdes@tzi.org