idnits 2.17.1 draft-jennings-core-transitive-trust-enrollment-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 13, 2012) is 4212 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-coap' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 482, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-05) exists of draft-arkko-core-dev-urn-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco 4 Intended status: Experimental October 13, 2012 5 Expires: April 16, 2013 7 Transitive Trust Enrollment for Constrained Devices 8 draft-jennings-core-transitive-trust-enrollment-00 10 Abstract 12 This is a copy of the paper sent to the "Smart Object Security" 13 workshop March 23, 2012 in Paris. It is submitted as an IETF draft 14 to have a record of it in the draft archive. The original 15 publication date of this work was Feb 14, 2012. Readers are 16 encouraged to read later versions of this draft. 18 This document provides a very early sketch of a enrollment protocol 19 that allows constrained internet devices to securely enroll into a 20 system. As the work is in its early phase, many details remain to be 21 resolved. The solution is based on the idea that each device will be 22 manufactured with a one time password that can be used by the 23 customer to tell the device which controller to enroll with. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 16, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 Secure enrollment of devices into internet-based systems has never 60 been easy. The constrained devices that need to be enrolled into 61 systems today face many challenges. Typically, simple devices have 62 no user interface such as a keyboard or screen - they may have only a 63 single button or LED. At the time they are installed, there may not 64 be a working network or even power. However, these devices are being 65 used for applications that are increasingly important and safety- 66 critical, so they need to have reasonable security and privacy 67 characteristics. This documents specifies an enrollment system for 68 such devices. 70 In many systems, there is a need to configured a Device, such as a 71 sensor or actuator, so that it is controlled by some specific 72 controller. In the case Devices like a switch and light, it may be 73 that all the Controller does is later configure the switch to control 74 the light. To make this happen, both Devices need to be under the 75 control of a common Controller that is authorized to make changes to 76 the Devices. 78 The simplified high-level information flow is illustrated in the 79 following figure. The goal is to get to the point where the Device 80 knows that it should be talking to the Controller. 81 TODO ASCII FIGURE 83 When the Manufacturer builds the Device, it includes a One Time 84 Password (OTP) that the Introducer can use to enroll the Device with 85 the Controller. The Manufacturer also runs a website known as the 86 MotherShip that knows the OTP for every device that Manufacturer 87 builds. The Device can include the OTP as a QR code on the outside 88 of the Device. When the Device is installed, the installer uses a 89 software agent known as the Introducer. The Introducer would 90 typically be something like an application running on an iPhone. 91 When the Device is installed, the Introducer can scan the QR code on 92 the Device to find the OTP (Message 1). The Introducer then contacts 93 the MotherShip and uses the OTP to tell the MotherShip which 94 Controller this Device is should use (Message 3). Later, the first 95 time the Device boots up and gets network connectivity, it contacts 96 the MotherShip, and the MotherShip tells the Device which Controller 97 to talk to (Message 3). From that point on, any time the Device 98 boots, the Device can communicate directly with the Controller 99 (Message 4). The actual message flow is slightly more complicated 100 and shown in Section 2, but it uses the same basic idea as this 101 simplified flow. 103 The system is designed to achieve several desirable properties: 104 o Can work for Devices with very limited memory and processing power 105 o Does not require network or power to be up when the Device is 106 installed 107 o Is fairly secure (see more in the security section) 108 o Minimal addition to manufacturing costs 109 o The installer can detect if the OTP has already been used 110 o Provides a work flow in which a Device does not need to be taken 111 out of the box to be enrolled. This can be very important to 112 enable consumers themselves to enroll devices they buy from a 113 service provider. 114 o Works with common Firewall and NAT network topologies 116 One of the key steps in making this system work is getting the OTP 117 from the Device to Introducer. There are several ways that could 118 happen but a few of the approaches considered here are: 120 o Using a QR code or other bar code printed on the Device and/or box 121 it comes in 122 o Having a single LED on the Device that blinks out the OTP 123 information and using a video capture application on the 124 Introducer to read this 125 o The manufacture providing the OTP in some other machine readable 126 form 127 o Including the OTP in an RFID tag on the Device that can be read by 128 the Introducer 129 o Having an electrical interface (such as one wire memory) on the 130 Device that can be read by the Introducer 132 The semantic level information in each message is discussed in 133 Section 2 and the syntax of the messages is discussed in Section 3. 134 The security properties of the system are described in Section 4. 136 2. Enrollment Information Flow 138 The Manufacturer, Device, MotherShip, Introducer, and Controller are 139 abbreviated M,D,MS,I,C respectively. The Device, MotherShip, and 140 Controller all use CoAP to communicate with each other and thus each 141 have an asymmetric key pair that is used to form the DTLS connections 142 between them. The MotherShip acts as an HTTP server to communicate 143 with the Introducer and Controller. The MotherShip needs a normal 144 certificate to use HTTPS. 146 It is assumed that the Device may have a NAT between it and the 147 Controller and that the Device is on the inside of the NAT. The 148 MotherShip is assumed to be a generally accessible server on the 149 internet but the Controller and Device can be on the inside of a 150 Firewall or NAT between them and the MotherShip. 152 In the following message flow we use the following definitions: 153 Fingerprint This refers to a hash of the DTLS public key used by the 154 associated network element. "MS Fingerprint" means a fingerprint 155 of the public key that the MotherShip will use when forming CoAP 156 connections over DTLS. 157 MS ID A 32-bit integer that uniquely identifies the MotherShip. 158 Section 3.4 explains how to use the MS ID to create a URL that can 159 be used to contact the MotherShip. 160 Dev ID A 32-bit integer that identifies the Device and when combined 161 with the MotherShip is unique. Two Devices that use the same 162 MotherShip cannot have the same Dev ID. 163 Dev URN A globally unique URN assigned by the Manufacturer to 164 uniquely identify this Device. This SHOULD be one of the URNs 165 from [I-D.arkko-core-dev-urn]. 166 OTP The One Time Password created by the Manufacturer for enrolling 167 the Device. This is a cryptographically random 64-bit integer. 168 C Addr Address of the Controller. This is an IPv4 or IPv6 address 169 and port which the Device can use to form a CoAP connection to the 170 Controller. 171 Dev Descp A locally significant string that the Introducer can 172 assign to a Device. For example, the convention for a thermostat 173 in building 30, floor2, office 361 might be assign the string 174 "BLD30/2/361 - Thermostat". This string is provided purely as a 175 way to let the Introducer and Controller exchange information that 176 may be useful for the Installer. 177 Dev Status The Controller can query the MotherShip for the 178 enrollment status of a Device that is enrolled with that 179 Controller. The various states returned are defined in 180 Section 3.2. 182 The information flow is illustrated in the following figure. The 183 goal is get to the point where the Device knows that it should be 184 talking to the Controller, the Controller knows it should be talking 185 the Device, and the Device and Controller can communicate using CoAP 186 and authenticate each other using their public keys. 187 TODO ASCII FIGURE 189 When the Manufacturer builds the Device, it includes a One Time 190 Password (OTP) on the Device and MotherShip (Message 1 and 2). When 191 the Device is installed, the Introducer reads OTP and other 192 information from the Device (Message 3). The Introducer then uses 193 the OTP to tell the MotherShip which Controller this Device should 194 use (Message 4 and 5). Later the Device contacts the MotherShip and 195 tells the Device which Controller to talk to, information that the 196 Device saves in non-volatile memory (Message 9 and 10). From that 197 point on, any time the Device boots, it can directly communicate with 198 the Controller (Message 11 and 12). 200 The Introducer has the option of informing Controller about any 201 Devices that it has enrolled with this Controller (Message 6). The 202 Controller can optionally contact the MotherShip to find out about 203 the status of any Devices that it has not heard from (Messages 7 and 204 8). 205 participant Manufacturer 206 participant Device 207 participant MotherShip 208 participant Introducer 209 participant Controller 211 Manufacturer-->Device: 1 MS ID,MS Fingerprint,\nDev ID, OTP 212 Manufacturer-->MotherShip: 2 Dev URN, Dev ID, OTP 213 note right of Introducer: User tells I:\n C Addr, Dev Desc 214 Device-->Introducer: 3 MS ID, Dev ID, OTP 215 Introducer->MotherShip: 4 Dev ID, OTP,\nC Addr, C Fingerprint 216 MotherShip->Introducer: 5 Dev URN,\nDev Fingerprint 217 Introducer->Controller: 6 Dev URN,\nDev Fingerprint, \nOTP, Dev Desc 218 Controller->MotherShip: 7 Dev URN, OTP 219 MotherShip->Controller: 8 Dev State 220 Device->MotherShip: 9 Dev URN 221 MotherShip->Device: 10 Addr,\n C Fingerprint 222 Device->Controller: 11 Hello 223 Controller->Device: 12 HelloAck 225 When the Device is built, it needs to be assigned a globally unique 226 URN, a Dev ID, and a MotherShip. A single manufacturer MAY operate 227 many MotherShips as each one can only support 16 million Devices. A 228 perfectly reasonable way to generate the Dev ID is to use the least 229 significant 32 bits of the Device URN. The Device needs to be 230 programmed with the IP address and port of the MotherShip along with 231 the fingerprint of the public key that the MotherShip will use in the 232 DTLS CoAP exchange. 234 The creation of the MotherShip domain name is discussed in 235 Section 3.4. The QR code for the Device MUST be an HTTPS URL that 236 points at the appropriate MotherShip and MUST include a URL parameter 237 called "otp" that is set to OTP represented in hexadecimal and MUST 238 include a URL parameter called "devid" that is set to the Device ID 239 represented in hexadecimal. It MUST use the default HTTP port and 240 MUST have an absolute path of /.well-known/tte. As an example, if 241 the MotherShip's domain name was ""tte-000000.net", the OTP was 242 0x123456789abcdef0 and the Device ID was 0xABCDEF01, a valid URL 243 would be: 245 https://tte-000000.net/.well-known/tte? 246 otp=123456789abcdef0,DevID=abcdef01 248 The QR code SHOULD use an error coding level of "H". This would 249 generate the following QR code: 251 QR code in ASCII art left as an exercise 252 to the reader but there is one in the PDF version. 254 The Introducer reads the QR code found and the Device, then uses this 255 URL to contact the MotherShip in messages 4 and 5. This URL is 256 referred to as the Enrollment URL . 258 Messages 4 and 5 MUST be sent over TLS, and the Introducer MUST 259 verify that the HTTPS certificate of the MotherShip matches the URL. 260 The Introducer can perform either an HTTPS GET or POST. If the 261 Introducer does a GET, it MUST make an HTTPS GET request to the 262 Enrollment URL and MUST act as a web browser to process returned HTML 263 pages. In the case of a GET, the MotherShip MUST return a web page 264 that allows the user to enter the IP address and port of the 265 Controller as well as the fingerprint of the Controller's public key 266 used in CoAP. If the Controller does not wish to act as a web 267 browser, instead of using the GET, it will use a PUT. When using a 268 PUT, the Controller MUST make an HTTPS POST request to a URL formed 269 by appending three parameters to the Enrollment URL. The parameters 270 are cip, which MUST have the IP address of the Controller; cport, 271 which MUST have the port of the Controller; and cfingerprint, which 272 MUST have the fingerprint of the Controller's Public Key, represented 273 in hexadecimal. If, and only if, the MotherShip successfully stores 274 the address information, the POST MUST return an HTTP 200 response 275 with a JSON string containing the URN and Fingerprint for that 276 Device. The format of this object is described in Section 3.2. 278 Once the MotherShip has successfully stored the Controller's address 279 for a given OTP, it MUST NOT allow that OTP to be used again to store 280 an address for that Device. The OTP can be used after this to query 281 the status of the enrollment as described in Section 3.2. 283 Message 6 is optional and MAY be omitted. As some point after the 284 Introducer has successfully mapped the Device to the Controller, it 285 can send an HTTP or HTTPS request to the Controller to notify it that 286 it can expect to hear from a particular Device. The message formats 287 for this are defined in Section 3.3. This does not need happen 288 immediately and the information can be saved so it can be done far in 289 the future. This might happen if Devices were being installed before 290 the Controller was even operational. In other cases it might be done 291 immediately. (TODO - look at in web browser case having MotherShip 292 redirect Introducer to Controller after successful Introduction.) 293 This is done with an HTTP POST to TBD URL with parameters to convey 294 the Device URN and Fingerprint learned from the MotherShip, the OTP 295 password, and a locally significant description string that can be 296 used to help label the Device for management reasons. 298 In the case where the Controller has learned the URN and OTP for a 299 given Device, it MAY query the MotherShip to find out the enrollment 300 status. It does this with an HTTP GET request to TBD URL. The 301 various statuses that can be returned in TBD JSON doc are: revoked, 302 not mapped, mapped, registered. TODO - could use better names and 303 descriptions. 305 When the Device has powered up and has network connectivity for the 306 first time, it attempts to form a CoAP connection to the MotherShip. 307 The Device makes a CoAP GET request to TBD URL, passing its URN as a 308 parameter. Details of this message are provided in Section 3.1. The 309 Device MUST check that the Public Key provided by the MotherShip in 310 the DTLS connection matches the fingerprint provided by the 311 Manufacturer. The MotherShip needs to look at the Public Key 312 provided in the DTLS and ensure that it matches the fingerprint for 313 this Device that was provided by the Manufacturer. If everything 314 does match, the MotherShip MUST return (in Message 10) the IP address 315 and port for the Controller as well as the Fingerprint for the 316 Controller's public key. Details for the syntax of these messages 317 are provided in Section 3.1. If this is successful, the Device MUST 318 store the address and fingerprint for the Controller in non-volatile 319 memory and, on future reboots, skip all the steps before this and 320 connect directly to the Controller. (TODO - Define how retries work 321 if the Device has not yet been enrolled.) 323 At this point, the Device can form a CoAP connection to the 324 Controller. The Device can verify that it is speaking to the correct 325 Controller by checking that the DTLS Public Key matches the 326 fingerprint for the Controller that was retrieved from the 327 MotherShip. If the Introducer has contacted the Controller in 328 message 6, then the Controller will already have the fingerprint of 329 the Device and can verify that it matches the DTLS information in the 330 connection between the Device and the Controller. 332 The Controller MAY be configured such that if it does not have the 333 information from Message 6 it can ignore the Device until it gets the 334 information from the Introducer, or, alternatively, such that it can 335 accept the connection based purely on the fact that the network was 336 configured to send messages to the Controller. 338 3. Message Formats 340 This section is missing from the current draft and will be completed 341 in future revisions once feedback on the overall design and been 342 incorporated. 344 3.1. Device Enrollment Query 346 TODO - define well known COAP URL on MotherShip that the Device uses 347 to get information about Controller. 349 3.2. JSON Enrollment States 351 TODO - Define a JSON object with Device URN, Device public key or 352 fingerprint, and enrollment state. 354 3.3. Controller Enrollment Messages 356 TODO - define HTTP messages to allow Introducer to tell Controller 357 about a new Device. Need a way for Introducer to tell Controller, 358 the Device public key or fingerprint, the Device URN, and the locally 359 significant label string, and the OTP. 361 3.4. MotherShip ID and URLs 363 This system requires a programmatic way to go from a MotherShip ID, 364 which is a 32-bit integer, to an address that can be used to contact 365 that MotherShip. The approach here is to use DNS for that mapping. 366 For a MotherShip ID that has a high order byte of 0x00, the DNS host 367 name of the MotherShip if formed by prepending "tte-" to the lower 368 order 24 bits of the MotherShip ID represented in hexadecimal, and 369 then appending ".net". So the host name for the MotherShip ID 10 370 would be "tte-00000A.net". MotherShip IDs that have a high order 371 byte other than 0x00 are reserved for future specifications. 373 A Manufacturer gets a MotherShip ID simply be registering the 374 corresponding DNS entry. The MotherShip ID zero is reserved for 375 examples and MUST NOT be treated as a valid ID by operational 376 systems. A manufacturer wishing to have more than 2^32 Devices would 377 simply register multiple MotherShip IDs. 379 4. Security Considerations 381 This section has not really been started and needs lots of work. 383 TODO - Discuss how one can replace a dead Controller with a new one 384 in an operational network. The short answer is likely that one needs 385 to back up the private keys of the old Controller and move these to 386 the new Controller. 388 What happens if the OTP is stolen during Device transit? The short 389 answer is that the Device is compromised at this point and needs to 390 be discarded or returned to the manufacture to get a new Device ID 391 and OTP. The Introducer needs to detect that this has happened and 392 warn the user. 394 There are additional concerns about Devices that may be operational 395 without ever being introduced to a Controller. For example, if a 396 light switch supported this protocol, but could also be used just as 397 a stand alone light switch, there is a risk the OTP could be stolen 398 by an attacker, with the attacker enrolling the Device to the 399 attacker's Controller. When the correct user installs the light 400 switch, if they never bother to try to Introduce it to anything, they 401 will not detect that it has been compromised. One way to mitigate 402 this risk in situations where it exists might be to include some 403 manual configuration on the Device to indicate that it is to be used 404 in stand-alone mode, such as a jumper that can be cut. 406 Network topology consideration - Introducer can install firewall 407 rules that allow Devices to contact MotherShip. 409 why works with NATs / FWs. 411 5. Variations 413 5.1. LED Based Enrollment 415 An alternative to QR codes is to have an LED on the Device flash out 416 the relevant information to the Introducer. The output string is 417 formed by concatenating a 16-bit start of message constant value of 418 0x0001, followed by the MotherShip ID, Device ID, OTP, and then an 419 8-bit two's compliment checksum value computed over the previous 420 bytes, including the start of message constant. All values are in 421 network byte order. The resulting string is output using Non-Return- 422 to-Zero Inverted (NRZI) encoding on the LED at a baud rate of 15 bps. 423 This allows a Device such as a smartphone with video capture to 424 detect the signal and recover the information. 426 TODO - see if this works at 30 bps. See about encoding multiple 427 intensity levels or colors in the LED. Initial experiments indicate 428 this does not work very well as auto contrast in the video camera 429 tends to saturate LED range. Would an Adler-32 checksum be better? 431 5.2. Bulk Enrollment 433 Imagine one wants to enroll a whole box of sensors. We should define 434 some scheme where one can simply bar code something on the outside of 435 a box and can bulk enroll all the sensors in the box. Perhaps have a 436 scheme where there is a master secret and start and end Device ID on 437 the outside of box bar code. Then the OTP for a given Device is 438 generated using the master secret and DeviceID of that Device. Need 439 to sort out details of a scheme like this. 441 5.3. No Public Key Crypto 443 The examples here assumed that COAP was being used with DTLS with 444 asymmetric keys. It would also be possible to use DTLS in Pre Shared 445 Key (PSK) mode in a very similar flow, where the Introducer provided 446 the MotherShip with the PSK to be used between the Device and the 447 Controller. 449 6. Open Issues 451 The references section is in serious need of work - let me know stuff 452 that should be added to it. 454 Does QR encoding of L work out better than H? 456 Is there any advantage in having the HTTP URL in well-known space? 458 Is there some clever way (perhaps zeroconf) for the Introducer to 459 discover the Controller's information? 461 7. IANA Considerations 463 TODO - create registry for the top byte of MotherShip ID 465 TODO register .well-known HTTP URL 467 8. Acknowledgments 469 Some of the fundamental ideas in this draft where inspired by Max 470 Pritikin's work. I'd like to thank the following people for review 471 comments: Eric Rescorla 473 9. References 475 9.1. Normative References 477 [I-D.ietf-core-coap] 478 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 479 "Constrained Application Protocol (CoAP)", 480 draft-ietf-core-coap-08 (work in progress), October 2011. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 9.2. Informative References 487 [I-D.arkko-core-dev-urn] 488 Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource 489 Names for Device Identifiers", draft-arkko-core-dev-urn-01 490 (work in progress), October 2011. 492 Author's Address 494 Cullen Jennings 495 Cisco 496 170 West Tasman Drive 497 San Jose, CA 95134 498 USA 500 Phone: +1 408 421-9990 501 Email: fluffy@cisco.com