idnits 2.17.1 draft-oflynn-core-bootstrapping-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 87 has weird spacing: '...mmetric with ...' == Line 337 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 (October 19, 2010) is 4937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RF4CE' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC5433' is defined on line 735, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-13 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-02 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-12 == 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 -- 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) Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Core C. O'Flynn 3 Internet-Draft Atmel Corporation 4 Intended status: Informational B. Sarikaya 5 Expires: April 22, 2011 Huawei USA 6 Y. Ohba 7 Toshiba 8 Z. Cao 9 China Mobile 10 R. Cragie 11 Pacific Gas and Electric 12 October 19, 2010 14 Security Bootstrapping of Resource-Constrained Devices 15 draft-oflynn-core-bootstrapping-02 17 Abstract 19 The Internet of Things is marching its way towards completion. Nodes 20 can use standards from the 6LoWPAN and ROLL WG to achieve IP 21 connectivity. IEEE Standards ensure connectivity at lower layers for 22 resource-constrained devices. Yet a central problem remains at a 23 more basic layer without a suitable answer: how to initially 24 configure the network. Without configuration the network never 25 advances beyond a large box of nodes. Current solutions tend to be 26 specific to a certain vendor, node type, or application. 28 This document outlines exactly what problems are faced in solving 29 this problem. General problems faced in any low-power wireless 30 network are outlined first; followed by how these apply to 31 bootstrapping. A selection of currently proposed techniques is 32 presented. From these a more generic approach is presented, which 33 can solve the problem for a wide range of situations. 35 An emphasis is on performing this bootstrapping in a secure manner. 36 This document does not cover operation of the network securely. This 37 document does provide the basis for allowing the network to operate 38 securely however, by providing standard methods for key exchanges and 39 authentication. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on April 22, 2011. 58 Copyright Notice 60 Copyright (c) 2010 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5 77 1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 6 79 2.1. Areas of Boostrapping . . . . . . . . . . . . . . . . . . 6 80 2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 81 3. Communications Channel . . . . . . . . . . . . . . . . . . . . 8 82 3.1. Supported Communication Channels . . . . . . . . . . . . . 8 83 4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 8 84 4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.2. Asymmetric with User Authentication, Followed by 86 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 87 4.3. Asymmetric with Certificate Authority, Followed by 88 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 89 4.4. Cryptographically Generated Address Based Address 90 Ownership Verification . . . . . . . . . . . . . . . . . . 9 91 5. Bootstrap Protocols . . . . . . . . . . . . . . . . . . . . . 9 92 5.1. EAP Authentication Framework . . . . . . . . . . . . . . . 10 93 5.2. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 5.3. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.4. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 102 Appendix A. Examples of Node Configuration . . . . . . . . . . . 18 103 A.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 18 104 A.1.1. Initial Meter Installation . . . . . . . . . . . . . . 18 105 A.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 18 106 A.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 18 107 A.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 18 108 A.2.2. Adding a TV to a network with a DVD player and 109 remote . . . . . . . . . . . . . . . . . . . . . . . . 18 110 A.2.3. Providing GPS Location Data . . . . . . . . . . . . . 18 111 A.3. Commercial Building Automation . . . . . . . . . . . . . . 19 112 A.3.1. Light Installation . . . . . . . . . . . . . . . . . . 19 113 Appendix B. Example Exchanges . . . . . . . . . . . . . . . . . . 19 114 B.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 19 115 B.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 19 116 B.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 19 117 B.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 19 118 B.5. Consumer: Adding a TV to a network with a DVD player 119 and remote . . . . . . . . . . . . . . . . . . . . . . . . 21 120 B.6. Consumer: Providing GPS Location Data . . . . . . . . . . 23 121 B.7. Commercial: Building Automation . . . . . . . . . . . . . 23 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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 provides 192 interaction between the user and bootstrapping methods. The user 193 interface would be used during bootstrapping as an OOB channel. It 194 may also be used to specify bootstrapping policies. 196 The user interface provides the interaction between the user and the 197 bootstrap protocol. The user interface will vary depending on the 198 capabilities of the node. Examples might include a push-button and 199 LED on simple nodes, to full-blown graphical user interfaces. Note 200 that a 'bootstrapping tool' used to initially deploy a network is 201 just a special user interface. This allows a very uniform protocol 202 in deployment and use of networks. 204 User interface is out-of-scope and will not be further discussed. 206 Two nodes communicate through some channel. For our purposes this is 207 split into the 'control channel' and 'data channel'. The control 208 channel is used for the bootstrap protocol, and the data channel is 209 used during normal network operation. A node may support multiple 210 control or data channels. When the control and data channels are the 211 same, the bootstrapping is done In Band (IB). When the control and 212 data channels are different, the bootstrapping is performed Out Of 213 Band (OOB). An 802.15.4 network for instance would use an 802.15.4 214 control channel for IB bootstrapping, but a control channel of 215 perhaps IrDA or USB for OOB bootstrapping. 217 The 'bootstrap profile', i.e. statically configured parameters during 218 the provisioning phase, defines what information should be exchanged 219 during the process. A single node may run the protocol multiple 220 times with different profiles. If the user wishes to associate a new 221 lightswitch, the protocol is first run with the '802.15.4 Wireless 222 Profile', through which it learns the channel and PAN-ID. The node 223 then runs a 'Security Exchange Profile' to learn the needed 224 encryption keys. Finally it runs a 'Lightswitch Association Profile' 225 through which it learns which light to associate with. 227 The 'security method' defines supported security methods for 228 bootstrapping. The supported security methods will depend on the 229 control channel and bootstrap profile. In one node if the control 230 channel is secure, then a simple clear-text security method is 231 supported. For example when a physical connection between two nodes 232 is used, the control channel is considered secure. However when the 233 control channel is not secure, this clear-text security method is not 234 supported. The 'bootstrap profile' additionally defines allowed 235 security methods. Higher security nodes may outlaw ever performing a 236 clear-text exchange, even if the control channel is deemed secure. 238 The 'bootstrap protocol' defines the actual messages exchanged during 239 bootstrapping. The messages are used to transfer between nodes data, 240 node information, and network state. The selected security method 241 runs on top of the control channel, such as EAP-GPSK etc. 243 2.2. Architecture 245 Security bootstrapping architecture is structured in a hierarchy of 246 nodes going from the least resource constraint to the most resource 247 constraint. At the top there is a root node. The root node is 248 called Coordinator or Trust Center in Zigbee and 6LowWAN Border 249 Router (6LBR) in 6LoWPAN ND. 251 At the next level there are interior Routers. Routers are able to 252 run a routing protocol between other routers and the root. Router 253 are called 6LowWAN Routers (6BR) in 6LoWPAN ND. 255 At the lowest level there are the nodes. The nodes do not run a 256 routing protocol. They can connect to the nearest router over a 257 single radio link. The nodes are called End Device in Zigbee and 258 host in in 6LoWPAN ND. 260 Routers first join the network as a node and go through security 261 bootstrapping operations in order to create a Master Session Key 262 (MSK). Next routers execute routing protocol, e.g. 263 [I-D.ietf-roll-rpl] specific steps to create session keys with their 264 neighbors and to establish upstream and downstream next hop parents. 266 At each node hierarachy level described above, there are lower-layer 267 and higher-layer protocols to bootstrap their ciphering keys, where 268 the lower-layer refers to layers below IP layer including IEEE 269 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer 270 refers to IP layer and the above. In general, required bootstrapping 271 procedures depend on the bootstrapping protocols to use. Section 272 Section 5 describes the bootstrapping procedures where EAP 273 (Extensible Authentication Protocol) [RFC3748] and other protocols 274 are used as the bootstrapping protocols. 276 3. Communications Channel 278 The communications channel is the method used between two nodes to 279 communicate. There are two main communication channels: the 280 'control' and 'data' channels. The control channel is used during 281 bootstrapping, and the data channel is used during network operation. 283 3.1. Supported Communication Channels 285 There is no limit on what communications channels are supported. The 286 following gives an example of several supported channels: 288 o IEEE 802.15.4 290 o Power-Line Communications 292 o IrDA 294 o RFID 296 o Some simple physical link 298 o Cellular 300 o Ethernet 302 o IPv6 304 o Wi-Fi 306 Depending on the node's function, it may use different channels as 307 the data or control channel. Nodes may have multiple data and/or 308 control channels as wel. 310 4. Bootstrap Security Method 312 The bootstrap security method defines allowable security methods. A 313 node may choose to support or use a subset of these methods. This is 314 NOT the security architecture used for the application, but only the 315 security used during bootstrapping. Typically some high-security 316 method is used to generate a shared secret, which then switches to 317 simplier symmetric encryption to secure the actual bootstrapping 318 channel. The techniques negotiated should take advantage of hardware 319 resources available, such as hardware encryption accelerators on an 320 end node. 322 4.1. None 324 This is the simplist security method. No encryption or 325 authentication is provided, messages are exchanged completely in 326 clear-text. It is assumed some other layer provides security, such 327 as a physical connection between devices. 329 4.2. Asymmetric with User Authentication, Followed by Symmetric 331 A Diffie-Hellman style key exchange is used to generate a shared 332 secret. The authentication will be provided by the user, by 333 confirming cryptographic signatures between two devices. With the 334 shared secret generated through the DH, some symmetric encryption is 335 used to secure the actual bootstrapping channel. 337 4.3. Asymmetric with Certificate Authority, Followed by Symmetric 339 Public key exchanges are used (aka: DH again), but with a Certificate 340 Authority. Once a shared secret exists, symmetric encryption is used 341 to secure the actual bootstrapping channel. 343 4.4. Cryptographically Generated Address Based Address Ownership 344 Verification 346 A node may generate the global unique address using different 347 techniques other than the stateless address autoconfiguration. For 348 example, Cryptographically Generated Addresses (CGA) [RFC3972] is a 349 type of global unique address that can be used to verify the address 350 ownership. When the node uses CGA, it MUST execute SeND protocol 351 [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol 352 [I-D.ietf-6lowpan-nd] must be executed between the node and the edge 353 router. 355 5. Bootstrap Protocols 357 In this section we first present EAP authentication framework and 358 then describe three different protocols. 360 5.1. EAP Authentication Framework 362 In EAP, there are three distinct entities: the client or EAP peer, 363 the authenticator and the authentication or EAP server [RFC5247]. 365 The EAP peer is the node that requires to be authenticated before 366 being admitted to the network. The authentication server is the 367 device authenticating the node for bootstrapping. The authenticator 368 is the device that is admitting the node to the network and it 369 resides in between the peer and authentication server. 371 EAP client and EAP server exchange EAP messages to execute the 372 authentication algorithm, a.k.a. EAP method. The authenticator is 373 responsible for forwarding EAP messages between the client and 374 server. In 802.1X, EAP messages are carried in Layer 2 and in PANA 375 in IP or Layer 3. EAP messages between the authenticator and 376 authentication server are carried using AAA protocols (RADIUS or 377 Diameter). 379 At the end of a successful EAP method execution a master session key 380 (MSK) is generated at both the EAP peer and EAP server. 381 Authenticator receives MSK from EAP server at the end of EAP method 382 execution using key transport. MSK is used in deriving a session key 383 between the node and the authenticator using a protocol called secure 384 association protocol (SAP). Derivation of the session key terminates 385 bootstrapping of a node. 387 Additional keying material derived between EAP client and server that 388 is exported by the EAP method is called Extended Master Session Key 389 (EMSK). EMSK is not used in session key derivation but it could be 390 used for the needs of other applications in higher layer protocols. 392 In the architecture introduced in Section 2.2 the node or router is 393 the peer and the root is the authenticator. When the supplicant and 394 authenticator are one hop away the authenticator can be reached 395 directly. However, this is rarely the case. In other cases the 396 authenticator authenticates neighboring supplicants first. The 397 router nodes that are authenticated become relay authenticators in 398 the next phase and they relay authentication messages from the 399 supplicants to the authenticator and vice versa. This continues 400 until all nodes are authenticated. 402 EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request 403 messages sent by the server and EAP-Response messages sent by the 404 peer. At the end, the server indicates the status of authentication, 405 usually by EAP-Success message which also carries the MSK. The first 406 EAP-Request/Response pair is used for the server to request the 407 identity and the peer to provide it. In the other pairs of EAP 408 exchanges EAP method is executed. 410 Several EAP methods have been standardized each for different 411 purposes. To authenticate devices with certificates, EAP Transport 412 Layer Security (TLS) v1.2 specified in [RFC5216] which supports 413 certificate-based mutual authentication is used. 415 Smart Energy Profile 2.0 Application Protocol Specification [SE2.0] 416 mandates each device to be factory programmed with a certificate. 417 The certificate is bound to a unique network ID, e.g. the device's 418 MAC address or EUI-64 address. During EAP-Identity exchange the EAP 419 peer provides its EUI-64 address as an identity to EAP server. This 420 enables the server to validate the device certificate. 422 5.2. PANA 424 PANA (Protocol for carrying Authentication for Network Access) 425 [RFC5191] defines an EAP transport over UDP where a PANA Client (PaC) 426 is an EAP peer and a PANA Authentication Agent (PAA) is an EAP 427 authenticator. There are three bootstrapping scenarios using PANA. 429 1. Use of PANA for bootstrapping link-layer security. 431 In this case, PANA is used for network access authentication to 432 bootstrap link-layer ciphering. Security for higher-layer (i.e., 433 IP layer and above) protocols is bootstrapped from an IB or OOB 434 mechanism other than PANA. For example, in a 6LoWPAN deployment 435 PANA authentication can take place to bootstrap IEEE 802.15.4 MAC 436 layer ciphering keys. 438 2. In ZigBee IP, IEEE 802.15.4 MAC layer ciphering keys used as 439 session keys are derived from a group key so called a Network Key 440 that is securely distributed to each joining node upon successful 441 PANA authentication using AES key wrap over PANA 442 [I-D.ohba-pana-keywrap] where the key encryption key is derived 443 from the EAP MSK (Master Session Key) [RFC3748]. 445 3. Use of PANA for bootstrapping higher-layer security. 447 In this scenario, PANA is used as an OOB mechanism for higher- 448 layer authentication to bootstrap ciphering keys for one or more 449 higher-layer protocols independently of network access 450 authentication. The PAA may reside in a higher-layer network 451 element such as an ANSI C12.22 authentication host [C1222] and a 452 CoAP server, or an independent server dedicated for service 453 authentication for multiple higher-layer protocols. When 454 bootstrapping ANSI C12.22 security for which no IB key management 455 mechanism is available, ANSI C12.22 ciphering keys are directly 456 derived from EAP key material established from PANA 457 authentication. When bootstrapping CoAP security, a PSK (Pre- 458 Shared Key) credential in the combined usage of DTLS (Datagram 459 Transport Layer Security) [RFC4347] and PSK mode of TLS [RFC4279] 460 is derived from EAP key material and DTLS ciphering keys are 461 generated as a result of a successful DTLS handshake. 463 The ability to bootstrap multiple higher-layer protocols from a 464 single execution of PANA authentication is important to save the 465 computational resources for resource-constrained devices 466 especially where public-key based authentication is used. 468 4. Use of PANA for bootstrapping both link-layer and higher-layer 469 security. 471 This case is the combination of the other two cases, and the most 472 optimized way for bootstrapping resource-constrained devices. 473 This case is only applicable where both the network access 474 authentication and the higher-layer authentication use the same 475 authentication server with the same authentication credentials. 477 The second and third scenarios are generally referred to as Single 478 Sign-On in section 4.2.2.2 of [NISTIR7628VOL1], where the root keys 479 for higher-layer protocols can be derived from EAP EMSK (Extended 480 Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295]. 482 A PANA Relay Element (PRE) is needed to enable PANA messaging between 483 a PANA Client (PaC) which is the node to be authenticated and a PANA 484 Authentication Agent (PAA) which is the authenticator where the two 485 nodes cannot reach each other by means of regular IP routing. This 486 happens during authentication since only a link-local IPv6 address 487 can be used prior to the completion of a succesful authentication. 489 PRE which is one hop away from PaC receives PANA messages and relays 490 the message contents (payload) by encapsulating it in a message 491 parameter called Attribute Value Pair (AVP). PRE also needs to send 492 header contents such as PaC's IP address and UDP port number in a 493 different AVP. PRE has IP routing established with PAA which could 494 be several hops away. PAA sends its reply messages in which the 495 payload is encapsulated in an AVP. It also adds the AVP containing 496 PaC's IP address and UDP port number. PRE sends creates a link local 497 PDU using these AVPs and sends it to PaC. 499 The requirements for the use of PANA as a bootsrapping protocol can 500 be stated as follows: 502 o A new entity called PANA Relay Element needs to be added to the 503 PANA architecture. Behaviour of PANA Relay Element needs to be 504 defined. 506 o New AVPs needed for PANA Relay Element operation for properly 507 relaying messages from the client to the authenticator and vice 508 versa are required to be specified. 510 o An extension to PANA to securely distribute keys from the PANA 511 Authentication Agent to the PANA Client using AES Key Wrap with 512 Padding algorithm needs to be defined. This is needed in order to 513 use PANA for group key distribution. 515 5.3. HIP-DEX 517 [RFC4423] introduces the Host Identity Protocol (HIP) where the Host 518 Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit 519 length Host Identity Tag (HIT) is derived from the HI (hashed) and 520 functions as an IPv6 address (/128 prefix) for applications. A four- 521 packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX) 522 establishes a security association (SA, similar to IKE), indexed by 523 the HITs, but independent of the IP address. So HIP can be 524 considered as a shim layer between the transport(TCP/UDP) and IP, 525 providing authentication, data confidentiality, mobility in one 526 basket. 528 The HIP BEX involves many crypto primitives that are difficult to run 529 on constrained nodes. HIP Diet Exchange (HIP DEX) 530 [I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight. 531 Basically, HIP DEX a variant of the HIP BEX specifically designed to 532 use as few crypto primitives as possible yet still provide the same 533 class of security features as HIP BEX. 535 In the architecture introduced in Section 2.2 the node and router 536 could be the HIP end-points. Depending on who initiates the HIP Diet 537 Exchange, the node or router could act as the HIP initiator and HIP 538 responder respectively. And the initiator and responder can be 539 multiple hops way from each other, as long as there is an IP 540 connectivity between them. 542 An important requirement for the HIP-DEX to work in the architecture, 543 the initiator should be able to get the IP address of the responder, 544 either using DNS infrastructure or local configuration. 546 5.4. 802.1X 548 IEEE 802.1X defines how EAP packets can be transported over in Layer 549 2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into 550 EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and 551 the authenticator. EAPOL can also be used in 802.11 wireless links. 553 To enable IEEE 802.15.4 devices to use EAP authentication, EAP 554 packets encapsulated in EAPOL frames can be carried as payload in 555 802.15.4 data frames [802.15.4]. EAPOL is well defined and widely 556 used and it lends itself to be easily carried in 802.15.4 data 557 frames. For this, Frame Type subfield of the Frame Control Field of 558 IEEE 802.15.4 MAC header needs to be set to a special value to 559 indicate the type of the payload, i.e. 802.1X encapsulated EAP 560 packets. EAPOL packets are encoded following common EAPOL PDU 561 structure defined in [802.1x] into the data payload field of 802.15.4 562 data frames. 564 Authentication proceeds as follows: authenticator authenticates the 565 supplicants that are on the next hop first. This enables a secure 566 link between the authenticator and these first-hop nodes. First-hop 567 nodes or router become Relay Authenticators in the next phase of 568 authentication. Relay authenticators tunnel EAPOL frames to the 569 authenticator in the secure link established. This way all the 570 supplicants are gradually authenticated. 572 The requirements for the use of 802.1X defined EAPOL as a 573 bootsrapping protocol can be stated as follows: 575 o A special value in the Frame Type subfield of the Frame Control 576 Field of IEEE 802.15.4 MAC header to indicate the type of the 577 payload, 579 o Group addresses for 802.15.4 corresponding to EAPOL Group Address 580 Assignments defined in Table 11.1 of [802.1x], especially to be 581 used in EAPOL-Start packet. 583 o Which MAC frames of beacon, data, acknowledgment and MAC command 584 as defined in [802.15.4] with what security levels are mapped to 585 controlled port, which MAC frames with what security levels are 586 mapped to uncontrolled port and which MAC frames are never mapped 587 to any of controlled/uncontrolled port (i.e., the payload of those 588 frames are used by the MAC-ayer ieself and never used by upper 589 layers). 591 6. Security Considerations 593 TBD. 595 7. IANA Considerations 597 This memo includes no request to IANA. 599 8. Acknowledgements 601 Thanks to Zach Shelby for editing, comments, and overall assistance. 603 9. References 605 9.1. Normative References 607 [802.15.4] 608 IEEE Std 802.15.4-2006, "Wireless Medium Access Control 609 (MAC) and Physical Layer (PHY) Specifications for Low Rate 610 Wireless Personal Area Networks (WPANs)", September 2006. 612 [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network 613 Access Control", February 2010. 615 [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version 616 1.00", March 2009. 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 622 Levkowetz, "Extensible Authentication Protocol (EAP)", 623 RFC 3748, June 2004. 625 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 626 over Low-Power Wireless Personal Area Networks (6LoWPANs): 627 Overview, Assumptions, Problem Statement, and Goals", 628 RFC 4919, August 2007. 630 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 631 Yegin, "Protocol for Carrying Authentication for Network 632 Access (PANA)", RFC 5191, May 2008. 634 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 635 Authentication Protocol", RFC 5216, March 2008. 637 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 638 "Routing Requirements for Urban Low-Power and Lossy 639 Networks", RFC 5548, May 2009. 641 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 642 "Industrial Routing Requirements in Low-Power and Lossy 643 Networks", RFC 5673, October 2009. 645 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 646 sensor networks", IEEE Wireless Communications, vol. 11, 647 no. 6, pp. 54-61, December 2004. 649 [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical 650 Requirements Document", April 2010. 652 9.2. Informative References 654 [C1222] American National Standard, "Protocol Specification For 655 Interfacing to Data Communication Networks", ANSI C12.22- 656 2008, 2008. 658 [I-D.ietf-6lowpan-nd] 659 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 660 Discovery Optimization for Low-power and Lossy Networks", 661 draft-ietf-6lowpan-nd-13 (work in progress), 662 September 2010. 664 [I-D.ietf-core-coap] 665 Shelby, Z., Frank, B., and D. Sturek, "Constrained 666 Application Protocol (CoAP)", draft-ietf-core-coap-02 667 (work in progress), September 2010. 669 [I-D.ietf-roll-rpl] 670 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 671 Kelsey, R., Levis, P., Networks, D., Struik, R., and J. 672 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 673 Lossy Networks", draft-ietf-roll-rpl-12 (work in 674 progress), October 2010. 676 [I-D.moskowitz-hip-rg-dex] 677 Moskowitz, R., "HIP Diet EXchange (DEX)", 678 draft-moskowitz-hip-rg-dex-02 (work in progress), 679 July 2010. 681 [I-D.narten-iana-considerations-rfc2434bis] 682 Narten, T. and H. Alvestrand, "Guidelines for Writing an 683 IANA Considerations Section in RFCs", 684 draft-narten-iana-considerations-rfc2434bis-09 (work in 685 progress), March 2008. 687 [I-D.ohba-pana-keywrap] 688 Chakrabarti, S., Cragie, R., Duffy, P., Ohba, Y., and A. 689 Yegin, "Protocol for Carrying Authentication for Network 690 Access (PANA) Extension for Key Wrap", 691 draft-ohba-pana-keywrap-01 (work in progress), 692 October 2010. 694 [NISTIR7628VOL1] 695 The Smart Grid Interoperability Panel - Cyber Security 696 Working Group, "Guidelines for Smart Grid Cyber Security: 697 Vol. 1, Smart Grid Cyber Security Strategy, Architecture, 698 and High-Level Requirements", NISTIR 7628, vol. 1, 2010. 700 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 701 June 1999. 703 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 704 Text on Security Considerations", BCP 72, RFC 3552, 705 July 2003. 707 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 708 Neighbor Discovery (SEND)", RFC 3971, March 2005. 710 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 711 RFC 3972, March 2005. 713 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 714 for Transport Layer Security (TLS)", RFC 4279, 715 December 2005. 717 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 718 Security", RFC 4347, April 2006. 720 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 721 (HIP) Architecture", RFC 4423, May 2006. 723 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 724 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 726 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 727 Authentication Protocol (EAP) Key Management Framework", 728 RFC 5247, August 2008. 730 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 731 "Specification for the Derivation of Root Keys from an 732 Extended Master Session Key (EMSK)", RFC 5295, 733 August 2008. 735 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 736 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 737 RFC 5433, February 2009. 739 Appendix A. Examples of Node Configuration 741 Before any detail on methods is explored, the following section will 742 provide various examples this document could cover. Exact 743 requirements will be brought forward in subsequent sections. For the 744 reader's general understanding this section is placed to give an idea 745 of an acceptable usage scenario. 747 A.1. Smart Energy 749 A.1.1. Initial Meter Installation 751 The meter is initially loaded with code and network keys through a 752 physical interface at the factory. The meter is installed at a 753 customers home, and configured by the installer through the backbone 754 link (via GSM modem, etc). Both operations can be performed through 755 methods defined herein. 757 A.1.2. Home Expansions 759 The user wishes to join a thermostat onto the network. They press a 760 button on the thermostat, which enters join mode. They press a 761 button on the smart meter, which allows nodes to join the network. 762 The devices both have displays, so they display a certain number 763 which the user verifies match on both devices. The thermostat has 764 now securely joined the network. 766 A.2. Consumer Products 768 A.2.1. Connecting DVD Remote to DVD Player 770 The user pushes a join button on the DVD remote and DVD player. The 771 devices find each other, and blink in unison to indicate to the user 772 which two devices will join. The user presses the button to confirm 773 this, and the two devices are now joined together. 775 A.2.2. Adding a TV to a network with a DVD player and remote 777 The user then presses the join button on the DVD player and TV. The 778 devices again find each other and blink in unison, with the addition 779 that the remote control also blinks to indicate it is present in the 780 network. 782 A.2.3. Providing GPS Location Data 784 A user has a simple GPS receiver (that has no user interface) they 785 wish to broadcast location data with. The user switches on their 786 camera, and enters a PIN from the base of the GPS. The user can now 787 view GPS information such as satellite health from their camera. In 788 addition photos are automatically tagged with location information. 790 A.3. Commercial Building Automation 792 A.3.1. Light Installation 794 The electrician installs the light fixture. Each light has a barcode 795 printed on it. They use a handheld barcode scanner tool, which acts 796 as the commissioning tool. When they scan a barcode with the tool, 797 the tool asks the electrician to enter some additional information 798 such as light fixture location. The tool securely registers the 799 light fixture on the network, along with setting parameters inside 800 the light fixture. 802 Appendix B. Example Exchanges 804 The following details how the protocol handles certain conditions and 805 situations through examples. Note that each example is a more 806 detailed description of the examples in Appendix A. 808 B.1. Smart Energy: Meter Manufacture 810 B.2. Smart Energy: Meter Installation 812 B.3. Smart Energy: Home Expansion 814 B.4. Consumer: Connecting DVD Remote to DVD Player 816 Supported User Interface Profiles 818 +----------------+------------+----------------+ 819 | Profile | DVD Player | Remote Control | 820 +----------------+------------+----------------+ 821 | none | Y | Y | 822 | simple | Y | Y | 823 | numerical | Y | N | 824 | alphanumerical | Y | N | 825 | Graphical | Y | N | 826 +----------------+------------+----------------+ 827 Supported Bootstrap Transport Layers 829 +----------+------------+----------------+ 830 | Layer | DVD Player | Remote Control | 831 +----------+------------+----------------+ 832 | Physical | Y | Y | 833 | 802.15.4 | Y | Y | 834 | IrDA | Y | N | 835 +----------+------------+----------------+ 837 Supported Security Methods 839 +------------------+------------+----------------+ 840 | Method | DVD Player | Remote Control | 841 +------------------+------------+----------------+ 842 | None | Y | Y | 843 | EAP | Y | N | 844 | Asymmetric, User | Y | Y | 845 | Asymmetric, CA | Y | N | 846 +------------------+------------+----------------+ 848 The DVD player and remote control have a number of ways in which they 849 could be joined together. The remote control does not have any 850 unique identifier printed on it, thus no pre-shared key can be 851 identified. This leaves either an unsecure joining method, or some 852 asymmetric security method. 854 The remote control has a button on it for 'join', as does the DVD 855 player. The user pushes the button on the DVD player, and then 856 pushes the button on the remote control. Based on the UI profile, 857 this causes the following to occur: 859 o DVD Player scans for existing network in advertise mode. Finding 860 none, it starts a new network and that network enters advertise 861 mode. 863 o The DVD remote scans for a network, and then finds the DVD 864 player's network. 866 o The devices generate a shared secret (ie: Diffie-Hellman), and 867 both blink their LED in a unique pattern based on this shared 868 secret. 870 o The user user confirms both devices are blinking the same pattern, 871 as both LEDs are blinking in unison. 873 o The DVD player displays 'JOIN OK' on it's LCD panel. 875 B.5. Consumer: Adding a TV to a network with a DVD player and remote 877 This network will have three devices: a TV, a DVD Player, and a 878 Remote Control. The user will run the bootstrap protocol between the 879 TV and Remote Control in this example, although it could also be run 880 between the TV and DVD player. 882 Supported User Interface Profiles 884 +----------------+----+----------------+ 885 | Profile | TV | Remote Control | 886 +----------------+----+----------------+ 887 | none | Y | Y | 888 | simple | Y | Y | 889 | numerical | Y | N | 890 | alphanumerical | Y | N | 891 | Graphical | Y | N | 892 +----------------+----+----------------+ 894 Supported Bootstrap Transport Layers 896 +----------+----+----------------+ 897 | Layer | TV | Remote Control | 898 +----------+----+----------------+ 899 | Physical | Y | Y | 900 | 802.15.4 | Y | Y | 901 | IrDA | Y | N | 902 +----------+----+----------------+ 904 Supported Security Methods 906 +------------------+----+----------------+ 907 | Method | TV | Remote Control | 908 +------------------+----+----------------+ 909 | None | Y | Y | 910 | EAP-GPSK | Y | N | 911 | Asymmetric, User | Y | Y | 912 | Asymmetric, CA | Y | N | 913 +------------------+----+----------------+ 915 The TV and remote control have a number of ways in which they could 916 be joined together. The remote control does not have any unique 917 identifier printed on it, thus no pre-shared key can be identified. 918 This leaves either an unsecure joining method, or some asymmetric 919 security method. 921 The remote control has a button on it for 'join', as does the TV. In 922 this example two sequence will be considered: where the TV button is 923 pressed first, and where the remote control button is pressed first. 925 If the TV join button is pressed first: 927 o TV scans for existing networks in advertise mode. Finding none, 928 it starts a new network and that network enters advertise mode. 930 o The remote scans for a network, and then finds the TV's network. 932 o The remote informs the TV it is on an existing network, and thus 933 will require the TV to join this network. 935 o The devices generate a shared secret, and both blink their LED in 936 a unique pattern. 938 o The DVD player in addition blinks, so the user is informed that if 939 they confirm the join action the resulting network will have all 940 three devices in it. 942 o The user confirms both devices are blinking the same pattern, as 943 both LEDs are blinking in unison. 945 o The TV displays 'JOIN OK' onscreen, along with any information 946 about the network it just joined. 948 If the remote control join button is pressed first: 950 o Remote control scans for existing networks in advertise mode. 951 Finding none, it advertises it's network. 953 o The TV scans for a network, and then finds the remote control's 954 network. 956 o The devices generate a shared secret, and both blink their LED in 957 a unique pattern. 959 o The DVD player in addition blinks, so the user is informed that if 960 they confirm the join action the resulting network will have all 961 three devices in it. 963 o The user confirms both devices are blinking the same pattern, as 964 both LEDs are blinking in unison. 966 o The TV displays 'JOIN OK' onscreen, along with any information 967 about the network it just joined. 969 B.6. Consumer: Providing GPS Location Data 971 B.7. Commercial: Building Automation 973 Authors' Addresses 975 Colin Patrick O'Flynn 976 Atmel Corporation 977 Colorado Springs, Colorado 978 USA 980 Phone: 981 Email: colin.oflynn@atmel.com 983 Behcet Sarikaya 984 Huawei USA 985 1700 Alma Dr. Suite 500 986 Plano, TX 75075 988 Email: sarikaya@ieee.org 990 Yoshihiro Ohba 991 Toshiba 992 Tokyo, Japan 994 Email: yoshihiro.ohba@toshiba.co.jp 996 Zhen Cao 997 China Mobile 998 Beijing, China 1000 Email: caozhen@chinamobile.com 1002 Robert Cragie 1003 Pacific Gas and Electric 1004 89 Greenfield Crescent 1005 Wakefield, UK WF4 4WA 1007 Email: robert.cragie@gridmerge.com