idnits 2.17.1 draft-sarikaya-core-sbootstrapping-02.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 73 has weird spacing: '...mmetric with ...' == Line 334 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 (June 22, 2011) is 4692 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RF4CE' is defined on line 776, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'C1222' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-pana-keywrap' is defined on line 842, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-17 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-rg-dex-05 == Outdated reference: A later version (-04) exists of draft-ohba-pana-keywrap-02 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Core B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Informational Y. Ohba 5 Expires: December 24, 2011 Toshiba 6 R. Moskowitz 7 ICSA Labs 8 Z. Cao 9 China Mobile 10 R. Cragie 11 Pacific Gas and Electric 12 June 22, 2011 14 Security Bootstrapping of Resource-Constrained Devices 15 draft-sarikaya-core-sbootstrapping-02 17 Abstract 19 This document describes how to initially configure the network of 20 resource constrained nodes securely, a.k.a., security bootstrapping. 21 Bootstrapping architecture, communication channel and bootstrap 22 security methods are described. System level objectives for security 23 bootstrapping are stated followed by the protocols that can be used. 24 Requirements on these protocols to be used as security bootstrapping 25 protocols are identified. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 24, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5 63 1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 6 65 2.1. Areas of Boostrapping . . . . . . . . . . . . . . . . . . 6 66 2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Communications Channel . . . . . . . . . . . . . . . . . . . . 8 68 3.1. Supported Communication Channels . . . . . . . . . . . . . 8 69 4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 9 70 4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.2. Asymmetric with User Authentication, Followed by 72 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. Asymmetric with Certificate Authority, Followed by 74 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.4. Cryptographically Generated Address Based Address 76 Ownership Verification . . . . . . . . . . . . . . . . . . 9 77 5. Bootstrapping Protocols . . . . . . . . . . . . . . . . . . . 10 78 5.1. System Level Objectives . . . . . . . . . . . . . . . . . 10 79 5.2. EAP Authentication Framework . . . . . . . . . . . . . . . 11 80 5.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.4. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 5.5. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 90 Appendix A. Examples of Node Configuration . . . . . . . . . . . 21 91 A.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 22 92 A.1.1. Initial Meter Installation . . . . . . . . . . . . . . 22 93 A.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 22 94 A.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 22 95 A.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 22 96 A.2.2. Adding a TV to a network with a DVD player and 97 remote . . . . . . . . . . . . . . . . . . . . . . . . 22 98 A.2.3. Providing GPS Location Data . . . . . . . . . . . . . 22 99 A.3. Commercial Building Automation . . . . . . . . . . . . . . 22 100 A.3.1. Light Installation . . . . . . . . . . . . . . . . . . 23 101 Appendix B. Example Exchanges . . . . . . . . . . . . . . . . . . 23 102 B.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 23 103 B.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 23 104 B.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 23 105 B.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 23 106 B.5. Consumer: Adding a TV to a network with a DVD player 107 and remote . . . . . . . . . . . . . . . . . . . . . . . . 24 108 B.6. Consumer: Providing GPS Location Data . . . . . . . . . . 26 109 B.7. Commercial: Building Automation . . . . . . . . . . . . . 26 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 112 1. Introduction 114 Familiarity with constrained network types is assumed here. 115 Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups 116 (WGs) would be a useful reference for the reader. In particular RFC 117 4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] and RFC 5673 118 [RFC5673] from ROLL, CoAP [I-D.ietf-core-coap] from CoRE, and a paper 119 by Romer and Mattern [ROMER04]. Familiarity with application 120 specific examples such as Zigbee or Smart Energy groups is assumed. 122 A summary of those will be presented, as far as network requirements 123 are concerned. The general network requirements will be further 124 concentrated into requirements surrounding only the bootstrapping 125 issues. 127 A number of solutions which are currently in use will be presented. 128 Requirements on each solution will be stated to enable their use as a 129 security bootstrapping protocol. 131 1.1. What is Bootstrapping? 133 Node configuration is known as bootstrapping in this document. 134 Bootstrapping is any processing required before the network can 135 operate. Typically this will require a number of settings to be 136 transferred between nodes at all layers. This could include anything 137 from link-layer information (i.e., wireless channels, link-layer 138 encryption keys) to application-layer information (i.e., network 139 names, application encryption keys). 141 Bootstrapping is complete when settings have been securely 142 transferred prior to normal operation in the network. 144 1.2. Why IETF? 146 The bootstrapping problem is not specific to any MAC or PHY. This 147 problem exists across any two nodes which have no previous knowledge 148 of each other. In particular, this problem is complicated when the 149 nodes are resource-constrained and may not have an advanced user 150 interface. The IETF is instrumental in defining standards which will 151 be used by The Internet of Things. Ensuring these standards can be 152 used across nodes and networks requires some form of bootstrapping 153 which any node can use. 155 Existing standards will be used as much as possible in this document. 156 The method proposed here should work across many different underlying 157 layers. It could be used to allow two nodes on the same physical 158 network to join at the physical layer, or allow two nodes on an 159 incompatible physical network to join at the IPv6 layer. 161 2. Bootstrapping Architecture 163 2.1. Areas of Boostrapping 165 In order to provide a flexible architecture, the bootstrapping method 166 is split into five distinct areas and two distinct phases. The five 167 areas are a 'user interface', 'bootstrap profile', 'security method', 168 'bootstrap protocol', and the 'communications channel'. 170 The phases are provisioning phase and bootstrapping phase. In the 171 provisioning phase, statically configured parameters (e.g., 172 certificates) needed for the bootstrapping phase is provisioned. In 173 the bootstrapping phase, dynamically configured information is set up 174 using the statically configured information provided in the 175 provisioning phase. 177 The user interface provides both user input and user output. Simple 178 nodes may only have a push-button and LED, more complex nodes may 179 have a graphical display and keyboard. The user interface (which 180 could be implemented as network management software graphical user 181 interface running at the remote end) provides interaction between the 182 user and bootstrapping methods. The user interface would be used 183 during bootstrapping as an OOB channel. It may also be used to 184 specify bootstrapping policies. 186 The user interface provides the interaction between the user and the 187 bootstrap protocol. The user interface will vary depending on the 188 capabilities of the node. Examples might include a push-button and 189 LED on simple nodes, to full-blown graphical user interfaces. Note 190 that a 'bootstrapping tool' used to initially deploy a network is 191 just a special user interface. This allows a very uniform protocol 192 in deployment and use of networks. 194 User interface is out-of-scope and will not be further discussed. 196 Two nodes communicate through some channel. For our purposes this is 197 split into the 'control channel' and 'data channel'. The control 198 channel is used for the bootstrap protocol, and the data channel is 199 used during normal network operation. A node may support multiple 200 control or data channels. When the control and data channels are the 201 same, the bootstrapping is done In Band (IB). When the control and 202 data channels are different, the bootstrapping is performed Out Of 203 Band (OOB). An 802.15.4 network for instance would use an 802.15.4 204 control channel for IB bootstrapping, but a control channel of 205 perhaps IrDA or USB for OOB bootstrapping. 207 The 'bootstrap profile', i.e. statically configured parameters during 208 the provisioning phase, defines what information should be exchanged 209 during the process. A single node may run the protocol multiple 210 times with different profiles. If the user wishes to associate a new 211 lightswitch, the protocol is first run with the '802.15.4 Wireless 212 Profile', through which it learns the channel and PAN-ID. The node 213 then runs a 'Security Exchange Profile' to learn the needed 214 encryption keys. Finally it runs a 'Lightswitch Association Profile' 215 through which it learns which light to associate with. 217 An example of the 'bootstrap profile' attribute is the 218 'administrative domain name'. 'Bootstrap profiles' are required to 219 be modified when the corresponding administrative domains are 220 changed, a.k.a. recommissioning. In recommissioning, the domains are 221 administratively repartitioned and nodes are therefore 222 recommissioned. 224 The 'security method' defines supported security methods for 225 bootstrapping. The supported security methods will depend on the 226 control channel and bootstrap profile. In one node if the control 227 channel is secure, then a simple clear-text security method is 228 supported. For example when a physical connection between two nodes 229 is used, the control channel is considered secure. However when the 230 control channel is not secure, this clear-text security method is not 231 supported. The 'bootstrap profile' additionally defines allowed 232 security methods. Higher security nodes may outlaw ever performing a 233 clear-text exchange, even if the control channel is deemed secure. 235 The 'bootstrap protocol' defines the actual messages exchanged during 236 bootstrapping. The messages are used to transfer between nodes data, 237 node information, and network state. The selected security method 238 runs on top of the control channel, such as EAP-GPSK etc. 240 2.2. Architecture 242 Security bootstrapping architecture is structured in a hierarchy of 243 nodes going from the least resource constraint to the most resource 244 constraint. At the top there is a root node. The root node is 245 called Coordinator or Trust Center in Zigbee and 6LowPAN Border 246 Router (6LBR) in 6LoWPAN ND. 248 At the next level there are interior Routers. Routers are able to 249 run a routing protocol between other routers and the root. Routers 250 are called 6LowPAN Routers (6BR) in 6LoWPAN ND. 252 At the lowest level there are the nodes. The nodes do not run a 253 routing protocol. They can connect to the nearest router over a 254 single radio link. The nodes are called End Devices in Zigbee and 255 hosts in in 6LoWPAN ND. 257 Routers first join the network as a node and go through security 258 bootstrapping operations in order to create a Master Session Key 259 (MSK). Next, routers execute routing protocol, e.g. 260 [I-D.ietf-roll-rpl] specific steps to create session keys with their 261 neighbors and to establish upstream and downstream next hop parents. 263 At each node hierarachy level described above, there are lower-layer 264 and higher-layer protocols to bootstrap their ciphering keys, where 265 the lower-layer refers to layers below IP layer including IEEE 266 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer 267 refers to IP layer and the above. In general, required bootstrapping 268 procedures depend on the bootstrapping protocols to use. Section 269 Section 5 describes the bootstrapping procedures where EAP 270 (Extensible Authentication Protocol) [RFC3748] and other protocols 271 are used as the bootstrapping protocols. 273 3. Communications Channel 275 The communications channel is the method used between two nodes to 276 communicate. There are two main communication channels: the 277 'control' and 'data' channels. The control channel is used during 278 bootstrapping, and the data channel is used during network operation. 280 3.1. Supported Communication Channels 282 There is no limit on what communications channels are supported. The 283 following gives an example of several supported channels: 285 o IEEE 802.15.4 287 o Power-Line Communications 289 o IrDA 291 o RFID 293 o Some simple physical link 295 o Cellular 297 o Ethernet 299 o IPv6 301 o Wi-Fi 303 Depending on the node's function, it may use different channels as 304 the data or control channel. Nodes may have multiple data and/or 305 control channels as wel. 307 4. Bootstrap Security Method 309 The bootstrap security method defines allowable security methods. A 310 node may choose to support or use a subset of these methods. This is 311 NOT the security architecture used for the application, but only the 312 security used during bootstrapping. Typically some high-security 313 method is used to generate a shared secret, which then switches to 314 simplier symmetric encryption to secure the actual bootstrapping 315 channel. The techniques negotiated should take advantage of hardware 316 resources available, such as hardware encryption accelerators on an 317 end node. 319 4.1. None 321 This is the simplist security method. No encryption or 322 authentication is provided, messages are exchanged completely in 323 clear-text. It is assumed some other layer provides security, such 324 as a physical connection between devices. 326 4.2. Asymmetric with User Authentication, Followed by Symmetric 328 A Diffie-Hellman style key exchange is used to generate a shared 329 secret. The authentication will be provided by the user, by 330 confirming cryptographic signatures between two devices. With the 331 shared secret generated through the DH, some symmetric encryption is 332 used to secure the actual bootstrapping channel. 334 4.3. Asymmetric with Certificate Authority, Followed by Symmetric 336 Public key exchanges are used (aka: DH again), but with a Certificate 337 Authority. Once a shared secret exists, symmetric encryption is used 338 to secure the actual bootstrapping channel. 340 4.4. Cryptographically Generated Address Based Address Ownership 341 Verification 343 A node may generate the global unique address using different 344 techniques other than the stateless address autoconfiguration. For 345 example, Cryptographically Generated Addresses (CGA) [RFC3972] is a 346 type of global unique address that can be used to verify the address 347 ownership. When the node uses CGA, it MUST execute SeND protocol 348 [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol 349 [I-D.ietf-6lowpan-nd] must be executed between the node and the edge 350 router. 352 5. Bootstrapping Protocols 354 In this section we first present system level objectives that 355 security bootstrapping protocols are expected to achieve. Next, we 356 present EAP authentication framework and then describe three 357 different protocols. 359 5.1. System Level Objectives 361 Authentication/ reauthentication: nodes joining the network MUST at 362 the first place authenticate to the trust center. In order to 363 achieve secure multi-hop routing, the node MUST authenticate to its 364 upstream and downstream neighbors. A bootstrapping solution MUST 365 support re-authentication of resource-constrained devices and re- 366 keying of dynamically generated keys. 368 Data Confidentiality: the data communication between two endpoints 369 MAY be encrypted using the derived key, avoiding being eavesdropped 370 by a non-trusted third part. 372 Data Integrity: the data communication between two endpoints MUST NOT 373 be altered by some intermediate nodes. The nodes should be able to 374 detect the non-integral data. 376 Keys and key freshness: the keys used for data communication MUST 377 have a lifetime, in order to keep their freshness. A bootstrapping 378 solution MUST support both symmetric and asymmetric key 379 authentication. If distribution of a key to be used for a resource- 380 constrained device is required, a bootstrapping solution MUST support 381 secure key distribution to prevent the key from eavesdropping, 382 alternation and replay attacks. 384 Multi domain support: A bootstrapping solution MUST be able to allow 385 resource-constrained devices that may be subscribed to different 386 administrative domains to be connected to the same access network at 387 the same time. 389 Multi domain support: A bootstrapping solution MUST be able to allow 390 resource-constrained devices to be recommissioned. Recommissioning a 391 device is defined to be (1) an resource-constrained device is 392 administratively switched to a different domain, or (2) acting a new 393 role with a different function set, or (3) both administrative domain 394 and function set are modified. 396 Identities: A bootstrapping solution MUST be able to allow a 397 resource-constrained device to use various types of identities used 398 for authentication, including device identities, user identities or 399 combinations of different types of identities. Also a bootstrapping 400 solution MUST be able to allow a resource-constrained device to 401 change its identities used for authentication over time. 403 Authentication infrastructure: A bootstrapping solution MUST be able 404 to operate with or without an authentication infrastructure. 406 5.2. EAP Authentication Framework 408 EAP is an authentication protocol that supports a number of 409 authentication algorithms called EAP methods [RFC5247]. EAP messages 410 can be transported in different layers: using 802.1X, EAP messages 411 are carried in Layer 2 and using PANA in IP or Layer 3 between EAP 412 peer and the authenticator. EAP messages between the authenticator 413 and authentication server are carried using AAA protocols (RADIUS or 414 Diameter). The associated AAA server address of each resource- 415 constrained device is assigned by the domain administrator. In the 416 recommissioning case, another AAA server is reassigned to devices by 417 the domain administrator if the device is switched to another domain. 419 At the end of a successful EAP method execution a master session key 420 (MSK) is generated at both the EAP peer and EAP server. 421 Authenticator receives MSK from EAP server at the end of EAP method 422 execution using key transport. MSK is used in deriving a session key 423 between the node and the authenticator using a protocol called secure 424 association protocol (SAP). Derivation of the session key terminates 425 bootstrapping of a node. 427 Additional keying material derived between EAP client and server that 428 is exported by the EAP method is called Extended Master Session Key 429 (EMSK). EMSK is not used in session key derivation but it could be 430 used for the needs of other applications in higher layer protocols. 432 In the architecture introduced in Section 2.2 the node or router is 433 the peer and the root is the authenticator. When the supplicant and 434 authenticator are one hop away the authenticator can be reached 435 directly. However, this is rarely the case. In other cases the 436 authenticator authenticates neighboring supplicants first. The 437 router nodes that are authenticated become relay authenticators in 438 the next phase and they relay authentication messages from the 439 supplicants to the authenticator and vice versa. This continues 440 until all nodes are authenticated. 442 EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request 443 messages sent by the server and EAP-Response messages sent by the 444 peer. At the end, the server indicates the status of authentication, 445 usually by EAP-Success message which also carries the MSK. The first 446 EAP-Request/Response pair is used for the server to request the 447 identity and the peer to provide it. In the other pairs of EAP 448 exchanges EAP method is executed. 450 Several EAP methods have been standardized each for different 451 purposes. To authenticate devices with certificates, EAP Transport 452 Layer Security (TLS) v1.2 specified in [RFC5216] which supports 453 certificate-based mutual authentication is used. 455 Zigbee Alliance's Smart Energy Profile 2.0 Application Protocol 456 Specification [SE2.0] mandates each device to be factory programmed 457 with a certificate. The certificate is bound to a unique network ID, 458 e.g. the device's MAC address or EUI-64 address. During EAP-Identity 459 exchange the EAP peer provides its EUI-64 address as an identity to 460 EAP server. This enables the server to validate the device 461 certificate. 463 There are three bootstrapping scenarios using EAP. 465 1. Use of EAP for bootstrapping link-layer security. 467 In this case, EAP is used for network access authentication to 468 bootstrap link-layer ciphering. Security for higher-layer (i.e., 469 IP layer and above) protocols is bootstrapped from an IB or OOB 470 mechanism other than EAP. 472 2. Use of EAP for bootstrapping higher-layer security. 474 In this case, EAP is used as an OOB mechanism for higher-layer 475 authentication to bootstrap ciphering keys for one or more 476 higher-layer protocols independently of network access 477 authentication. When bootstrapping Constrained Application 478 Protocol (CoAP) security with DTLS protection, a PSK (Pre-Shared 479 Key) credential in the combined usage of DTLS (Datagram Transport 480 Layer Security) [RFC4347] and PSK mode of TLS [RFC4279] is 481 derived from EAP key material and DTLS ciphering keys are 482 generated as a result of a successful DTLS handshake. Similarly, 483 when bootstrapping CoAP security with IPsec ESP protection, a PSK 484 credential of IKEv2 [RFC5996] is derived from EAP key material 485 and IPsec ESP ciphering keys are generated as a result of a 486 successful IKEv2 handshake. 488 The ability to bootstrap multiple higher-layer protocols from a 489 single execution of PANA authentication is important to save the 490 computational resources for resource-constrained devices 491 especially where public-key based authentication is used. 493 3. Use of EAP for bootstrapping both link-layer and higher-layer 494 security. 496 This case is the combination of the other two cases, and the most 497 optimized way for bootstrapping resource-constrained devices. 498 This case is only applicable where both the network access 499 authentication and the higher-layer authentication use the same 500 authentication server with the same authentication credentials. 502 The second and third scenarios are generally referred to as Single 503 Sign-On in Section 4.2.2.2 of [NISTIR7628VOL1], where the root keys 504 for higher-layer protocols can be derived from EAP EMSK (Extended 505 Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295]. 507 5.3. PANA 509 PANA (Protocol for carrying Authentication for Network Access) 510 [RFC5191] defines an EAP transport over UDP where a PANA Client (PaC) 511 is an EAP peer and a PANA Authentication Agent (PAA) is an EAP 512 authenticator. 514 PANA can achieve the authentication, key freshness and data 515 confidentiality objectives of security bootstrapping. 517 Multi domain operation is intrinsically supported due to the use of 518 EAP and AAA. 520 Even though PANA architecture consisting of PaC, PAA and AAA Server 521 is generic enough to be used in security bootstrapping, the 522 architecture introduced in Section 2.2 requires a new element called 523 PANA Relay Element (PRE). PRE is needed to enable PANA messaging 524 between a PaC and PAA because the two nodes cannot reach each other 525 by means of regular IP routing since only a link-local IPv6 address 526 can be used by PaC prior to the completion of a succesful 527 authentication. 529 PRE which is one hop away from PaC receives PANA messages and relays 530 the message contents (payload) by encapsulating it in a message 531 parameter called Attribute Value Pair (AVP). PRE also needs to send 532 header contents such as PaC's IP address and UDP port number in a 533 different AVP. PRE has IP routing established with PAA which could 534 be several hops away. PAA sends its reply messages in which the 535 payload is encapsulated in an AVP. It also adds the AVP containing 536 PaC's IP address and UDP port number. PRE creates a link local PDU 537 using these AVPs and sends it to PaC [I-D.ohba-pana-relay]. 539 The requirements for the use of PANA as a bootsrapping protocol can 540 be stated as follows: 542 o A new entity called PANA Relay Element may be added to the PANA 543 architecture. Behaviour of PANA Relay Element needs to be 544 defined. New AVPs needed for PANA Relay Element operation for 545 properly relaying messages from the client to the authenticator 546 and vice versa are required to be specified. 548 o An extension to PANA to securely distribute keys from the PANA 549 Authentication Agent to the PANA Client using AES Key Wrap with 550 Padding algorithm needs to be defined. This is needed in order to 551 use PANA for multicast group key distribution. 553 5.4. HIP-DEX 555 [RFC4423] introduces the Host Identity Protocol (HIP) where the Host 556 Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit 557 length Host Identity Tag (HIT) is derived from the HI (hashed) and 558 functions as an IPv6 address (/128 prefix) for applications. A four- 559 packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX) 560 establishes a security association (SA, similar to IKE), indexed by 561 the HITs, but independent of the IP address. So HIP can be 562 considered as a shim layer between the transport(TCP/UDP) and IP, 563 providing authentication, data confidentiality, mobility in one 564 basket. 566 As with IKE, HIP is typically used as a Key Management Protocol (KMP) 567 for ESP. However, HIP is independent of IP and ESP and can be used 568 for a KMP for any secure communication protocol at any level. Thus 569 HIP can provide keying material for the MAC, IP, and Transport 570 layers. HIP can be run directly over the MAC in an Ethernet Frame or 571 within an Information Element in a MAC control frame. HIP can be run 572 over UDP, traversing firewalls, and push keys over to Transport 573 security protocols like SRTP or (D)TLS. Further, HIP could start on 574 the MAC, then be enveloped over UDP after the first link. 576 The HIP-BEX involves many crypto primitives that are difficult to run 577 on constrained nodes. HIP Diet Exchange (HIP-DEX) 578 [I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight. 579 Basically, HIP-DEX a variant of the HIP-BEX specifically designed to 580 use as few crypto primitives as possible yet still provide the same 581 class of security features as HIP-BEX. 583 HIP-DEX can be used for mutual authentication between two endpoints. 584 After mutual authentication, the two endpints establish a shared 585 secret, which is fresh and fed into the encryption algorithm for data 586 confidentiality. So HIP-DEX can achieve the authentication, key 587 freshness and data confidentiality objectives of security 588 bootstrapping. 590 When a node wants to authenticate to the network using HIP and Diet- 591 HIP, it should be able to complete the HIP-BEX or HIP-DEX with the 592 trust anchor or some delegate. In HIP, it does not matter how many 593 domains, and nodes can authenticate each other as long as they have 594 the secret. 596 In the architecture introduced in Section 2.2 the node and router 597 could be the HIP end-points. Or the router could be a HIP Rendezvous 598 Server, with the node registering to the rendezvous server (RVS) 599 [RFC5204] to be reachable by other nodes. Typically the initial 600 interaction will have the node be the HIP DEX Initiator with the 601 router being the Responder. Using the RVS function on a Router any 602 node could be the Initiator with any other Responder node. As long 603 as there is IP connectivity between the Initiator and Responder, they 604 can be multiple hops away from each other. Alternatively if the 605 first hop from the Initiator has knowledge of the IP address of the 606 Responder, it can act as a MAC/IP gateway for HIP. 608 An important requirement for the HIP-DEX to work in the architecture, 609 the initiator should be able to get the IP address of the responder 610 or have a gateway function as a forwarder. The IP address can be 611 obtained from a 3rd party source like DNS of Distributed Hash Table 612 (DHT), from local configuration, or from an RVS. 614 5.5. 802.1X 616 IEEE 802.1X defines how EAP packets can be transported over in Layer 617 2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into 618 EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and 619 the authenticator. EAPOL can also be used in 802.11 wireless links. 621 To enable IEEE 802.15.4 devices to use EAP authentication, EAP 622 packets encapsulated in EAPOL frames can be carried as payload in 623 802.15.4 data frames [802.15.4]. EAPOL is well defined and widely 624 used and it lends itself to be easily carried in 802.15.4 data 625 frames. For this, Frame Type subfield of the Frame Control Field of 626 IEEE 802.15.4 MAC header needs to be set to a special value to 627 indicate the type of the payload, i.e. 802.1X encapsulated EAP 628 packets. EAPOL packets are encoded following common EAPOL PDU 629 structure defined in [802.1x] into the data payload field of 802.15.4 630 data frames. 632 Authentication proceeds as follows: authenticator authenticates the 633 supplicants that are on the next hop first. This enables a secure 634 link between the authenticator and these first-hop nodes. The 635 architecture introduced in Section 2.2 requires a new entity called 636 Relay Authenticator. First-hop nodes or router become Relay 637 Authenticators in the next phase of authentication. Relay 638 Authenticators tunnel EAPOL frames to the authenticator in the secure 639 link established. This way all the supplicants are gradually 640 authenticated. 642 After the keys are established from a successful EAP method (such as 643 PSK mode of TLS), the node runs neighbor discovery protocol to get an 644 IPv6 address assigned [I-D.ietf-6lowpan-nd]. Data transfer can be 645 secured using DTLS or IPSec. Keys derived from EAP TLS are used in 646 either generating DTLS ciphering keys after a successful DTLS 647 handshake or IPSec ESP ciphering keys after a successful IKEv2 648 handshake. 650 802.1X can achieve the authentication, key freshness and data 651 confidentiality objectives of security bootstrapping. 653 Multi domain operation is intrinsically supported due to the use of 654 EAP and AAA. In order to support a device recommissioning case 655 whereby the device's administrative domain is modified, after a new 656 AAA server address assigned and a successful 802.1X method execution, 657 the old set of device 'name and password' MUST be overwritten into 658 the device by a new set of 'name and password' that are assigned by 659 the domain administrator. The device MUST be rebooted to execute EAP 660 method again for authentication and a new master session key MUST be 661 generated. 663 The requirements for the use of 802.1X defined EAPOL as a 664 bootsrapping protocol can be stated as follows: 666 o A special value in the Frame Type subfield of the Frame Control 667 Field of IEEE 802.15.4 MAC header to indicate the type of the 668 payload, 670 o Link Layer Multicast Group addresses for 802.15.4 corresponding to 671 EAPOL Group Address Assignments defined in Table 11.1 of [802.1x], 672 especially to be used in EAPOL-Start packet. 674 o Which MAC frames of beacon, data, acknowledgment and MAC command 675 as defined in [802.15.4] with what security levels are mapped to 676 controlled port, which MAC frames with what security levels are 677 mapped to uncontrolled port and which MAC frames are never mapped 678 to any of controlled/uncontrolled port (i.e., the payload of those 679 frames are used by the MAC-ayer ieself and never used by upper 680 layers). 682 o A new entity called Relay Authenticator may be added to the 802.1x 683 architecture. Behaviour of Relay Authenticator needs to be 684 defined. 686 6. Security Considerations 688 When security bootstrapping resource constraint nodes is undertaken, 689 several attacks are possible and security bootstrapping methods 690 described in this document do not protect the nodes against such 691 attacks. These attacks are similar to the ones described in 692 [RFC3971] and mainly stem from unsecured link layer. Link layer must 693 be secured on each node before the node can begin security 694 bootstrapping. 696 If a bootstrapping protocol does not rely on a pre-shared key for 697 peer authentication, it must rely on an online or offline third-party 698 (e.g., an authentication server, a key distribution center in 699 Kerberos, a certification authority in PKI, a private key generator 700 in ID-based cryptography and so on) to prevent man-in-the-middle 701 attacks during peer authentication. Depending on use cases, a 702 resource-constrained device may not always have access to an online 703 third-party for peer authentication. 705 Depending on use cases, a bootstrapping protocol may deal with 706 authorization separately from authentication in terms of timing and 707 signaling path. For example, two resource-constrained devices A and 708 B may perform mutual authentication using authentication credentials 709 provided by an offline third-party X whereas resource-constrained 710 device A obtains authorization for running a particular application 711 with resource-constrained device B from an online third-party Y 712 before or after the authentication. In some use cases, 713 authentication and authorization are tightly coupled, e.g., 714 successful authentication also means successful authorization. A 715 bootstrapping protocol supports various types of authentication and 716 authorization or different bootstrapping protocols may be used for 717 different types of authentication and authorization. 719 If authorization information includes cryptographic keys, a special 720 care must be taken for dealing with the keys, e.g., guidelines for 721 AAA-based key management are described in [RFC4962]. A 722 recommissioning use case may require revocation and re-installation 723 of authentication credentials (i.e., a certificate or a shared secret 724 and identity information, etc.) to a large number of resource- 725 constrained devices that are already deployed. Re-installation of 726 authentication credentials must be as secure as the initial 727 installation regardless of whether the re-installation is done 728 manually or automatically. 730 If resource-constrained devices use a multicast group key for peer 731 authentication or message authentication or encryption, the group key 732 must be securely distributed to the current members of the group for 733 both initial key distribution and key update. Protocols designed for 734 group key management such as GSAKMP [RFC4535], GDOI [RFC3547] and 735 MIKEY [RFC3830] may be used for group key distribution. 736 Alternatively, key wrap attributes for securely encapsulating group 737 key may be defined in network access authentication protocols such as 738 PANA [RFC5191] and EAP-TTLSv0 [RFC5281]. Those protocols use an end- 739 to-end, point-to-point communication channel with a pair-wise 740 security association between a key distribution center and each key 741 recipient. Further considerations may be needed for more efficient 742 group key management to support a large number of resource- 743 constrained devices. 745 7. IANA Considerations 747 This memo includes no request to IANA. 749 8. Contributors 751 The people listed below have made significant text contributions to 752 this document. 754 Colin O'Flynn 756 colin.oflynn@atmel.com 758 9. Acknowledgements 760 Thanks to Zach Shelby for editing, comments, and overall assistance. 761 Special thanks also to Rene Struik, Carsten Borman, Gary Yang and 762 Alper Yegin for their comments that helped us improve the writing. 764 10. References 766 10.1. Normative References 768 [802.15.4] 769 IEEE Std 802.15.4-2006, "Wireless Medium Access Control 770 (MAC) and Physical Layer (PHY) Specifications for Low Rate 771 Wireless Personal Area Networks (WPANs)", September 2006. 773 [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network 774 Access Control", February 2010. 776 [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version 777 1.00", March 2009. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 783 Levkowetz, "Extensible Authentication Protocol (EAP)", 784 RFC 3748, June 2004. 786 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 787 over Low-Power Wireless Personal Area Networks (6LoWPANs): 788 Overview, Assumptions, Problem Statement, and Goals", 789 RFC 4919, August 2007. 791 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 792 Yegin, "Protocol for Carrying Authentication for Network 793 Access (PANA)", RFC 5191, May 2008. 795 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 796 Authentication Protocol", RFC 5216, March 2008. 798 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 799 "Routing Requirements for Urban Low-Power and Lossy 800 Networks", RFC 5548, May 2009. 802 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 803 "Industrial Routing Requirements in Low-Power and Lossy 804 Networks", RFC 5673, October 2009. 806 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 807 sensor networks", IEEE Wireless Communications, vol. 11, 808 no. 6, pp. 54-61, December 2004. 810 [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical 811 Requirements Document", April 2010. 813 10.2. Informative References 815 [C1222] American National Standard, "Protocol Specification For 816 Interfacing to Data Communication Networks", ANSI C12.22- 817 2008, 2008. 819 [I-D.ietf-6lowpan-nd] 820 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 821 Discovery Optimization for Low Power and Lossy Networks 822 (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), 823 June 2011. 825 [I-D.ietf-core-coap] 826 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 827 "Constrained Application Protocol (CoAP)", 828 draft-ietf-core-coap-06 (work in progress), May 2011. 830 [I-D.ietf-roll-rpl] 831 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 832 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 833 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 834 Lossy Networks", draft-ietf-roll-rpl-19 (work in 835 progress), March 2011. 837 [I-D.moskowitz-hip-rg-dex] 838 Moskowitz, R., "HIP Diet EXchange (DEX)", 839 draft-moskowitz-hip-rg-dex-05 (work in progress), 840 March 2011. 842 [I-D.ohba-pana-keywrap] 843 Chakrabarti, S., Cragie, R., Duffy, P., Ohba, Y., and A. 844 Yegin, "Protocol for Carrying Authentication for Network 845 Access (PANA) Extension for Key Wrap", 846 draft-ohba-pana-keywrap-02 (work in progress), 847 February 2011. 849 [I-D.ohba-pana-relay] 850 Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 851 Yegin, "Protocol for Carrying Authentication for Network 852 Access (PANA) Relay Element", draft-ohba-pana-relay-03 853 (work in progress), February 2011. 855 [NISTIR7628VOL1] 856 The Smart Grid Interoperability Panel - Cyber Security 857 Working Group, "Guidelines for Smart Grid Cyber Security: 858 Vol. 1, Smart Grid Cyber Security Strategy, Architecture, 859 and High-Level Requirements", NISTIR 7628, vol. 1, 2010. 861 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 862 Group Domain of Interpretation", RFC 3547, July 2003. 864 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 865 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 866 August 2004. 868 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 869 Neighbor Discovery (SEND)", RFC 3971, March 2005. 871 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 872 RFC 3972, March 2005. 874 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 875 for Transport Layer Security (TLS)", RFC 4279, 876 December 2005. 878 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 879 Security", RFC 4347, April 2006. 881 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 882 (HIP) Architecture", RFC 4423, May 2006. 884 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 885 "GSAKMP: Group Secure Association Key Management 886 Protocol", RFC 4535, June 2006. 888 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 889 Authorization, and Accounting (AAA) Key Management", 890 BCP 132, RFC 4962, July 2007. 892 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 893 Rendezvous Extension", RFC 5204, April 2008. 895 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 896 Authentication Protocol (EAP) Key Management Framework", 897 RFC 5247, August 2008. 899 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 900 Protocol Tunneled Transport Layer Security Authenticated 901 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 903 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 904 "Specification for the Derivation of Root Keys from an 905 Extended Master Session Key (EMSK)", RFC 5295, 906 August 2008. 908 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 909 "Internet Key Exchange Protocol Version 2 (IKEv2)", 910 RFC 5996, September 2010. 912 Appendix A. Examples of Node Configuration 914 Before any detail on methods is explored, the following section will 915 provide various examples this document could cover. Exact 916 requirements will be brought forward in subsequent sections. For the 917 reader's general understanding this section is placed to give an idea 918 of an acceptable usage scenario. 920 A.1. Smart Energy 922 A.1.1. Initial Meter Installation 924 The meter is initially loaded with code and network keys through a 925 physical interface at the factory. The meter is installed at a 926 customers home, and configured by the installer through the backbone 927 link (via GSM modem, etc). Both operations can be performed through 928 methods defined herein. 930 A.1.2. Home Expansions 932 The user wishes to join a thermostat onto the network. They press a 933 button on the thermostat, which enters join mode. They press a 934 button on the smart meter, which allows nodes to join the network. 935 The devices both have displays, so they display a certain number 936 which the user verifies match on both devices. The thermostat has 937 now securely joined the network. 939 A.2. Consumer Products 941 A.2.1. Connecting DVD Remote to DVD Player 943 The user pushes a join button on the DVD remote and DVD player. The 944 devices find each other, and blink in unison to indicate to the user 945 which two devices will join. The user presses the button to confirm 946 this, and the two devices are now joined together. 948 A.2.2. Adding a TV to a network with a DVD player and remote 950 The user then presses the join button on the DVD player and TV. The 951 devices again find each other and blink in unison, with the addition 952 that the remote control also blinks to indicate it is present in the 953 network. 955 A.2.3. Providing GPS Location Data 957 A user has a simple GPS receiver (that has no user interface) they 958 wish to broadcast location data with. The user switches on their 959 camera, and enters a PIN from the base of the GPS. The user can now 960 view GPS information such as satellite health from their camera. In 961 addition photos are automatically tagged with location information. 963 A.3. Commercial Building Automation 964 A.3.1. Light Installation 966 The electrician installs the light fixture. Each light has a barcode 967 printed on it. They use a handheld barcode scanner tool, which acts 968 as the commissioning tool. When they scan a barcode with the tool, 969 the tool asks the electrician to enter some additional information 970 such as light fixture location. The tool securely registers the 971 light fixture on the network, along with setting parameters inside 972 the light fixture. 974 Appendix B. Example Exchanges 976 The following details how the protocol handles certain conditions and 977 situations through examples. Note that each example is a more 978 detailed description of the examples in Appendix A. 980 B.1. Smart Energy: Meter Manufacture 982 B.2. Smart Energy: Meter Installation 984 B.3. Smart Energy: Home Expansion 986 B.4. Consumer: Connecting DVD Remote to DVD Player 988 Supported User Interface Profiles 990 +----------------+------------+----------------+ 991 | Profile | DVD Player | Remote Control | 992 +----------------+------------+----------------+ 993 | none | Y | Y | 994 | simple | Y | Y | 995 | numerical | Y | N | 996 | alphanumerical | Y | N | 997 | Graphical | Y | N | 998 +----------------+------------+----------------+ 1000 Supported Bootstrap Transport Layers 1002 +----------+------------+----------------+ 1003 | Layer | DVD Player | Remote Control | 1004 +----------+------------+----------------+ 1005 | Physical | Y | Y | 1006 | 802.15.4 | Y | Y | 1007 | IrDA | Y | N | 1008 +----------+------------+----------------+ 1009 Supported Security Methods 1011 +------------------+------------+----------------+ 1012 | Method | DVD Player | Remote Control | 1013 +------------------+------------+----------------+ 1014 | None | Y | Y | 1015 | EAP | Y | N | 1016 | Asymmetric, User | Y | Y | 1017 | Asymmetric, CA | Y | N | 1018 +------------------+------------+----------------+ 1020 The DVD player and remote control have a number of ways in which they 1021 could be joined together. The remote control does not have any 1022 unique identifier printed on it, thus no pre-shared key can be 1023 identified. This leaves either an unsecure joining method, or some 1024 asymmetric security method. 1026 The remote control has a button on it for 'join', as does the DVD 1027 player. The user pushes the button on the DVD player, and then 1028 pushes the button on the remote control. Based on the UI profile, 1029 this causes the following to occur: 1031 o DVD Player scans for existing network in advertise mode. Finding 1032 none, it starts a new network and that network enters advertise 1033 mode. 1035 o The DVD remote scans for a network, and then finds the DVD 1036 player's network. 1038 o The devices generate a shared secret (ie: Diffie-Hellman), and 1039 both blink their LED in a unique pattern based on this shared 1040 secret. 1042 o The user user confirms both devices are blinking the same pattern, 1043 as both LEDs are blinking in unison. 1045 o The DVD player displays 'JOIN OK' on it's LCD panel. 1047 B.5. Consumer: Adding a TV to a network with a DVD player and remote 1049 This network will have three devices: a TV, a DVD Player, and a 1050 Remote Control. The user will run the bootstrap protocol between the 1051 TV and Remote Control in this example, although it could also be run 1052 between the TV and DVD player. 1054 Supported User Interface Profiles 1056 +----------------+----+----------------+ 1057 | Profile | TV | Remote Control | 1058 +----------------+----+----------------+ 1059 | none | Y | Y | 1060 | simple | Y | Y | 1061 | numerical | Y | N | 1062 | alphanumerical | Y | N | 1063 | Graphical | Y | N | 1064 +----------------+----+----------------+ 1066 Supported Bootstrap Transport Layers 1068 +----------+----+----------------+ 1069 | Layer | TV | Remote Control | 1070 +----------+----+----------------+ 1071 | Physical | Y | Y | 1072 | 802.15.4 | Y | Y | 1073 | IrDA | Y | N | 1074 +----------+----+----------------+ 1076 Supported Security Methods 1078 +------------------+----+----------------+ 1079 | Method | TV | Remote Control | 1080 +------------------+----+----------------+ 1081 | None | Y | Y | 1082 | EAP-GPSK | Y | N | 1083 | Asymmetric, User | Y | Y | 1084 | Asymmetric, CA | Y | N | 1085 +------------------+----+----------------+ 1087 The TV and remote control have a number of ways in which they could 1088 be joined together. The remote control does not have any unique 1089 identifier printed on it, thus no pre-shared key can be identified. 1090 This leaves either an unsecure joining method, or some asymmetric 1091 security method. 1093 The remote control has a button on it for 'join', as does the TV. In 1094 this example two sequence will be considered: where the TV button is 1095 pressed first, and where the remote control button is pressed first. 1097 If the TV join button is pressed first: 1099 o TV scans for existing networks in advertise mode. Finding none, 1100 it starts a new network and that network enters advertise mode. 1102 o The remote scans for a network, and then finds the TV's network. 1104 o The remote informs the TV it is on an existing network, and thus 1105 will require the TV to join this network. 1107 o The devices generate a shared secret, and both blink their LED in 1108 a unique pattern. 1110 o The DVD player in addition blinks, so the user is informed that if 1111 they confirm the join action the resulting network will have all 1112 three devices in it. 1114 o The user confirms both devices are blinking the same pattern, as 1115 both LEDs are blinking in unison. 1117 o The TV displays 'JOIN OK' onscreen, along with any information 1118 about the network it just joined. 1120 If the remote control join button is pressed first: 1122 o Remote control scans for existing networks in advertise mode. 1123 Finding none, it advertises it's network. 1125 o The TV scans for a network, and then finds the remote control's 1126 network. 1128 o The devices generate a shared secret, and both blink their LED in 1129 a unique pattern. 1131 o The DVD player in addition blinks, so the user is informed that if 1132 they confirm the join action the resulting network will have all 1133 three devices in it. 1135 o The user confirms both devices are blinking the same pattern, as 1136 both LEDs are blinking in unison. 1138 o The TV displays 'JOIN OK' onscreen, along with any information 1139 about the network it just joined. 1141 B.6. Consumer: Providing GPS Location Data 1143 B.7. Commercial: Building Automation 1144 Authors' Addresses 1146 Behcet Sarikaya 1147 Huawei USA 1148 1700 Alma Dr. Suite 500 1149 Plano, TX 75075 1151 Email: sarikaya@ieee.org 1153 Yoshihiro Ohba 1154 Toshiba 1155 Tokyo, Japan 1157 Email: yoshihiro.ohba@toshiba.co.jp 1159 Robert Moskowitz 1160 ICSA Labs 1161 100 Bent Creek Blvd. St. 200 1162 Mechanicsburg, PA 17050 1164 Email: robert.moskowitz@icsalabs.com 1166 Zhen Cao 1167 China Mobile 1168 Beijing, China 1170 Email: caozhen@chinamobile.com 1172 Robert Cragie 1173 Pacific Gas and Electric 1174 89 Greenfield Crescent 1175 Wakefield, UK WF4 4WA 1177 Email: robert.cragie@gridmerge.com