idnits 2.17.1 draft-sarikaya-core-sbootstrapping-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 85 has weird spacing: '...mmetric with ...' == Line 346 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 (January 24, 2011) is 4840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RF4CE' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'RFC5433' is defined on line 847, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-04 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-17 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-rg-dex-02 == Outdated reference: A later version (-04) exists of draft-ohba-pana-keywrap-01 == Outdated reference: A later version (-03) exists of draft-ohba-pana-relay-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- 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 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 17 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: July 28, 2011 Toshiba 6 Z. Cao 7 China Mobile 8 R. Cragie 9 Pacific Gas and Electric 10 January 24, 2011 12 Security Bootstrapping of Resource-Constrained Devices 13 draft-sarikaya-core-sbootstrapping-01 15 Abstract 17 The Internet of Things is marching its way towards completion. Nodes 18 can use standards from the 6LoWPAN and ROLL WG to achieve IP 19 connectivity. IEEE Standards ensure connectivity at lower layers for 20 resource-constrained devices. Yet a central problem remains at a 21 more basic layer without a suitable answer: how to initially 22 configure the network. Without configuration the network never 23 advances beyond a large box of nodes. Current solutions tend to be 24 specific to a certain vendor, node type, or application. 26 This document outlines exactly what problems are faced in solving 27 this problem. General problems faced in any low-power wireless 28 network are outlined first; followed by how these apply to 29 bootstrapping. A selection of currently proposed techniques is 30 presented. From these a more generic approach is presented, which 31 can solve the problem for a wide range of situations. 33 An emphasis is on performing this bootstrapping in a secure manner. 34 This document does not cover operation of the network securely. This 35 document does provide the basis for allowing the network to operate 36 securely however, by providing standard methods for key exchanges and 37 authentication. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on July 28, 2011. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5 75 1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 6 77 2.1. Areas of Boostrapping . . . . . . . . . . . . . . . . . . 6 78 2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 79 3. Communications Channel . . . . . . . . . . . . . . . . . . . . 8 80 3.1. Supported Communication Channels . . . . . . . . . . . . . 8 81 4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 9 82 4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.2. Asymmetric with User Authentication, Followed by 84 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.3. Asymmetric with Certificate Authority, Followed by 86 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 87 4.4. Cryptographically Generated Address Based Address 88 Ownership Verification . . . . . . . . . . . . . . . . . . 9 89 5. Bootstrap Protocols . . . . . . . . . . . . . . . . . . . . . 10 90 5.1. System Level Objectives . . . . . . . . . . . . . . . . . 10 91 5.2. EAP Authentication Framework . . . . . . . . . . . . . . . 11 92 5.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 5.4. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 5.5. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 101 Appendix A. Examples of Node Configuration . . . . . . . . . . . 20 102 A.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 20 103 A.1.1. Initial Meter Installation . . . . . . . . . . . . . . 20 104 A.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 20 105 A.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 20 106 A.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 21 107 A.2.2. Adding a TV to a network with a DVD player and 108 remote . . . . . . . . . . . . . . . . . . . . . . . . 21 109 A.2.3. Providing GPS Location Data . . . . . . . . . . . . . 21 110 A.3. Commercial Building Automation . . . . . . . . . . . . . . 21 111 A.3.1. Light Installation . . . . . . . . . . . . . . . . . . 21 112 Appendix B. Example Exchanges . . . . . . . . . . . . . . . . . . 21 113 B.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 21 114 B.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 21 115 B.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 21 116 B.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 22 117 B.5. Consumer: Adding a TV to a network with a DVD player 118 and remote . . . . . . . . . . . . . . . . . . . . . . . . 23 120 B.6. Consumer: Providing GPS Location Data . . . . . . . . . . 25 121 B.7. Commercial: Building Automation . . . . . . . . . . . . . 25 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 124 1. Introduction 126 Familiarity with constrained network types is assumed here. 127 Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups 128 (WGs) would be a useful reference for the reader. In particular RFC 129 4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] and RFC 5673 130 [RFC5673] from ROLL, CoAP [I-D.ietf-core-coap] from CoRE, and a paper 131 by Romer and Mattern [ROMER04]. Familiarity with application 132 specific examples such as Zigbee or Smart Energy groups is assumed. 134 A summary of those will be presented, as far as network requirements 135 are concerned. The general network requirements will be further 136 concentrated into requirements surrounding only the bootstrapping 137 issues. 139 A number of solutions which are currently in use will be presented. 140 Requirements on each solution will be stated to enable their use as a 141 security bootstrapping protocol. 143 1.1. What is Bootstrapping? 145 Node configuration is known as bootstrapping in this document. 146 Bootstrapping is any processing required before the network can 147 operate. Typically this will require a number of settings to be 148 transferred between nodes at all layers. This could include anything 149 from link-layer information (i.e., wireless channels, link-layer 150 encryption keys) to application-layer information (i.e., network 151 names, application encryption keys). 153 Bootstrapping is complete when settings have been securely 154 transferred prior to normal operation in the network. 156 1.2. Why IETF? 158 The bootstrapping problem is not specific to any MAC or PHY. This 159 problem exists across any two nodes which have no previous knowledge 160 of each other. In particular, this problem is complicated when the 161 nodes are resource-constrained and may not have an advanced user 162 interface. The IETF is instrumental in defining standards which will 163 be used by The Internet of Things. Ensuring these standards can be 164 used across nodes and networks requires some form of bootstrapping 165 which any node can use. 167 Existing standards will be used as much as possible in this document. 168 The method proposed here should work across many different underlying 169 layers. It could be used to allow two nodes on the same physical 170 network to join at the physical layer, or allow two nodes on an 171 incompatible physical network to join at the IPv6 layer. 173 2. Bootstrapping Architecture 175 2.1. Areas of Boostrapping 177 In order to provide a flexible architecture, the bootstrapping method 178 is split into five distinct areas and two distinct phases. The five 179 areas are a 'user interface', 'bootstrap profile', 'security method', 180 'bootstrap protocol', and the 'communications channel'. 182 The phases are provisioning phase and bootstrapping phase. In the 183 provisioning phase, statically configured parameters (e.g., 184 certificates) needed for the bootstrapping phase is provisioned. In 185 the bootstrapping phase, dynamically configured information is set up 186 using the statically configured information provided in the 187 provisioning phase. 189 The user interface provides both user input and user output. Simple 190 nodes may only have a push-button and LED, more complex nodes may 191 have a graphical display and keyboard. The user interface (which 192 could be implemented as network management software graphical user 193 interface running at the remote end) provides interaction between the 194 user and bootstrapping methods. The user interface would be used 195 during bootstrapping as an OOB channel. It may also be used to 196 specify bootstrapping policies. 198 The user interface provides the interaction between the user and the 199 bootstrap protocol. The user interface will vary depending on the 200 capabilities of the node. Examples might include a push-button and 201 LED on simple nodes, to full-blown graphical user interfaces. Note 202 that a 'bootstrapping tool' used to initially deploy a network is 203 just a special user interface. This allows a very uniform protocol 204 in deployment and use of networks. 206 User interface is out-of-scope and will not be further discussed. 208 Two nodes communicate through some channel. For our purposes this is 209 split into the 'control channel' and 'data channel'. The control 210 channel is used for the bootstrap protocol, and the data channel is 211 used during normal network operation. A node may support multiple 212 control or data channels. When the control and data channels are the 213 same, the bootstrapping is done In Band (IB). When the control and 214 data channels are different, the bootstrapping is performed Out Of 215 Band (OOB). An 802.15.4 network for instance would use an 802.15.4 216 control channel for IB bootstrapping, but a control channel of 217 perhaps IrDA or USB for OOB bootstrapping. 219 The 'bootstrap profile', i.e. statically configured parameters during 220 the provisioning phase, defines what information should be exchanged 221 during the process. A single node may run the protocol multiple 222 times with different profiles. If the user wishes to associate a new 223 lightswitch, the protocol is first run with the '802.15.4 Wireless 224 Profile', through which it learns the channel and PAN-ID. The node 225 then runs a 'Security Exchange Profile' to learn the needed 226 encryption keys. Finally it runs a 'Lightswitch Association Profile' 227 through which it learns which light to associate with. 229 An example of the 'bootstrap profile' attribute is the 230 'administrative domain name'. 'Bootstrap profiles' are required to 231 be modified when the corresponding administrative domains are 232 changed, a.k.a. recommissioning. In recommissioning, the domains are 233 administratively repartitioned and nodes are therefore 234 recommissioned. 236 The 'security method' defines supported security methods for 237 bootstrapping. The supported security methods will depend on the 238 control channel and bootstrap profile. In one node if the control 239 channel is secure, then a simple clear-text security method is 240 supported. For example when a physical connection between two nodes 241 is used, the control channel is considered secure. However when the 242 control channel is not secure, this clear-text security method is not 243 supported. The 'bootstrap profile' additionally defines allowed 244 security methods. Higher security nodes may outlaw ever performing a 245 clear-text exchange, even if the control channel is deemed secure. 247 The 'bootstrap protocol' defines the actual messages exchanged during 248 bootstrapping. The messages are used to transfer between nodes data, 249 node information, and network state. The selected security method 250 runs on top of the control channel, such as EAP-GPSK etc. 252 2.2. Architecture 254 Security bootstrapping architecture is structured in a hierarchy of 255 nodes going from the least resource constraint to the most resource 256 constraint. At the top there is a root node. The root node is 257 called Coordinator or Trust Center in Zigbee and 6LowPAN Border 258 Router (6LBR) in 6LoWPAN ND. 260 At the next level there are interior Routers. Routers are able to 261 run a routing protocol between other routers and the root. Router 262 are called 6LowPAN Routers (6BR) in 6LoWPAN ND. 264 At the lowest level there are the nodes. The nodes do not run a 265 routing protocol. They can connect to the nearest router over a 266 single radio link. The nodes are called End Device in Zigbee and 267 host in in 6LoWPAN ND. 269 Routers first join the network as a node and go through security 270 bootstrapping operations in order to create a Master Session Key 271 (MSK). Next routers execute routing protocol, e.g. 272 [I-D.ietf-roll-rpl] specific steps to create session keys with their 273 neighbors and to establish upstream and downstream next hop parents. 275 At each node hierarachy level described above, there are lower-layer 276 and higher-layer protocols to bootstrap their ciphering keys, where 277 the lower-layer refers to layers below IP layer including IEEE 278 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer 279 refers to IP layer and the above. In general, required bootstrapping 280 procedures depend on the bootstrapping protocols to use. Section 281 Section 5 describes the bootstrapping procedures where EAP 282 (Extensible Authentication Protocol) [RFC3748] and other protocols 283 are used as the bootstrapping protocols. 285 3. Communications Channel 287 The communications channel is the method used between two nodes to 288 communicate. There are two main communication channels: the 289 'control' and 'data' channels. The control channel is used during 290 bootstrapping, and the data channel is used during network operation. 292 3.1. Supported Communication Channels 294 There is no limit on what communications channels are supported. The 295 following gives an example of several supported channels: 297 o IEEE 802.15.4 299 o Power-Line Communications 301 o IrDA 303 o RFID 305 o Some simple physical link 307 o Cellular 309 o Ethernet 311 o IPv6 313 o Wi-Fi 315 Depending on the node's function, it may use different channels as 316 the data or control channel. Nodes may have multiple data and/or 317 control channels as wel. 319 4. Bootstrap Security Method 321 The bootstrap security method defines allowable security methods. A 322 node may choose to support or use a subset of these methods. This is 323 NOT the security architecture used for the application, but only the 324 security used during bootstrapping. Typically some high-security 325 method is used to generate a shared secret, which then switches to 326 simplier symmetric encryption to secure the actual bootstrapping 327 channel. The techniques negotiated should take advantage of hardware 328 resources available, such as hardware encryption accelerators on an 329 end node. 331 4.1. None 333 This is the simplist security method. No encryption or 334 authentication is provided, messages are exchanged completely in 335 clear-text. It is assumed some other layer provides security, such 336 as a physical connection between devices. 338 4.2. Asymmetric with User Authentication, Followed by Symmetric 340 A Diffie-Hellman style key exchange is used to generate a shared 341 secret. The authentication will be provided by the user, by 342 confirming cryptographic signatures between two devices. With the 343 shared secret generated through the DH, some symmetric encryption is 344 used to secure the actual bootstrapping channel. 346 4.3. Asymmetric with Certificate Authority, Followed by Symmetric 348 Public key exchanges are used (aka: DH again), but with a Certificate 349 Authority. Once a shared secret exists, symmetric encryption is used 350 to secure the actual bootstrapping channel. 352 4.4. Cryptographically Generated Address Based Address Ownership 353 Verification 355 A node may generate the global unique address using different 356 techniques other than the stateless address autoconfiguration. For 357 example, Cryptographically Generated Addresses (CGA) [RFC3972] is a 358 type of global unique address that can be used to verify the address 359 ownership. When the node uses CGA, it MUST execute SeND protocol 360 [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol 361 [I-D.ietf-6lowpan-nd] must be executed between the node and the edge 362 router. 364 5. Bootstrap Protocols 366 In this section we first present system level objectives that 367 security bootstrapping protocols are expected to achieve. Next, we 368 present EAP authentication framework and then describe three 369 different protocols. 371 5.1. System Level Objectives 373 Authentication/ reauthentication: nodes joining the network MUST at 374 the first place authenticate to the trust center. In order to 375 achieve secure multi-hop routing, the node MUST authenticate to its 376 upstream and downstream neighbors. A bootstrapping solution MUST 377 support re-authentication of resource-constrained devices and re- 378 keying of dynamically generated keys. 380 Data Confidentiality: the data communication between two endpoints 381 MAY be encrypted using the derived key, avoiding being eavesdropped 382 by a non-trusted third part. 384 Data Integrity: the data communication between two endpoints MUST NOT 385 be altered by some intermediate nodes. The nodes should be able to 386 detect the non-integral data. 388 Keys and key freshness: the keys used for data communication MUST 389 have a lifetime, in order to keep their freshness. A bootstrapping 390 solution MUST support both symmetric and asymmetric key 391 authentication. If distribution of a key to be used for a resource- 392 constrained device is required, a bootstrapping solution MUST support 393 secure key distribution to prevent the key from eavesdropping, 394 alternation and replay attacks. 396 Multi domain support: A bootstrapping solution MUST be able to allow 397 resource-constrained devices that may be subscribed to different 398 administrative domains to be connected to the same access network at 399 the same time. 401 Multi domain support: A bootstrapping solution MUST be able to allow 402 resource-constrained devices to be recommissioned. Recommissioning a 403 device is defined to be (1) an resource-constrained device is 404 administratively switched to a different domain, or (2) acting a new 405 role with a different function set, or (3) both administrative domain 406 and function set are modified. 408 Identities: A bootstrapping solution MUST be able to allow a 409 resource-constrained device to use various types of identities used 410 for authentication, including device identities, user identities or 411 combinations of different types of identities. Also a bootstrapping 412 solution MUST be able to allow a resource-constrained device to 413 change its identities used for authentication over time. 415 Authentication infrastructure: A bootstrapping solution MUST be able 416 to operate with or without an authentication infrastructure. 418 5.2. EAP Authentication Framework 420 In EAP, there are three distinct entities: the client or EAP peer, 421 the authenticator and the authentication or EAP server [RFC5247]. 423 The EAP peer is the node that requires to be authenticated before 424 being admitted to the network. The authentication server is the 425 device authenticating the node for bootstrapping. The authenticator 426 is the device that is admitting the node to the network and it 427 resides in between the peer and authentication server. 429 EAP client and EAP server exchange EAP messages to execute the 430 authentication algorithm, a.k.a. EAP method. The authenticator is 431 responsible for forwarding EAP messages between the client and 432 server. In 802.1X, EAP messages are carried in Layer 2 and in PANA 433 in IP or Layer 3. EAP messages between the authenticator and 434 authentication server are carried using AAA protocols (RADIUS or 435 Diameter). The associated AAA server address of each resource- 436 constrained device is assigned by the domain administrator. In the 437 recommissioning case, another AAA server is reassigned to a devices 438 by the domain administrator if the device is switched to another 439 domain. 441 At the end of a successful EAP method execution a master session key 442 (MSK) is generated at both the EAP peer and EAP server. 443 Authenticator receives MSK from EAP server at the end of EAP method 444 execution using key transport. MSK is used in deriving a session key 445 between the node and the authenticator using a protocol called secure 446 association protocol (SAP). Derivation of the session key terminates 447 bootstrapping of a node. 449 Additional keying material derived between EAP client and server that 450 is exported by the EAP method is called Extended Master Session Key 451 (EMSK). EMSK is not used in session key derivation but it could be 452 used for the needs of other applications in higher layer protocols. 454 In the architecture introduced in Section 2.2 the node or router is 455 the peer and the root is the authenticator. When the supplicant and 456 authenticator are one hop away the authenticator can be reached 457 directly. However, this is rarely the case. In other cases the 458 authenticator authenticates neighboring supplicants first. The 459 router nodes that are authenticated become relay authenticators in 460 the next phase and they relay authentication messages from the 461 supplicants to the authenticator and vice versa. This continues 462 until all nodes are authenticated. 464 EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request 465 messages sent by the server and EAP-Response messages sent by the 466 peer. At the end, the server indicates the status of authentication, 467 usually by EAP-Success message which also carries the MSK. The first 468 EAP-Request/Response pair is used for the server to request the 469 identity and the peer to provide it. In the other pairs of EAP 470 exchanges EAP method is executed. 472 Several EAP methods have been standardized each for different 473 purposes. To authenticate devices with certificates, EAP Transport 474 Layer Security (TLS) v1.2 specified in [RFC5216] which supports 475 certificate-based mutual authentication is used. 477 Smart Energy Profile 2.0 Application Protocol Specification [SE2.0] 478 mandates each device to be factory programmed with a certificate. 479 The certificate is bound to a unique network ID, e.g. the device's 480 MAC address or EUI-64 address. During EAP-Identity exchange the EAP 481 peer provides its EUI-64 address as an identity to EAP server. This 482 enables the server to validate the device certificate. 484 5.3. PANA 486 PANA (Protocol for carrying Authentication for Network Access) 487 [RFC5191] defines an EAP transport over UDP where a PANA Client (PaC) 488 is an EAP peer and a PANA Authentication Agent (PAA) is an EAP 489 authenticator. There are three bootstrapping scenarios using PANA. 491 1. Use of PANA for bootstrapping link-layer security. 493 In this case, PANA is used for network access authentication to 494 bootstrap link-layer ciphering. Security for higher-layer (i.e., 495 IP layer and above) protocols is bootstrapped from an IB or OOB 496 mechanism other than PANA. For example, in a 6LoWPAN deployment 497 PANA authentication can take place to bootstrap IEEE 802.15.4 MAC 498 layer ciphering keys. In ZigBee IP, IEEE 802.15.4 MAC layer 499 ciphering keys used as session keys are derived from a group key 500 so called a Network Key that is securely distributed to each 501 joining node upon successful PANA authentication using AES key 502 wrap over PANA [I-D.ohba-pana-keywrap] where the key encryption 503 key is derived from the EAP MSK (Master Session Key) [RFC3748]. 505 2. Use of PANA for bootstrapping higher-layer security. 507 In this scenario, PANA is used as an OOB mechanism for higher- 508 layer authentication to bootstrap ciphering keys for one or more 509 higher-layer protocols independently of network access 510 authentication. The PAA may reside in a higher-layer network 511 element such as an ANSI C12.22 authentication host [C1222] and a 512 CoAP server, or an independent server dedicated for service 513 authentication for multiple higher-layer protocols. When 514 bootstrapping ANSI C12.22 security for which no IB key management 515 mechanism is available, ANSI C12.22 ciphering keys are directly 516 derived from EAP key material established from PANA 517 authentication. When bootstrapping CoAP security with DTLS 518 protection, a PSK (Pre-Shared Key) credential in the combined 519 usage of DTLS (Datagram Transport Layer Security) [RFC4347] and 520 PSK mode of TLS [RFC4279] is derived from EAP key material and 521 DTLS ciphering keys are generated as a result of a successful 522 DTLS handshake. Similarly, when bootstrapping CoAP security with 523 IPsec ESP protection, a PSK credential of IKEv2 [RFC5996] is 524 derived from EAP key material and IPsec ESP ciphering keys are 525 generated as a result of a successful IKEv2 handshake. 527 The ability to bootstrap multiple higher-layer protocols from a 528 single execution of PANA authentication is important to save the 529 computational resources for resource-constrained devices 530 especially where public-key based authentication is used. 532 3. Use of PANA for bootstrapping both link-layer and higher-layer 533 security. 535 This case is the combination of the other two cases, and the most 536 optimized way for bootstrapping resource-constrained devices. 537 This case is only applicable where both the network access 538 authentication and the higher-layer authentication use the same 539 authentication server with the same authentication credentials. 541 The second and third scenarios are generally referred to as Single 542 Sign-On in section 4.2.2.2 of [NISTIR7628VOL1], where the root keys 543 for higher-layer protocols can be derived from EAP EMSK (Extended 544 Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295]. 546 A PANA Relay Element (PRE) is needed to enable PANA messaging between 547 a PANA Client (PaC) which is the node to be authenticated and a PANA 548 Authentication Agent (PAA) which is the authenticator where the two 549 nodes cannot reach each other by means of regular IP routing. This 550 happens during authentication since only a link-local IPv6 address 551 can be used prior to the completion of a succesful authentication. 553 PRE which is one hop away from PaC receives PANA messages and relays 554 the message contents (payload) by encapsulating it in a message 555 parameter called Attribute Value Pair (AVP). PRE also needs to send 556 header contents such as PaC's IP address and UDP port number in a 557 different AVP. PRE has IP routing established with PAA which could 558 be several hops away. PAA sends its reply messages in which the 559 payload is encapsulated in an AVP. It also adds the AVP containing 560 PaC's IP address and UDP port number. PRE sends creates a link local 561 PDU using these AVPs and sends it to PaC [I-D.ohba-pana-relay]. 563 The requirements for the use of PANA as a bootsrapping protocol can 564 be stated as follows: 566 o A new entity called PANA Relay Element needs to be added to the 567 PANA architecture. Behaviour of PANA Relay Element needs to be 568 defined. 570 o New AVPs needed for PANA Relay Element operation for properly 571 relaying messages from the client to the authenticator and vice 572 versa are required to be specified. 574 o An extension to PANA to securely distribute keys from the PANA 575 Authentication Agent to the PANA Client using AES Key Wrap with 576 Padding algorithm needs to be defined. This is needed in order to 577 use PANA for group key distribution. 579 5.4. HIP-DEX 581 [RFC4423] introduces the Host Identity Protocol (HIP) where the Host 582 Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit 583 length Host Identity Tag (HIT) is derived from the HI (hashed) and 584 functions as an IPv6 address (/128 prefix) for applications. A four- 585 packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX) 586 establishes a security association (SA, similar to IKE), indexed by 587 the HITs, but independent of the IP address. So HIP can be 588 considered as a shim layer between the transport(TCP/UDP) and IP, 589 providing authentication, data confidentiality, mobility in one 590 basket. 592 The HIP-BEX involves many crypto primitives that are difficult to run 593 on constrained nodes. HIP Diet Exchange (HIP-DEX) 594 [I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight. 595 Basically, HIP-DEX a variant of the HIP-BEX specifically designed to 596 use as few crypto primitives as possible yet still provide the same 597 class of security features as HIP-BEX. 599 HIP-DEX can be used for mutual authentication between two endpoints. 600 After mutual authentication, the two endpints establish a shared 601 secret, which is fresh and fed into the encryption algorithm for data 602 confidentiality. So HIP-DEX can achieve the authentication, key 603 freshness and data confidentiality objectives of security 604 bootstrapping. 606 When a node wants to authenticate to the network using HIP and Diet- 607 HIP, it should be able to complete the HIP-BEX or HIP-DEX with the 608 trust anchor or some delegate. In HIP, it does not matter how many 609 domains, and nodes can authenticate each other as long as they have 610 the secret. 612 In the architecture introduced in Section 2.2 the node and router 613 could be the HIP end-points. Depending on who initiates the HIP Diet 614 Exchange, the node or router could act as the HIP initiator and HIP 615 responder respectively. And the initiator and responder can be 616 multiple hops way from each other, as long as there is an IP 617 connectivity between them. 619 An important requirement for the HIP-DEX to work in the architecture, 620 the initiator should be able to get the IP address of the responder, 621 either using DNS infrastructure or local configuration. 623 5.5. 802.1X 625 IEEE 802.1X defines how EAP packets can be transported over in Layer 626 2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into 627 EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and 628 the authenticator. EAPOL can also be used in 802.11 wireless links. 630 To enable IEEE 802.15.4 devices to use EAP authentication, EAP 631 packets encapsulated in EAPOL frames can be carried as payload in 632 802.15.4 data frames [802.15.4]. EAPOL is well defined and widely 633 used and it lends itself to be easily carried in 802.15.4 data 634 frames. For this, Frame Type subfield of the Frame Control Field of 635 IEEE 802.15.4 MAC header needs to be set to a special value to 636 indicate the type of the payload, i.e. 802.1X encapsulated EAP 637 packets. EAPOL packets are encoded following common EAPOL PDU 638 structure defined in [802.1x] into the data payload field of 802.15.4 639 data frames. 641 Authentication proceeds as follows: authenticator authenticates the 642 supplicants that are on the next hop first. This enables a secure 643 link between the authenticator and these first-hop nodes. First-hop 644 nodes or router become Relay Authenticators in the next phase of 645 authentication. Relay authenticators tunnel EAPOL frames to the 646 authenticator in the secure link established. This way all the 647 supplicants are gradually authenticated. 649 The keys established from a successful EAP method (such as PSK mode 650 of TLS), the node runs neighbor discovery protocol to get an IPv6 651 address assigned [I-D.ietf-6lowpan-nd]. Data transfer can be secured 652 using DTLS or IPSec. Keys derived from EAP TLS are used in either 653 generating DTLS ciphering keys after a successful DTLS handshake or 654 IPSec ESP ciphering keys after a successful IKEv2 handshake. 656 802.1X can achieve the authentication, key freshness and data 657 confidentiality objectives of security bootstrapping. 659 Multi domain operation is intrinsically supported due to the use of 660 EAP and AAA. In order to support a device recommissioning case 661 whereby the device's administrative domain is modified, after a new 662 AAA server address assigned and a successful 802.1X method execution, 663 the old set of device 'name and password' MUST be overwritten into 664 the device by a new set of 'name and password' that are assigned by 665 the domain administrator. The device MUST be rebooted to execute EAP 666 method again for authentication and a new master session key MUST be 667 generated. 669 The requirements for the use of 802.1X defined EAPOL as a 670 bootsrapping protocol can be stated as follows: 672 o A special value in the Frame Type subfield of the Frame Control 673 Field of IEEE 802.15.4 MAC header to indicate the type of the 674 payload, 676 o Group addresses for 802.15.4 corresponding to EAPOL Group Address 677 Assignments defined in Table 11.1 of [802.1x], especially to be 678 used in EAPOL-Start packet. 680 o Which MAC frames of beacon, data, acknowledgment and MAC command 681 as defined in [802.15.4] with what security levels are mapped to 682 controlled port, which MAC frames with what security levels are 683 mapped to uncontrolled port and which MAC frames are never mapped 684 to any of controlled/uncontrolled port (i.e., the payload of those 685 frames are used by the MAC-ayer ieself and never used by upper 686 layers). 688 6. Security Considerations 690 When security bootstrapping resource constraint nodes, several 691 attacks are possible and security bootstrapping methods described in 692 this document do not protect the nodes against such attacks. These 693 attacks are similar to the ones described in [RFC3971] and mainly 694 stem from unsecured link layer. Link layer must be secured on each 695 node before the node can begin security bootstrapping. 697 7. IANA Considerations 699 This memo includes no request to IANA. 701 8. Acknowledgements 703 Very special thanks go to Colin O'Flynn who initiated this document 704 and contributed so much to it. Thanks to Zach Shelby for editing, 705 comments, and overall assistance. Special thanks also to Rene 706 Struik, Carsten Borman and Gary Yang for their comments that helped 707 us improve the writing. 709 9. References 711 9.1. Normative References 713 [802.15.4] 714 IEEE Std 802.15.4-2006, "Wireless Medium Access Control 715 (MAC) and Physical Layer (PHY) Specifications for Low Rate 716 Wireless Personal Area Networks (WPANs)", September 2006. 718 [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network 719 Access Control", February 2010. 721 [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version 722 1.00", March 2009. 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, March 1997. 727 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 728 Levkowetz, "Extensible Authentication Protocol (EAP)", 729 RFC 3748, June 2004. 731 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 732 over Low-Power Wireless Personal Area Networks (6LoWPANs): 733 Overview, Assumptions, Problem Statement, and Goals", 734 RFC 4919, August 2007. 736 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 737 Yegin, "Protocol for Carrying Authentication for Network 738 Access (PANA)", RFC 5191, May 2008. 740 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 741 Authentication Protocol", RFC 5216, March 2008. 743 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 744 "Routing Requirements for Urban Low-Power and Lossy 745 Networks", RFC 5548, May 2009. 747 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 748 "Industrial Routing Requirements in Low-Power and Lossy 749 Networks", RFC 5673, October 2009. 751 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 752 sensor networks", IEEE Wireless Communications, vol. 11, 753 no. 6, pp. 54-61, December 2004. 755 [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical 756 Requirements Document", April 2010. 758 9.2. Informative References 760 [C1222] American National Standard, "Protocol Specification For 761 Interfacing to Data Communication Networks", ANSI C12.22- 762 2008, 2008. 764 [I-D.ietf-6lowpan-nd] 765 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 766 Discovery Optimization for Low-power and Lossy Networks", 767 draft-ietf-6lowpan-nd-15 (work in progress), 768 December 2010. 770 [I-D.ietf-core-coap] 771 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 772 "Constrained Application Protocol (CoAP)", 773 draft-ietf-core-coap-04 (work in progress), January 2011. 775 [I-D.ietf-roll-rpl] 776 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 777 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 778 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 779 Lossy Networks", draft-ietf-roll-rpl-17 (work in 780 progress), December 2010. 782 [I-D.moskowitz-hip-rg-dex] 783 Moskowitz, R., "HIP Diet EXchange (DEX)", 784 draft-moskowitz-hip-rg-dex-02 (work in progress), 785 July 2010. 787 [I-D.narten-iana-considerations-rfc2434bis] 788 Narten, T. and H. Alvestrand, "Guidelines for Writing an 789 IANA Considerations Section in RFCs", 790 draft-narten-iana-considerations-rfc2434bis-09 (work in 791 progress), March 2008. 793 [I-D.ohba-pana-keywrap] 794 Chakrabarti, S., Cragie, R., Duffy, P., Ohba, Y., and A. 795 Yegin, "Protocol for Carrying Authentication for Network 796 Access (PANA) Extension for Key Wrap", 797 draft-ohba-pana-keywrap-01 (work in progress), 798 October 2010. 800 [I-D.ohba-pana-relay] 801 Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 802 Yegin, "Protocol for Carrying Authentication for Network 803 Access (PANA) Relay Element", draft-ohba-pana-relay-02 804 (work in progress), October 2010. 806 [NISTIR7628VOL1] 807 The Smart Grid Interoperability Panel - Cyber Security 808 Working Group, "Guidelines for Smart Grid Cyber Security: 809 Vol. 1, Smart Grid Cyber Security Strategy, Architecture, 810 and High-Level Requirements", NISTIR 7628, vol. 1, 2010. 812 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 813 June 1999. 815 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 816 Text on Security Considerations", BCP 72, RFC 3552, 817 July 2003. 819 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 820 Neighbor Discovery (SEND)", RFC 3971, March 2005. 822 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 823 RFC 3972, March 2005. 825 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 826 for Transport Layer Security (TLS)", RFC 4279, 827 December 2005. 829 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 830 Security", RFC 4347, April 2006. 832 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 833 (HIP) Architecture", RFC 4423, May 2006. 835 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 836 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 838 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 839 Authentication Protocol (EAP) Key Management Framework", 840 RFC 5247, August 2008. 842 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 843 "Specification for the Derivation of Root Keys from an 844 Extended Master Session Key (EMSK)", RFC 5295, 845 August 2008. 847 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 848 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 849 RFC 5433, February 2009. 851 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 852 "Internet Key Exchange Protocol Version 2 (IKEv2)", 853 RFC 5996, September 2010. 855 Appendix A. Examples of Node Configuration 857 Before any detail on methods is explored, the following section will 858 provide various examples this document could cover. Exact 859 requirements will be brought forward in subsequent sections. For the 860 reader's general understanding this section is placed to give an idea 861 of an acceptable usage scenario. 863 A.1. Smart Energy 865 A.1.1. Initial Meter Installation 867 The meter is initially loaded with code and network keys through a 868 physical interface at the factory. The meter is installed at a 869 customers home, and configured by the installer through the backbone 870 link (via GSM modem, etc). Both operations can be performed through 871 methods defined herein. 873 A.1.2. Home Expansions 875 The user wishes to join a thermostat onto the network. They press a 876 button on the thermostat, which enters join mode. They press a 877 button on the smart meter, which allows nodes to join the network. 878 The devices both have displays, so they display a certain number 879 which the user verifies match on both devices. The thermostat has 880 now securely joined the network. 882 A.2. Consumer Products 883 A.2.1. Connecting DVD Remote to DVD Player 885 The user pushes a join button on the DVD remote and DVD player. The 886 devices find each other, and blink in unison to indicate to the user 887 which two devices will join. The user presses the button to confirm 888 this, and the two devices are now joined together. 890 A.2.2. Adding a TV to a network with a DVD player and remote 892 The user then presses the join button on the DVD player and TV. The 893 devices again find each other and blink in unison, with the addition 894 that the remote control also blinks to indicate it is present in the 895 network. 897 A.2.3. Providing GPS Location Data 899 A user has a simple GPS receiver (that has no user interface) they 900 wish to broadcast location data with. The user switches on their 901 camera, and enters a PIN from the base of the GPS. The user can now 902 view GPS information such as satellite health from their camera. In 903 addition photos are automatically tagged with location information. 905 A.3. Commercial Building Automation 907 A.3.1. Light Installation 909 The electrician installs the light fixture. Each light has a barcode 910 printed on it. They use a handheld barcode scanner tool, which acts 911 as the commissioning tool. When they scan a barcode with the tool, 912 the tool asks the electrician to enter some additional information 913 such as light fixture location. The tool securely registers the 914 light fixture on the network, along with setting parameters inside 915 the light fixture. 917 Appendix B. Example Exchanges 919 The following details how the protocol handles certain conditions and 920 situations through examples. Note that each example is a more 921 detailed description of the examples in Appendix A. 923 B.1. Smart Energy: Meter Manufacture 925 B.2. Smart Energy: Meter Installation 927 B.3. Smart Energy: Home Expansion 928 B.4. Consumer: Connecting DVD Remote to DVD Player 930 Supported User Interface Profiles 932 +----------------+------------+----------------+ 933 | Profile | DVD Player | Remote Control | 934 +----------------+------------+----------------+ 935 | none | Y | Y | 936 | simple | Y | Y | 937 | numerical | Y | N | 938 | alphanumerical | Y | N | 939 | Graphical | Y | N | 940 +----------------+------------+----------------+ 942 Supported Bootstrap Transport Layers 944 +----------+------------+----------------+ 945 | Layer | DVD Player | Remote Control | 946 +----------+------------+----------------+ 947 | Physical | Y | Y | 948 | 802.15.4 | Y | Y | 949 | IrDA | Y | N | 950 +----------+------------+----------------+ 952 Supported Security Methods 954 +------------------+------------+----------------+ 955 | Method | DVD Player | Remote Control | 956 +------------------+------------+----------------+ 957 | None | Y | Y | 958 | EAP | Y | N | 959 | Asymmetric, User | Y | Y | 960 | Asymmetric, CA | Y | N | 961 +------------------+------------+----------------+ 963 The DVD player and remote control have a number of ways in which they 964 could be joined together. The remote control does not have any 965 unique identifier printed on it, thus no pre-shared key can be 966 identified. This leaves either an unsecure joining method, or some 967 asymmetric security method. 969 The remote control has a button on it for 'join', as does the DVD 970 player. The user pushes the button on the DVD player, and then 971 pushes the button on the remote control. Based on the UI profile, 972 this causes the following to occur: 974 o DVD Player scans for existing network in advertise mode. Finding 975 none, it starts a new network and that network enters advertise 976 mode. 978 o The DVD remote scans for a network, and then finds the DVD 979 player's network. 981 o The devices generate a shared secret (ie: Diffie-Hellman), and 982 both blink their LED in a unique pattern based on this shared 983 secret. 985 o The user user confirms both devices are blinking the same pattern, 986 as both LEDs are blinking in unison. 988 o The DVD player displays 'JOIN OK' on it's LCD panel. 990 B.5. Consumer: Adding a TV to a network with a DVD player and remote 992 This network will have three devices: a TV, a DVD Player, and a 993 Remote Control. The user will run the bootstrap protocol between the 994 TV and Remote Control in this example, although it could also be run 995 between the TV and DVD player. 997 Supported User Interface Profiles 999 +----------------+----+----------------+ 1000 | Profile | TV | Remote Control | 1001 +----------------+----+----------------+ 1002 | none | Y | Y | 1003 | simple | Y | Y | 1004 | numerical | Y | N | 1005 | alphanumerical | Y | N | 1006 | Graphical | Y | N | 1007 +----------------+----+----------------+ 1009 Supported Bootstrap Transport Layers 1011 +----------+----+----------------+ 1012 | Layer | TV | Remote Control | 1013 +----------+----+----------------+ 1014 | Physical | Y | Y | 1015 | 802.15.4 | Y | Y | 1016 | IrDA | Y | N | 1017 +----------+----+----------------+ 1018 Supported Security Methods 1020 +------------------+----+----------------+ 1021 | Method | TV | Remote Control | 1022 +------------------+----+----------------+ 1023 | None | Y | Y | 1024 | EAP-GPSK | Y | N | 1025 | Asymmetric, User | Y | Y | 1026 | Asymmetric, CA | Y | N | 1027 +------------------+----+----------------+ 1029 The TV and remote control have a number of ways in which they could 1030 be joined together. The remote control does not have any unique 1031 identifier printed on it, thus no pre-shared key can be identified. 1032 This leaves either an unsecure joining method, or some asymmetric 1033 security method. 1035 The remote control has a button on it for 'join', as does the TV. In 1036 this example two sequence will be considered: where the TV button is 1037 pressed first, and where the remote control button is pressed first. 1039 If the TV join button is pressed first: 1041 o TV scans for existing networks in advertise mode. Finding none, 1042 it starts a new network and that network enters advertise mode. 1044 o The remote scans for a network, and then finds the TV's network. 1046 o The remote informs the TV it is on an existing network, and thus 1047 will require the TV to join this network. 1049 o The devices generate a shared secret, and both blink their LED in 1050 a unique pattern. 1052 o The DVD player in addition blinks, so the user is informed that if 1053 they confirm the join action the resulting network will have all 1054 three devices in it. 1056 o The user confirms both devices are blinking the same pattern, as 1057 both LEDs are blinking in unison. 1059 o The TV displays 'JOIN OK' onscreen, along with any information 1060 about the network it just joined. 1062 If the remote control join button is pressed first: 1064 o Remote control scans for existing networks in advertise mode. 1065 Finding none, it advertises it's network. 1067 o The TV scans for a network, and then finds the remote control's 1068 network. 1070 o The devices generate a shared secret, and both blink their LED in 1071 a unique pattern. 1073 o The DVD player in addition blinks, so the user is informed that if 1074 they confirm the join action the resulting network will have all 1075 three devices in it. 1077 o The user confirms both devices are blinking the same pattern, as 1078 both LEDs are blinking in unison. 1080 o The TV displays 'JOIN OK' onscreen, along with any information 1081 about the network it just joined. 1083 B.6. Consumer: Providing GPS Location Data 1085 B.7. Commercial: Building Automation 1087 Authors' Addresses 1089 Behcet Sarikaya 1090 Huawei USA 1091 1700 Alma Dr. Suite 500 1092 Plano, TX 75075 1094 Email: sarikaya@ieee.org 1096 Yoshihiro Ohba 1097 Toshiba 1098 Tokyo, Japan 1100 Email: yoshihiro.ohba@toshiba.co.jp 1102 Zhen Cao 1103 China Mobile 1104 Beijing, China 1106 Email: caozhen@chinamobile.com 1107 Robert Cragie 1108 Pacific Gas and Electric 1109 89 Greenfield Crescent 1110 Wakefield, UK WF4 4WA 1112 Email: robert.cragie@gridmerge.com