idnits 2.17.1 draft-oflynn-core-bootstrapping-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 == Line 83 has weird spacing: '...mmetric with ...' == Line 321 has weird spacing: '...mmetric with ...' == 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 (July 12, 2010) is 5036 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 439, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-10 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Core C. O'Flynn 3 Internet-Draft Atmel Corporation 4 Intended status: Informational B. Sarikaya 5 Expires: January 13, 2011 Huawei USA 6 R. Cragie 7 Pacific Gas and Electric 8 July 12, 2010 10 Initial Configuration of Resource-Constrained Devices 11 draft-oflynn-core-bootstrapping-01 13 Abstract 15 The Internet of Things is marching its way towards completion. Nodes 16 can use standards from the 6LoWPAN and ROLL WG to achieve IP 17 connectivity. IEEE Standards ensure connectivity at lower layers for 18 resource-constrained devices. Yet a central problem remains at a 19 more basic layer without a suitable answer: how to initially 20 configure the network. Without configuration the network never 21 advances beyond a large box of nodes. Current solutions tend to be 22 specific to a certain vendor, node type, or application. 24 This document outlines exactly what problems are faced in solving 25 this problem. General problems faced in any low-power wireless 26 network are outlined first; followed by how these apply to 27 bootstrapping. A selection of currently proposed techniques is 28 presented. From these a more generic approach is presented, which 29 can solve the problem for a wide range of situations. 31 An emphasis is on performing this bootstrapping in a secure manner. 32 This document does not cover operation of the network securely. This 33 document does provide the basis for allowing the network to operate 34 securely however, by providing standard methods for key exchanges and 35 authentication. 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 January 13, 2011. 54 Copyright Notice 56 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 73 1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.3. Why a New Standard? . . . . . . . . . . . . . . . . . . . 5 75 2. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 5 76 3. Communications Channel . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Supported Communication Channels . . . . . . . . . . . . . 7 78 4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 7 79 4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.3. Asymmetric with User Authentication, Followed by 82 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.4. Asymmetric with Certificate Authority, Followed by 84 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.5. Cryptographically Generated Address Based Address 86 Ownership Verification . . . . . . . . . . . . . . . . . . 8 87 5. Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . . . 8 88 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 96 Appendix A. Examples of Node Configuration . . . . . . . . . . . 11 97 A.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 11 98 A.1.1. Initial Meter Installation . . . . . . . . . . . . . . 11 99 A.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 11 100 A.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 11 101 A.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 11 102 A.2.2. Adding a TV to a network with a DVD player and 103 remote . . . . . . . . . . . . . . . . . . . . . . . . 12 104 A.2.3. Providing GPS Location Data . . . . . . . . . . . . . 12 105 A.3. Commercial Building Automation . . . . . . . . . . . . . . 12 106 A.3.1. Light Installation . . . . . . . . . . . . . . . . . . 12 107 Appendix B. Example Exchanges . . . . . . . . . . . . . . . . . . 12 108 B.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 12 109 B.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 12 110 B.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 12 111 B.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 13 112 B.5. Consumer: Adding a TV to a network with a DVD player 113 and remote . . . . . . . . . . . . . . . . . . . . . . . . 14 114 B.6. Consumer: Providing GPS Location Data . . . . . . . . . . 16 115 B.7. Commercial: Building Automation . . . . . . . . . . . . . 16 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 118 1. Introduction 120 Familiarity with constrained network types is assumed here. 121 Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups 122 (WGs) would be a useful reference for the reader. In particular RFC 123 4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] and RFC 5673 124 [RFC5673] from ROLL, and a paper by Romer and Mattern [ROMER04]. 125 Familiarity with application specific examples is also useful, such 126 as Zigbee or Smart Energy groups. 128 A summary of those will be presented, as far as network requirements 129 are concerned. The general network requirements will be further 130 concentrated into requirements surrounding only the bootstrapping 131 issues. 133 A number of solutions which are currently in use will be presented 134 and compared to the requirements. From these the requirements of the 135 final solution is identifiable, and a proposal is made on this. 137 Note this document has considerable extra information that is not 138 designed to be worked into the final I-D. It also has some example 139 specifications of particular applications that would not be present 140 in the final version as they are out of scope of the proposed working 141 group. As a general guide they are very useful, but realistically 142 will be split off to either another I-D or some other location. 144 1.1. What is Bootstrapping? 146 Node configuration is known as bootstrapping in this document. 147 Bootstrapping is any processing required before the network can 148 operate. Typically this will require a number of settings to be 149 transferred between nodes at all layers. This could include anything 150 from link-layer information (i.e., wireless channels, link-layer 151 encryption keys) to application-layer information (i.e., network 152 names, application encryption keys). 154 Bootstrapping is complete when settings have been securely 155 transferred prior to normal operation in the network. 157 1.2. Why IETF? 159 The bootstrapping problem is not specific to any MAC or PHY. This 160 problem exists across any two nodes which have no previous knowledge 161 of each other. In particular, this problem is complicated when the 162 nodes are resource-constrained and may not have an advanced user 163 interface. The IETF is instrumental in defining standards which will 164 be used by The Internet of Things. Ensuring these standards can be 165 used across nodes and networks requires some form of bootstrapping 166 which any node can use. 168 Existing standards will be used as much as possible in this document. 169 The method proposed here should work across many different underlying 170 layers. It could be used to allow two nodes on the same physical 171 network to join at the physical layer, or allow two nodes on an 172 incompatible physical network to join at the IPv6 layer. 174 1.3. Why a New Standard? 176 Simply put, no existing standard brings together all the required 177 aspects. At lower layers, standards exist to solve the problem in 178 special cases. Examples are Wi-Fi Protected Setup, Bluetooth 179 Pairing, or ZigBee solutions such as Zigbee RF4CE [RF4CE]. As will 180 be discussed later, these are not flexible enough to run on the wide 181 variety of nodes which a smart network will use. 183 At higher layers, standards exist to perform a secure authentication 184 or service discovery. However these standards almost always assume 185 the two nodes have some existing way of communicating, such as being 186 plugged into the same network. This will often not be the case. 188 Thus this document is aimed to bridge this gap. Many existing 189 standards can be applied to solve the problem (e.g. EAP), but some 190 guidance on their use is required to ensure all implementations 191 interoperate. 193 2. Bootstrapping Architecture 195 In order to provide a flexible architecture, the bootstrapping method 196 is split into five distinct areas. The five areas are a 'user 197 interface', 'bootstrap profile', 'security method', 'bootstrap 198 protocol', and the 'communications channel'. 200 The user interface provides both user input and user output. Simple 201 nodes may only have a push-button and LED, more complex nodes may 202 have a graphical display and keyboard. The user interface provides 203 interaction between the user and bootstrapping methods. The user 204 interface would be used during bootstrapping as an OOB channel. It 205 may also be used to specify bootstrapping policies. 207 The user interface provides the interaction between the user and the 208 bootstrap protocol. The user interface will vary depending on the 209 capabilities of the node. Examples might include a push-button and 210 LED on simple nodes, to full-blown graphical user interfaces. Note 211 that a 'bootstrapping tool' used to initially deploy a network is 212 just a special user interface. This allows a very uniform protocol 213 in deployment and use of networks. 215 User interface is out-of-scope and will not be further discussed. 217 Two nodes communicate through some channel. For our purposes this is 218 split into the 'control channel' and 'data channel'. The control 219 channel is used for the bootstrap protocol, and the data channel is 220 used during normal network operation. A node may support multiple 221 control or data channels. When the control and data channels are the 222 same, the bootstrapping is done In Band (IB). When the control and 223 data channels are different, the bootstrapping is performed Out Of 224 Band (OOB). An 802.15.4 network for instance would use an 802.15.4 225 control channel for IB bootstrapping, but a control channel of 226 perhaps IrDA or USB for OOB bootstrapping. 228 The 'bootstrap profile' defines what information should be exchanged 229 during the process. A single node may run the protocol multiple 230 times with different profiles. If the user wishes to associate a new 231 lightswitch, the protocol is first run with the '802.15.4 Wireless 232 Profile', through which it learns the channel and PAN-ID. The node 233 then runs a 'Security Exchange Profile' to learn the needed 234 encryption keys. Finally it runs a 'Lightswitch Association Profile' 235 through which it learns which light to associate with. 237 The 'security method' defines supported security methods for 238 bootstrapping. The supported security methods will depend on the 239 control channel and bootstrap profile. In one node if the control 240 channel is secure, then a simple clear-text security method is 241 supported. For example when a physical connection between two nodes 242 is used, the control channel is considered secure. However when the 243 BTL is not secure, this clear-text security method is not supported. 244 The 'bootstrap profile' additionally defines allowed security 245 methods. Higher security nodes may outlaw ever performing a clear- 246 text exchange, even if the control channel is deemed secure. 248 The 'bootstrap protocol' defines the actual messages exchanged during 249 bootstrapping. The messages are used to transfer between nodes data, 250 node information, and network state. The selected security method 251 runs on top of the control channel, such as EAP-GPSK etc. 253 3. Communications Channel 255 The communications channel is the method used between two nodes to 256 communicate. There are two main communication channels: the 257 'control' and 'data' channels. The control channel is used during 258 bootstrapping, and the data channel is used during network operation. 260 3.1. Supported Communication Channels 262 There is no limit on what communications channels are supported. The 263 following gives an example of several supported channels: 265 o IEEE 802.15.4 267 o Power-Line Communications 269 o IrDA 271 o RFID 273 o Some simple physical link 275 o Cellular 277 o Ethernet 279 o IPv6 281 o Wi-Fi 283 Depending on the node's function, it may use different channels as 284 the data or control channel. Nodes may have multiple data and/or 285 control channels as wel. 287 4. Bootstrap Security Method 289 The bootstrap security method defines allowable security methods. A 290 node may choose to support or use a subset of these methods. This is 291 NOT the security architecture used for the application, but only the 292 security used during bootstrapping. Typically some high-security 293 method is used to generate a shared secret, which then switches to 294 simplier symmetric encryption to secure the actual bootstrapping 295 channel. The techniques negotiated should take advantage of hardware 296 resources available, such as hardware encryption accelerators on an 297 end node. 299 4.1. None 301 This is the simplist security method. No encryption or 302 authentication is provided, messages are exchanged completely in 303 clear-text. It is assumed some other layer provides security, such 304 as a physical connection between devices. 306 4.2. EAP Methods 308 EAP-TLSv1.2 can be used as the authentication method [RFC5246]. 310 EAP-GPSK can be used as the authentication method [RFC5433]. Keys 311 must be pre-shared through some other method. 313 4.3. Asymmetric with User Authentication, Followed by Symmetric 315 A Diffie-Hellman style key exchange is used to generate a shared 316 secret. The authentication will be provided by the user, by 317 confirming cryptographic signatures between two devices. With the 318 shared secret generated through the DH, some symmetric encryption is 319 used to secure the actual bootstrapping channel. 321 4.4. Asymmetric with Certificate Authority, Followed by Symmetric 323 Public key exchanges are used (aka: DH again), but with a Certificate 324 Authority. Once a shared secret exists, symmetric encryption is used 325 to secure the actual bootstrapping channel. 327 4.5. Cryptographically Generated Address Based Address Ownership 328 Verification 330 A node may generate the global unique address using different 331 techniques other than the stateless address autoconfiguration. For 332 example, Cryptographically Generated Addresses (CGA) [RFC3972] is a 333 type of global unique address that can be used to verify the address 334 ownership. When the node uses CGA, it MUST execute SeND protocol 335 [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol 336 [I-D.ietf-6lowpan-nd] must be executed between the node and the edge 337 router. 339 5. Bootstrap Protocol 341 The bootstrap protocol defines several messages which can be sent 342 over the BTL. The bootstrap protocol is a small wrapper around the 343 standard authentication functions used, such as EAP etc. The 344 bootstrap protocol will negotiate allowable standards between nodes. 345 When a TV is joining a remote control for example, the bootstrap 346 protocol must understand that the remote control has very limited 347 feedback to the user. Hence the method selected must not rely on a 348 complex user interface on the remote, even though the TV has a 349 complex interface available. 351 Specifics TBD. 353 6. Conclusion 355 Initial configuration of a network is essential to interoperability. 356 This process is known as bootstrapping, and a variety of solutions 357 have been proposed previously. An analysis of the requirements shows 358 that no single solution is likely to meet all the requirements, 359 instead multiple solutions will be picked. At least one of these 360 must remain capable of running on the most resource constrained 361 nodes, ensuring that all nodes are capable of at least a single 362 common communication channel. 364 This document helps to focus on a method of solving this problem in a 365 flexible and extensible way. It is very much a work in progress, and 366 is expected to undergo radical changes before it becomes complete. 367 Please comment on the mailing list or add missing sections as you see 368 fit. 370 7. Security Considerations 372 TBD. 374 8. IANA Considerations 376 None. 378 9. Acknowledgements 380 Thanks to Zach Shelby for editing, comments, and overall assistance. 382 10. IANA Considerations 384 This memo includes no request to IANA. 386 All drafts are required to have an IANA considerations section (see 387 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 388 for a guide). If the draft does not require IANA to do anything, the 389 section contains an explicit statement that this is the case (as 390 above). If there are no requirements for IANA, the section will be 391 removed during conversion into an RFC by the RFC Editor. 393 11. References 394 11.1. Normative References 396 [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version 397 1.00", March 2009. 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 403 Levkowetz, "Extensible Authentication Protocol (EAP)", 404 RFC 3748, June 2004. 406 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 407 over Low-Power Wireless Personal Area Networks (6LoWPANs): 408 Overview, Assumptions, Problem Statement, and Goals", 409 RFC 4919, August 2007. 411 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 412 "Routing Requirements for Urban Low-Power and Lossy 413 Networks", RFC 5548, May 2009. 415 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 416 "Industrial Routing Requirements in Low-Power and Lossy 417 Networks", RFC 5673, October 2009. 419 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 420 sensor networks", IEEE Wireless Communications, vol. 11, 421 no. 6, pp. 54-61, December 2004. 423 11.2. Informative References 425 [I-D.ietf-6lowpan-nd] 426 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 427 Discovery Optimization for Low-power and Lossy Networks", 428 draft-ietf-6lowpan-nd-10 (work in progress), June 2010. 430 [I-D.narten-iana-considerations-rfc2434bis] 431 Narten, T. and H. Alvestrand, "Guidelines for Writing an 432 IANA Considerations Section in RFCs", 433 draft-narten-iana-considerations-rfc2434bis-09 (work in 434 progress), March 2008. 436 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 437 June 1999. 439 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 440 Text on Security Considerations", BCP 72, RFC 3552, 441 July 2003. 443 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 444 Neighbor Discovery (SEND)", RFC 3971, March 2005. 446 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 447 RFC 3972, March 2005. 449 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 450 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 452 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 453 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 454 RFC 5433, February 2009. 456 Appendix A. Examples of Node Configuration 458 Before any detail on methods is explored, the following section will 459 provide various examples this document could cover. Exact 460 requirements will be brought forward in subsequent sections. For the 461 reader's general understanding this section is placed to give an idea 462 of an acceptable usage scenario. 464 A.1. Smart Energy 466 A.1.1. Initial Meter Installation 468 The meter is initially loaded with code and network keys through a 469 physical interface at the factory. The meter is installed at a 470 customers home, and configured by the installer through the backbone 471 link (via GSM modem, etc). Both operations can be performed through 472 methods defined herein. 474 A.1.2. Home Expansions 476 The user wishes to join a thermostat onto the network. They press a 477 button on the thermostat, which enters join mode. They press a 478 button on the smart meter, which allows nodes to join the network. 479 The devices both have displays, so they display a certain number 480 which the user verifies match on both devices. The thermostat has 481 now securely joined the network. 483 A.2. Consumer Products 485 A.2.1. Connecting DVD Remote to DVD Player 487 The user pushes a join button on the DVD remote and DVD player. The 488 devices find each other, and blink in unison to indicate to the user 489 which two devices will join. The user presses the button to confirm 490 this, and the two devices are now joined together. 492 A.2.2. Adding a TV to a network with a DVD player and remote 494 The user then presses the join button on the DVD player and TV. The 495 devices again find each other and blink in unison, with the addition 496 that the remote control also blinks to indicate it is present in the 497 network. 499 A.2.3. Providing GPS Location Data 501 A user has a simple GPS receiver (that has no user interface) they 502 wish to broadcast location data with. The user switches on their 503 camera, and enters a PIN from the base of the GPS. The user can now 504 view GPS information such as satellite health from their camera. In 505 addition photos are automatically tagged with location information. 507 A.3. Commercial Building Automation 509 A.3.1. Light Installation 511 The electrician installs the light fixture. Each light has a barcode 512 printed on it. They use a handheld barcode scanner tool, which acts 513 as the commissioning tool. When they scan a barcode with the tool, 514 the tool asks the electrician to enter some additional information 515 such as light fixture location. The tool securely registers the 516 light fixture on the network, along with setting parameters inside 517 the light fixture. 519 Appendix B. Example Exchanges 521 The following details how the protocol handles certain conditions and 522 situations through examples. Note that each example is a more 523 detailed description of the examples in Appendix A. 525 B.1. Smart Energy: Meter Manufacture 527 B.2. Smart Energy: Meter Installation 529 B.3. Smart Energy: Home Expansion 530 B.4. Consumer: Connecting DVD Remote to DVD Player 532 Supported User Interface Profiles 534 +----------------+------------+----------------+ 535 | Profile | DVD Player | Remote Control | 536 +----------------+------------+----------------+ 537 | none | Y | Y | 538 | simple | Y | Y | 539 | numerical | Y | N | 540 | alphanumerical | Y | N | 541 | Graphical | Y | N | 542 +----------------+------------+----------------+ 544 Supported Bootstrap Transport Layers 546 +----------+------------+----------------+ 547 | Layer | DVD Player | Remote Control | 548 +----------+------------+----------------+ 549 | Physical | Y | Y | 550 | 802.15.4 | Y | Y | 551 | IrDA | Y | N | 552 +----------+------------+----------------+ 554 Supported Security Methods 556 +------------------+------------+----------------+ 557 | Method | DVD Player | Remote Control | 558 +------------------+------------+----------------+ 559 | None | Y | Y | 560 | EAP | Y | N | 561 | Asymmetric, User | Y | Y | 562 | Asymmetric, CA | Y | N | 563 +------------------+------------+----------------+ 565 The DVD player and remote control have a number of ways in which they 566 could be joined together. The remote control does not have any 567 unique identifier printed on it, thus no pre-shared key can be 568 identified. This leaves either an unsecure joining method, or some 569 asymmetric security method. 571 The remote control has a button on it for 'join', as does the DVD 572 player. The user pushes the button on the DVD player, and then 573 pushes the button on the remote control. Based on the UI profile, 574 this causes the following to occur: 576 o DVD Player scans for existing network in advertise mode. Finding 577 none, it starts a new network and that network enters advertise 578 mode. 580 o The DVD remote scans for a network, and then finds the DVD 581 player's network. 583 o The devices generate a shared secret (ie: Diffie-Hellman), and 584 both blink their LED in a unique pattern based on this shared 585 secret. 587 o The user user confirms both devices are blinking the same pattern, 588 as both LEDs are blinking in unison. 590 o The DVD player displays 'JOIN OK' on it's LCD panel. 592 B.5. Consumer: Adding a TV to a network with a DVD player and remote 594 This network will have three devices: a TV, a DVD Player, and a 595 Remote Control. The user will run the bootstrap protocol between the 596 TV and Remote Control in this example, although it could also be run 597 between the TV and DVD player. 599 Supported User Interface Profiles 601 +----------------+----+----------------+ 602 | Profile | TV | Remote Control | 603 +----------------+----+----------------+ 604 | none | Y | Y | 605 | simple | Y | Y | 606 | numerical | Y | N | 607 | alphanumerical | Y | N | 608 | Graphical | Y | N | 609 +----------------+----+----------------+ 611 Supported Bootstrap Transport Layers 613 +----------+----+----------------+ 614 | Layer | TV | Remote Control | 615 +----------+----+----------------+ 616 | Physical | Y | Y | 617 | 802.15.4 | Y | Y | 618 | IrDA | Y | N | 619 +----------+----+----------------+ 620 Supported Security Methods 622 +------------------+----+----------------+ 623 | Method | TV | Remote Control | 624 +------------------+----+----------------+ 625 | None | Y | Y | 626 | EAP-GPSK | Y | N | 627 | Asymmetric, User | Y | Y | 628 | Asymmetric, CA | Y | N | 629 +------------------+----+----------------+ 631 The TV and remote control have a number of ways in which they could 632 be joined together. The remote control does not have any unique 633 identifier printed on it, thus no pre-shared key can be identified. 634 This leaves either an unsecure joining method, or some asymmetric 635 security method. 637 The remote control has a button on it for 'join', as does the TV. In 638 this example two sequence will be considered: where the TV button is 639 pressed first, and where the remote control button is pressed first. 641 If the TV join button is pressed first: 643 o TV scans for existing networks in advertise mode. Finding none, 644 it starts a new network and that network enters advertise mode. 646 o The remote scans for a network, and then finds the TV's network. 648 o The remote informs the TV it is on an existing network, and thus 649 will require the TV to join this network. 651 o The devices generate a shared secret, and both blink their LED in 652 a unique pattern. 654 o The DVD player in addition blinks, so the user is informed that if 655 they confirm the join action the resulting network will have all 656 three devices in it. 658 o The user confirms both devices are blinking the same pattern, as 659 both LEDs are blinking in unison. 661 o The TV displays 'JOIN OK' onscreen, along with any information 662 about the network it just joined. 664 If the remote control join button is pressed first: 666 o Remote control scans for existing networks in advertise mode. 667 Finding none, it advertises it's network. 669 o The TV scans for a network, and then finds the remote control's 670 network. 672 o The devices generate a shared secret, and both blink their LED in 673 a unique pattern. 675 o The DVD player in addition blinks, so the user is informed that if 676 they confirm the join action the resulting network will have all 677 three devices in it. 679 o The user confirms both devices are blinking the same pattern, as 680 both LEDs are blinking in unison. 682 o The TV displays 'JOIN OK' onscreen, along with any information 683 about the network it just joined. 685 B.6. Consumer: Providing GPS Location Data 687 B.7. Commercial: Building Automation 689 Authors' Addresses 691 Colin Patrick O'Flynn 692 Atmel Corporation 693 Colorado Springs, Colorado 694 USA 696 Phone: 697 Email: colin.oflynn@atmel.com 699 Behcet Sarikaya 700 Huawei USA 701 1700 Alma Dr. Suite 500 702 Plano, TX 75075 704 Email: sarikaya@ieee.org 706 Robert Cragie 707 Pacific Gas and Electric 708 89 Greenfield Crescent 709 Wakefield, UK WF4 4WA 711 Email: robert.cragie@gridmerge.com