idnits 2.17.1 draft-oflynn-core-bootstrapping-03.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 339 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 (November 8, 2010) is 4911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RF4CE' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC5433' is defined on line 806, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-14 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-03 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-14 == 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) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 6 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: May 12, 2011 Huawei USA 6 Y. Ohba 7 Toshiba 8 Z. Cao 9 China Mobile 10 R. Cragie 11 Pacific Gas and Electric 12 November 8, 2010 14 Security Bootstrapping of Resource-Constrained Devices 15 draft-oflynn-core-bootstrapping-03 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 May 12, 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. System Level Objectives . . . . . . . . . . . . . . . . . 10 93 5.2. EAP Authentication Framework . . . . . . . . . . . . . . . 10 94 5.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 5.4. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 5.5. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 103 Appendix A. Examples of Node Configuration . . . . . . . . . . . 19 104 A.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 19 105 A.1.1. Initial Meter Installation . . . . . . . . . . . . . . 19 106 A.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 19 107 A.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 20 108 A.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 20 109 A.2.2. Adding a TV to a network with a DVD player and 110 remote . . . . . . . . . . . . . . . . . . . . . . . . 20 111 A.2.3. Providing GPS Location Data . . . . . . . . . . . . . 20 112 A.3. Commercial Building Automation . . . . . . . . . . . . . . 20 113 A.3.1. Light Installation . . . . . . . . . . . . . . . . . . 20 114 Appendix B. Example Exchanges . . . . . . . . . . . . . . . . . . 20 115 B.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 20 116 B.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 20 117 B.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 21 118 B.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 21 119 B.5. Consumer: Adding a TV to a network with a DVD player 120 and remote . . . . . . . . . . . . . . . . . . . . . . . . 22 122 B.6. Consumer: Providing GPS Location Data . . . . . . . . . . 24 123 B.7. Commercial: Building Automation . . . . . . . . . . . . . 24 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 126 1. Introduction 128 Familiarity with constrained network types is assumed here. 129 Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups 130 (WGs) would be a useful reference for the reader. In particular RFC 131 4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] and RFC 5673 132 [RFC5673] from ROLL, CoAP [I-D.ietf-core-coap] from CoRE, and a paper 133 by Romer and Mattern [ROMER04]. Familiarity with application 134 specific examples such as Zigbee or Smart Energy groups is assumed. 136 A summary of those will be presented, as far as network requirements 137 are concerned. The general network requirements will be further 138 concentrated into requirements surrounding only the bootstrapping 139 issues. 141 A number of solutions which are currently in use will be presented. 142 Requirements on each solution will be stated to enable their use as a 143 security bootstrapping protocol. 145 1.1. What is Bootstrapping? 147 Node configuration is known as bootstrapping in this document. 148 Bootstrapping is any processing required before the network can 149 operate. Typically this will require a number of settings to be 150 transferred between nodes at all layers. This could include anything 151 from link-layer information (i.e., wireless channels, link-layer 152 encryption keys) to application-layer information (i.e., network 153 names, application encryption keys). 155 Bootstrapping is complete when settings have been securely 156 transferred prior to normal operation in the network. 158 1.2. Why IETF? 160 The bootstrapping problem is not specific to any MAC or PHY. This 161 problem exists across any two nodes which have no previous knowledge 162 of each other. In particular, this problem is complicated when the 163 nodes are resource-constrained and may not have an advanced user 164 interface. The IETF is instrumental in defining standards which will 165 be used by The Internet of Things. Ensuring these standards can be 166 used across nodes and networks requires some form of bootstrapping 167 which any node can use. 169 Existing standards will be used as much as possible in this document. 170 The method proposed here should work across many different underlying 171 layers. It could be used to allow two nodes on the same physical 172 network to join at the physical layer, or allow two nodes on an 173 incompatible physical network to join at the IPv6 layer. 175 2. Bootstrapping Architecture 177 2.1. Areas of Boostrapping 179 In order to provide a flexible architecture, the bootstrapping method 180 is split into five distinct areas and two distinct phases. The five 181 areas are a 'user interface', 'bootstrap profile', 'security method', 182 'bootstrap protocol', and the 'communications channel'. 184 The phases are provisioning phase and bootstrapping phase. In the 185 provisioning phase, statically configured parameters (e.g., 186 certificates) needed for the bootstrapping phase is provisioned. In 187 the bootstrapping phase, dynamically configured information is set up 188 using the statically configured information provided in the 189 provisioning phase. 191 The user interface provides both user input and user output. Simple 192 nodes may only have a push-button and LED, more complex nodes may 193 have a graphical display and keyboard. The user interface provides 194 interaction between the user and bootstrapping methods. The user 195 interface would be used during bootstrapping as an OOB channel. It 196 may also be used to 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 The 'security method' defines supported security methods for 230 bootstrapping. The supported security methods will depend on the 231 control channel and bootstrap profile. In one node if the control 232 channel is secure, then a simple clear-text security method is 233 supported. For example when a physical connection between two nodes 234 is used, the control channel is considered secure. However when the 235 control channel is not secure, this clear-text security method is not 236 supported. The 'bootstrap profile' additionally defines allowed 237 security methods. Higher security nodes may outlaw ever performing a 238 clear-text exchange, even if the control channel is deemed secure. 240 The 'bootstrap protocol' defines the actual messages exchanged during 241 bootstrapping. The messages are used to transfer between nodes data, 242 node information, and network state. The selected security method 243 runs on top of the control channel, such as EAP-GPSK etc. 245 2.2. Architecture 247 Security bootstrapping architecture is structured in a hierarchy of 248 nodes going from the least resource constraint to the most resource 249 constraint. At the top there is a root node. The root node is 250 called Coordinator or Trust Center in Zigbee and 6LowWAN Border 251 Router (6LBR) in 6LoWPAN ND. 253 At the next level there are interior Routers. Routers are able to 254 run a routing protocol between other routers and the root. Router 255 are called 6LowWAN Routers (6BR) in 6LoWPAN ND. 257 At the lowest level there are the nodes. The nodes do not run a 258 routing protocol. They can connect to the nearest router over a 259 single radio link. The nodes are called End Device in Zigbee and 260 host in in 6LoWPAN ND. 262 Routers first join the network as a node and go through security 263 bootstrapping operations in order to create a Master Session Key 264 (MSK). Next routers execute routing protocol, e.g. 265 [I-D.ietf-roll-rpl] specific steps to create session keys with their 266 neighbors and to establish upstream and downstream next hop parents. 268 At each node hierarachy level described above, there are lower-layer 269 and higher-layer protocols to bootstrap their ciphering keys, where 270 the lower-layer refers to layers below IP layer including IEEE 271 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer 272 refers to IP layer and the above. In general, required bootstrapping 273 procedures depend on the bootstrapping protocols to use. Section 274 Section 5 describes the bootstrapping procedures where EAP 275 (Extensible Authentication Protocol) [RFC3748] and other protocols 276 are used as the bootstrapping protocols. 278 3. Communications Channel 280 The communications channel is the method used between two nodes to 281 communicate. There are two main communication channels: the 282 'control' and 'data' channels. The control channel is used during 283 bootstrapping, and the data channel is used during network operation. 285 3.1. Supported Communication Channels 287 There is no limit on what communications channels are supported. The 288 following gives an example of several supported channels: 290 o IEEE 802.15.4 292 o Power-Line Communications 294 o IrDA 296 o RFID 298 o Some simple physical link 300 o Cellular 302 o Ethernet 304 o IPv6 306 o Wi-Fi 308 Depending on the node's function, it may use different channels as 309 the data or control channel. Nodes may have multiple data and/or 310 control channels as wel. 312 4. Bootstrap Security Method 314 The bootstrap security method defines allowable security methods. A 315 node may choose to support or use a subset of these methods. This is 316 NOT the security architecture used for the application, but only the 317 security used during bootstrapping. Typically some high-security 318 method is used to generate a shared secret, which then switches to 319 simplier symmetric encryption to secure the actual bootstrapping 320 channel. The techniques negotiated should take advantage of hardware 321 resources available, such as hardware encryption accelerators on an 322 end node. 324 4.1. None 326 This is the simplist security method. No encryption or 327 authentication is provided, messages are exchanged completely in 328 clear-text. It is assumed some other layer provides security, such 329 as a physical connection between devices. 331 4.2. Asymmetric with User Authentication, Followed by Symmetric 333 A Diffie-Hellman style key exchange is used to generate a shared 334 secret. The authentication will be provided by the user, by 335 confirming cryptographic signatures between two devices. With the 336 shared secret generated through the DH, some symmetric encryption is 337 used to secure the actual bootstrapping channel. 339 4.3. Asymmetric with Certificate Authority, Followed by Symmetric 341 Public key exchanges are used (aka: DH again), but with a Certificate 342 Authority. Once a shared secret exists, symmetric encryption is used 343 to secure the actual bootstrapping channel. 345 4.4. Cryptographically Generated Address Based Address Ownership 346 Verification 348 A node may generate the global unique address using different 349 techniques other than the stateless address autoconfiguration. For 350 example, Cryptographically Generated Addresses (CGA) [RFC3972] is a 351 type of global unique address that can be used to verify the address 352 ownership. When the node uses CGA, it MUST execute SeND protocol 353 [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol 354 [I-D.ietf-6lowpan-nd] must be executed between the node and the edge 355 router. 357 5. Bootstrap Protocols 359 In this section we first present system level objectives that 360 security bootstrapping protocols are expected to achieve. Next, we 361 present EAP authentication framework and then describe three 362 different protocols. 364 5.1. System Level Objectives 366 Authentication/ reauthentication: nodes joining the network MUST at 367 the first place authenticate to the trust center. In order to 368 achieve secure multi-hop routing, the node MUST authenticate to its 369 upstream and downstream neighbors. A bootstrapping solution MUST 370 support re-authentication of resource-constrained devices and re- 371 keying of dynamically generated keys. 373 Data Confidentiality: the data communication between two endpoints 374 MAY be encrypted using the derived key, avoiding being eavesdropped 375 by a non-trusted third part. 377 Data Integrity: the data communication between two endpoints MUST NOT 378 be altered by some intermediate nodes. The nodes should be able to 379 detect the non-integral data. 381 Keys and key freshness: the keys used for data communication MUST 382 have a lifetime, in order to keep their freshness. A bootstrapping 383 solution MUST support both symmetric and asymmetric key 384 authentication. If distribution of a key to be used for a resource- 385 constrained device is required, a bootstrapping solution MUST support 386 secure key distribution to prevent the key from eavesdropping, 387 alternation and replay attacks. 389 Multi domain support: A bootstrapping solution MUST be able to allow 390 resource-constrained devices that may be subscribed to different 391 administrative domains to be connected to the same access network at 392 the same time. 394 Identities: A bootstrapping solution MUST be able to allow a 395 resource-constrained device to use various types of identities used 396 for authentication, including device identities, user identities or 397 combinations of different types of identities. Also a bootstrapping 398 solution MUST be able to allow a resource-constrained device to 399 change its identities used for authentication over time. 401 Authentication infrastructure: A bootstrapping solution MUST be able 402 to operate with or without an authentication infrastructure. 404 5.2. EAP Authentication Framework 406 In EAP, there are three distinct entities: the client or EAP peer, 407 the authenticator and the authentication or EAP server [RFC5247]. 409 The EAP peer is the node that requires to be authenticated before 410 being admitted to the network. The authentication server is the 411 device authenticating the node for bootstrapping. The authenticator 412 is the device that is admitting the node to the network and it 413 resides in between the peer and authentication server. 415 EAP client and EAP server exchange EAP messages to execute the 416 authentication algorithm, a.k.a. EAP method. The authenticator is 417 responsible for forwarding EAP messages between the client and 418 server. In 802.1X, EAP messages are carried in Layer 2 and in PANA 419 in IP or Layer 3. EAP messages between the authenticator and 420 authentication server are carried using AAA protocols (RADIUS or 421 Diameter). 423 At the end of a successful EAP method execution a master session key 424 (MSK) is generated at both the EAP peer and EAP server. 425 Authenticator receives MSK from EAP server at the end of EAP method 426 execution using key transport. MSK is used in deriving a session key 427 between the node and the authenticator using a protocol called secure 428 association protocol (SAP). Derivation of the session key terminates 429 bootstrapping of a node. 431 Additional keying material derived between EAP client and server that 432 is exported by the EAP method is called Extended Master Session Key 433 (EMSK). EMSK is not used in session key derivation but it could be 434 used for the needs of other applications in higher layer protocols. 436 In the architecture introduced in Section 2.2 the node or router is 437 the peer and the root is the authenticator. When the supplicant and 438 authenticator are one hop away the authenticator can be reached 439 directly. However, this is rarely the case. In other cases the 440 authenticator authenticates neighboring supplicants first. The 441 router nodes that are authenticated become relay authenticators in 442 the next phase and they relay authentication messages from the 443 supplicants to the authenticator and vice versa. This continues 444 until all nodes are authenticated. 446 EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request 447 messages sent by the server and EAP-Response messages sent by the 448 peer. At the end, the server indicates the status of authentication, 449 usually by EAP-Success message which also carries the MSK. The first 450 EAP-Request/Response pair is used for the server to request the 451 identity and the peer to provide it. In the other pairs of EAP 452 exchanges EAP method is executed. 454 Several EAP methods have been standardized each for different 455 purposes. To authenticate devices with certificates, EAP Transport 456 Layer Security (TLS) v1.2 specified in [RFC5216] which supports 457 certificate-based mutual authentication is used. 459 Smart Energy Profile 2.0 Application Protocol Specification [SE2.0] 460 mandates each device to be factory programmed with a certificate. 461 The certificate is bound to a unique network ID, e.g. the device's 462 MAC address or EUI-64 address. During EAP-Identity exchange the EAP 463 peer provides its EUI-64 address as an identity to EAP server. This 464 enables the server to validate the device certificate. 466 5.3. PANA 468 PANA (Protocol for carrying Authentication for Network Access) 469 [RFC5191] defines an EAP transport over UDP where a PANA Client (PaC) 470 is an EAP peer and a PANA Authentication Agent (PAA) is an EAP 471 authenticator. There are three bootstrapping scenarios using PANA. 473 1. Use of PANA for bootstrapping link-layer security. 475 In this case, PANA is used for network access authentication to 476 bootstrap link-layer ciphering. Security for higher-layer (i.e., 477 IP layer and above) protocols is bootstrapped from an IB or OOB 478 mechanism other than PANA. For example, in a 6LoWPAN deployment 479 PANA authentication can take place to bootstrap IEEE 802.15.4 MAC 480 layer ciphering keys. In ZigBee IP, IEEE 802.15.4 MAC layer 481 ciphering keys used as session keys are derived from a group key 482 so called a Network Key that is securely distributed to each 483 joining node upon successful PANA authentication using AES key 484 wrap over PANA [I-D.ohba-pana-keywrap] where the key encryption 485 key is derived from the EAP MSK (Master Session Key) [RFC3748]. 487 2. Use of PANA for bootstrapping higher-layer security. 489 In this scenario, PANA is used as an OOB mechanism for higher- 490 layer authentication to bootstrap ciphering keys for one or more 491 higher-layer protocols independently of network access 492 authentication. The PAA may reside in a higher-layer network 493 element such as an ANSI C12.22 authentication host [C1222] and a 494 CoAP server, or an independent server dedicated for service 495 authentication for multiple higher-layer protocols. When 496 bootstrapping ANSI C12.22 security for which no IB key management 497 mechanism is available, ANSI C12.22 ciphering keys are directly 498 derived from EAP key material established from PANA 499 authentication. When bootstrapping CoAP security with DTLS 500 protection, a PSK (Pre-Shared Key) credential in the combined 501 usage of DTLS (Datagram Transport Layer Security) [RFC4347] and 502 PSK mode of TLS [RFC4279] is derived from EAP key material and 503 DTLS ciphering keys are generated as a result of a successful 504 DTLS handshake. Similarly, when bootstrapping CoAP security with 505 IPsec ESP protection, a PSK credential of IKEv2 [RFC5996] is 506 derived from EAP key material and IPsec ESP ciphering keys are 507 generated as a result of a successful IKEv2 handshake. 509 The ability to bootstrap multiple higher-layer protocols from a 510 single execution of PANA authentication is important to save the 511 computational resources for resource-constrained devices 512 especially where public-key based authentication is used. 514 3. Use of PANA for bootstrapping both link-layer and higher-layer 515 security. 517 This case is the combination of the other two cases, and the most 518 optimized way for bootstrapping resource-constrained devices. 519 This case is only applicable where both the network access 520 authentication and the higher-layer authentication use the same 521 authentication server with the same authentication credentials. 523 The second and third scenarios are generally referred to as Single 524 Sign-On in section 4.2.2.2 of [NISTIR7628VOL1], where the root keys 525 for higher-layer protocols can be derived from EAP EMSK (Extended 526 Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295]. 528 A PANA Relay Element (PRE) is needed to enable PANA messaging between 529 a PANA Client (PaC) which is the node to be authenticated and a PANA 530 Authentication Agent (PAA) which is the authenticator where the two 531 nodes cannot reach each other by means of regular IP routing. This 532 happens during authentication since only a link-local IPv6 address 533 can be used prior to the completion of a succesful authentication. 535 PRE which is one hop away from PaC receives PANA messages and relays 536 the message contents (payload) by encapsulating it in a message 537 parameter called Attribute Value Pair (AVP). PRE also needs to send 538 header contents such as PaC's IP address and UDP port number in a 539 different AVP. PRE has IP routing established with PAA which could 540 be several hops away. PAA sends its reply messages in which the 541 payload is encapsulated in an AVP. It also adds the AVP containing 542 PaC's IP address and UDP port number. PRE sends creates a link local 543 PDU using these AVPs and sends it to PaC. 545 The requirements for the use of PANA as a bootsrapping protocol can 546 be stated as follows: 548 o A new entity called PANA Relay Element needs to be added to the 549 PANA architecture. Behaviour of PANA Relay Element needs to be 550 defined. 552 o New AVPs needed for PANA Relay Element operation for properly 553 relaying messages from the client to the authenticator and vice 554 versa are required to be specified. 556 o An extension to PANA to securely distribute keys from the PANA 557 Authentication Agent to the PANA Client using AES Key Wrap with 558 Padding algorithm needs to be defined. This is needed in order to 559 use PANA for group key distribution. 561 5.4. HIP-DEX 563 [RFC4423] introduces the Host Identity Protocol (HIP) where the Host 564 Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit 565 length Host Identity Tag (HIT) is derived from the HI (hashed) and 566 functions as an IPv6 address (/128 prefix) for applications. A four- 567 packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX) 568 establishes a security association (SA, similar to IKE), indexed by 569 the HITs, but independent of the IP address. So HIP can be 570 considered as a shim layer between the transport(TCP/UDP) and IP, 571 providing authentication, data confidentiality, mobility in one 572 basket. 574 The HIP-BEX involves many crypto primitives that are difficult to run 575 on constrained nodes. HIP Diet Exchange (HIP-DEX) 576 [I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight. 577 Basically, HIP-DEX a variant of the HIP-BEX specifically designed to 578 use as few crypto primitives as possible yet still provide the same 579 class of security features as HIP-BEX. 581 HIP-DEX can be used for mutual authentication between two endpoints. 582 After mutual authentication, the two endpints establish a shared 583 secret, which is fresh and fed into the encryption algorithm for data 584 confidentiality. So HIP-DEX can achieve the authentication, key 585 freshness and data confidentiality objectives of security 586 bootstrapping. 588 When a node wants to authenticate to the network using HIP and Diet- 589 HIP, it should be able to complete the HIP-BEX or HIP-DEX with the 590 trust anchor or some delegate. In HIP, it does not matter how many 591 domains, and nodes can authenticate each other as long as they have 592 the secret. 594 In the architecture introduced in Section 2.2 the node and router 595 could be the HIP end-points. Depending on who initiates the HIP Diet 596 Exchange, the node or router could act as the HIP initiator and HIP 597 responder respectively. And the initiator and responder can be 598 multiple hops way from each other, as long as there is an IP 599 connectivity between them. 601 An important requirement for the HIP-DEX to work in the architecture, 602 the initiator should be able to get the IP address of the responder, 603 either using DNS infrastructure or local configuration. 605 5.5. 802.1X 607 IEEE 802.1X defines how EAP packets can be transported over in Layer 608 2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into 609 EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and 610 the authenticator. EAPOL can also be used in 802.11 wireless links. 612 To enable IEEE 802.15.4 devices to use EAP authentication, EAP 613 packets encapsulated in EAPOL frames can be carried as payload in 614 802.15.4 data frames [802.15.4]. EAPOL is well defined and widely 615 used and it lends itself to be easily carried in 802.15.4 data 616 frames. For this, Frame Type subfield of the Frame Control Field of 617 IEEE 802.15.4 MAC header needs to be set to a special value to 618 indicate the type of the payload, i.e. 802.1X encapsulated EAP 619 packets. EAPOL packets are encoded following common EAPOL PDU 620 structure defined in [802.1x] into the data payload field of 802.15.4 621 data frames. 623 Authentication proceeds as follows: authenticator authenticates the 624 supplicants that are on the next hop first. This enables a secure 625 link between the authenticator and these first-hop nodes. First-hop 626 nodes or router become Relay Authenticators in the next phase of 627 authentication. Relay authenticators tunnel EAPOL frames to the 628 authenticator in the secure link established. This way all the 629 supplicants are gradually authenticated. 631 The keys established from a successful EAP method (such as PSK mode 632 of TLS), the node runs neighbor discovery protocol to get an IPv6 633 address assigned [I-D.ietf-6lowpan-nd]. Data transfer can be secured 634 using DTLS or IPSec. Keys derived from EAP TLS are used in either 635 generating DTLS ciphering keys after a successful DTLS handshake or 636 IPSec ESP ciphering keys after a successful IKEv2 handshake. 638 802.1X can achieve the authentication, key freshness and data 639 confidentiality objectives of security bootstrapping. Multi domain 640 operation is intrinsically supported due to the use of EAP and AAA. 642 The requirements for the use of 802.1X defined EAPOL as a 643 bootsrapping protocol can be stated as follows: 645 o A special value in the Frame Type subfield of the Frame Control 646 Field of IEEE 802.15.4 MAC header to indicate the type of the 647 payload, 649 o Group addresses for 802.15.4 corresponding to EAPOL Group Address 650 Assignments defined in Table 11.1 of [802.1x], especially to be 651 used in EAPOL-Start packet. 653 o Which MAC frames of beacon, data, acknowledgment and MAC command 654 as defined in [802.15.4] with what security levels are mapped to 655 controlled port, which MAC frames with what security levels are 656 mapped to uncontrolled port and which MAC frames are never mapped 657 to any of controlled/uncontrolled port (i.e., the payload of those 658 frames are used by the MAC-ayer ieself and never used by upper 659 layers). 661 6. Security Considerations 663 TBD. 665 7. IANA Considerations 667 This memo includes no request to IANA. 669 8. Acknowledgements 671 Thanks to Zach Shelby for editing, comments, and overall assistance. 672 Special thanks also to Rene Struik and Carsten Borman for their 673 comments that helped us improve the writing. 675 9. References 677 9.1. Normative References 679 [802.15.4] 680 IEEE Std 802.15.4-2006, "Wireless Medium Access Control 681 (MAC) and Physical Layer (PHY) Specifications for Low Rate 682 Wireless Personal Area Networks (WPANs)", September 2006. 684 [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network 685 Access Control", February 2010. 687 [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version 688 1.00", March 2009. 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, March 1997. 693 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 694 Levkowetz, "Extensible Authentication Protocol (EAP)", 695 RFC 3748, June 2004. 697 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 698 over Low-Power Wireless Personal Area Networks (6LoWPANs): 699 Overview, Assumptions, Problem Statement, and Goals", 700 RFC 4919, August 2007. 702 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 703 Yegin, "Protocol for Carrying Authentication for Network 704 Access (PANA)", RFC 5191, May 2008. 706 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 707 Authentication Protocol", RFC 5216, March 2008. 709 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 710 "Routing Requirements for Urban Low-Power and Lossy 711 Networks", RFC 5548, May 2009. 713 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 714 "Industrial Routing Requirements in Low-Power and Lossy 715 Networks", RFC 5673, October 2009. 717 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 718 sensor networks", IEEE Wireless Communications, vol. 11, 719 no. 6, pp. 54-61, December 2004. 721 [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical 722 Requirements Document", April 2010. 724 9.2. Informative References 726 [C1222] American National Standard, "Protocol Specification For 727 Interfacing to Data Communication Networks", ANSI C12.22- 728 2008, 2008. 730 [I-D.ietf-6lowpan-nd] 731 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 732 Discovery Optimization for Low-power and Lossy Networks", 733 draft-ietf-6lowpan-nd-14 (work in progress), October 2010. 735 [I-D.ietf-core-coap] 736 Shelby, Z., Frank, B., and D. Sturek, "Constrained 737 Application Protocol (CoAP)", draft-ietf-core-coap-03 738 (work in progress), October 2010. 740 [I-D.ietf-roll-rpl] 741 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 742 Kelsey, R., Levis, P., Networks, D., Struik, R., and J. 743 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 744 Lossy Networks", draft-ietf-roll-rpl-14 (work in 745 progress), October 2010. 747 [I-D.moskowitz-hip-rg-dex] 748 Moskowitz, R., "HIP Diet EXchange (DEX)", 749 draft-moskowitz-hip-rg-dex-02 (work in progress), 750 July 2010. 752 [I-D.narten-iana-considerations-rfc2434bis] 753 Narten, T. and H. Alvestrand, "Guidelines for Writing an 754 IANA Considerations Section in RFCs", 755 draft-narten-iana-considerations-rfc2434bis-09 (work in 756 progress), March 2008. 758 [I-D.ohba-pana-keywrap] 759 Chakrabarti, S., Cragie, R., Duffy, P., Ohba, Y., and A. 760 Yegin, "Protocol for Carrying Authentication for Network 761 Access (PANA) Extension for Key Wrap", 762 draft-ohba-pana-keywrap-01 (work in progress), 763 October 2010. 765 [NISTIR7628VOL1] 766 The Smart Grid Interoperability Panel - Cyber Security 767 Working Group, "Guidelines for Smart Grid Cyber Security: 768 Vol. 1, Smart Grid Cyber Security Strategy, Architecture, 769 and High-Level Requirements", NISTIR 7628, vol. 1, 2010. 771 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 772 June 1999. 774 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 775 Text on Security Considerations", BCP 72, RFC 3552, 776 July 2003. 778 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 779 Neighbor Discovery (SEND)", RFC 3971, March 2005. 781 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 782 RFC 3972, March 2005. 784 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 785 for Transport Layer Security (TLS)", RFC 4279, 786 December 2005. 788 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 789 Security", RFC 4347, April 2006. 791 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 792 (HIP) Architecture", RFC 4423, May 2006. 794 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 795 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 797 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 798 Authentication Protocol (EAP) Key Management Framework", 799 RFC 5247, August 2008. 801 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 802 "Specification for the Derivation of Root Keys from an 803 Extended Master Session Key (EMSK)", RFC 5295, 804 August 2008. 806 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 807 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 808 RFC 5433, February 2009. 810 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 811 "Internet Key Exchange Protocol Version 2 (IKEv2)", 812 RFC 5996, September 2010. 814 Appendix A. Examples of Node Configuration 816 Before any detail on methods is explored, the following section will 817 provide various examples this document could cover. Exact 818 requirements will be brought forward in subsequent sections. For the 819 reader's general understanding this section is placed to give an idea 820 of an acceptable usage scenario. 822 A.1. Smart Energy 824 A.1.1. Initial Meter Installation 826 The meter is initially loaded with code and network keys through a 827 physical interface at the factory. The meter is installed at a 828 customers home, and configured by the installer through the backbone 829 link (via GSM modem, etc). Both operations can be performed through 830 methods defined herein. 832 A.1.2. Home Expansions 834 The user wishes to join a thermostat onto the network. They press a 835 button on the thermostat, which enters join mode. They press a 836 button on the smart meter, which allows nodes to join the network. 837 The devices both have displays, so they display a certain number 838 which the user verifies match on both devices. The thermostat has 839 now securely joined the network. 841 A.2. Consumer Products 843 A.2.1. Connecting DVD Remote to DVD Player 845 The user pushes a join button on the DVD remote and DVD player. The 846 devices find each other, and blink in unison to indicate to the user 847 which two devices will join. The user presses the button to confirm 848 this, and the two devices are now joined together. 850 A.2.2. Adding a TV to a network with a DVD player and remote 852 The user then presses the join button on the DVD player and TV. The 853 devices again find each other and blink in unison, with the addition 854 that the remote control also blinks to indicate it is present in the 855 network. 857 A.2.3. Providing GPS Location Data 859 A user has a simple GPS receiver (that has no user interface) they 860 wish to broadcast location data with. The user switches on their 861 camera, and enters a PIN from the base of the GPS. The user can now 862 view GPS information such as satellite health from their camera. In 863 addition photos are automatically tagged with location information. 865 A.3. Commercial Building Automation 867 A.3.1. Light Installation 869 The electrician installs the light fixture. Each light has a barcode 870 printed on it. They use a handheld barcode scanner tool, which acts 871 as the commissioning tool. When they scan a barcode with the tool, 872 the tool asks the electrician to enter some additional information 873 such as light fixture location. The tool securely registers the 874 light fixture on the network, along with setting parameters inside 875 the light fixture. 877 Appendix B. Example Exchanges 879 The following details how the protocol handles certain conditions and 880 situations through examples. Note that each example is a more 881 detailed description of the examples in Appendix A. 883 B.1. Smart Energy: Meter Manufacture 885 B.2. Smart Energy: Meter Installation 886 B.3. Smart Energy: Home Expansion 888 B.4. Consumer: Connecting DVD Remote to DVD Player 890 Supported User Interface Profiles 892 +----------------+------------+----------------+ 893 | Profile | DVD Player | Remote Control | 894 +----------------+------------+----------------+ 895 | none | Y | Y | 896 | simple | Y | Y | 897 | numerical | Y | N | 898 | alphanumerical | Y | N | 899 | Graphical | Y | N | 900 +----------------+------------+----------------+ 902 Supported Bootstrap Transport Layers 904 +----------+------------+----------------+ 905 | Layer | DVD Player | Remote Control | 906 +----------+------------+----------------+ 907 | Physical | Y | Y | 908 | 802.15.4 | Y | Y | 909 | IrDA | Y | N | 910 +----------+------------+----------------+ 912 Supported Security Methods 914 +------------------+------------+----------------+ 915 | Method | DVD Player | Remote Control | 916 +------------------+------------+----------------+ 917 | None | Y | Y | 918 | EAP | Y | N | 919 | Asymmetric, User | Y | Y | 920 | Asymmetric, CA | Y | N | 921 +------------------+------------+----------------+ 923 The DVD player and remote control have a number of ways in which they 924 could be joined together. The remote control does not have any 925 unique identifier printed on it, thus no pre-shared key can be 926 identified. This leaves either an unsecure joining method, or some 927 asymmetric security method. 929 The remote control has a button on it for 'join', as does the DVD 930 player. The user pushes the button on the DVD player, and then 931 pushes the button on the remote control. Based on the UI profile, 932 this causes the following to occur: 934 o DVD Player scans for existing network in advertise mode. Finding 935 none, it starts a new network and that network enters advertise 936 mode. 938 o The DVD remote scans for a network, and then finds the DVD 939 player's network. 941 o The devices generate a shared secret (ie: Diffie-Hellman), and 942 both blink their LED in a unique pattern based on this shared 943 secret. 945 o The user user confirms both devices are blinking the same pattern, 946 as both LEDs are blinking in unison. 948 o The DVD player displays 'JOIN OK' on it's LCD panel. 950 B.5. Consumer: Adding a TV to a network with a DVD player and remote 952 This network will have three devices: a TV, a DVD Player, and a 953 Remote Control. The user will run the bootstrap protocol between the 954 TV and Remote Control in this example, although it could also be run 955 between the TV and DVD player. 957 Supported User Interface Profiles 959 +----------------+----+----------------+ 960 | Profile | TV | Remote Control | 961 +----------------+----+----------------+ 962 | none | Y | Y | 963 | simple | Y | Y | 964 | numerical | Y | N | 965 | alphanumerical | Y | N | 966 | Graphical | Y | N | 967 +----------------+----+----------------+ 969 Supported Bootstrap Transport Layers 971 +----------+----+----------------+ 972 | Layer | TV | Remote Control | 973 +----------+----+----------------+ 974 | Physical | Y | Y | 975 | 802.15.4 | Y | Y | 976 | IrDA | Y | N | 977 +----------+----+----------------+ 978 Supported Security Methods 980 +------------------+----+----------------+ 981 | Method | TV | Remote Control | 982 +------------------+----+----------------+ 983 | None | Y | Y | 984 | EAP-GPSK | Y | N | 985 | Asymmetric, User | Y | Y | 986 | Asymmetric, CA | Y | N | 987 +------------------+----+----------------+ 989 The TV and remote control have a number of ways in which they could 990 be joined together. The remote control does not have any unique 991 identifier printed on it, thus no pre-shared key can be identified. 992 This leaves either an unsecure joining method, or some asymmetric 993 security method. 995 The remote control has a button on it for 'join', as does the TV. In 996 this example two sequence will be considered: where the TV button is 997 pressed first, and where the remote control button is pressed first. 999 If the TV join button is pressed first: 1001 o TV scans for existing networks in advertise mode. Finding none, 1002 it starts a new network and that network enters advertise mode. 1004 o The remote scans for a network, and then finds the TV's network. 1006 o The remote informs the TV it is on an existing network, and thus 1007 will require the TV to join this network. 1009 o The devices generate a shared secret, and both blink their LED in 1010 a unique pattern. 1012 o The DVD player in addition blinks, so the user is informed that if 1013 they confirm the join action the resulting network will have all 1014 three devices in it. 1016 o The user confirms both devices are blinking the same pattern, as 1017 both LEDs are blinking in unison. 1019 o The TV displays 'JOIN OK' onscreen, along with any information 1020 about the network it just joined. 1022 If the remote control join button is pressed first: 1024 o Remote control scans for existing networks in advertise mode. 1025 Finding none, it advertises it's network. 1027 o The TV scans for a network, and then finds the remote control's 1028 network. 1030 o The devices generate a shared secret, and both blink their LED in 1031 a unique pattern. 1033 o The DVD player in addition blinks, so the user is informed that if 1034 they confirm the join action the resulting network will have all 1035 three devices in it. 1037 o The user confirms both devices are blinking the same pattern, as 1038 both LEDs are blinking in unison. 1040 o The TV displays 'JOIN OK' onscreen, along with any information 1041 about the network it just joined. 1043 B.6. Consumer: Providing GPS Location Data 1045 B.7. Commercial: Building Automation 1047 Authors' Addresses 1049 Colin Patrick O'Flynn 1050 Atmel Corporation 1051 Colorado Springs, Colorado 1052 USA 1054 Phone: 1055 Email: colin.oflynn@atmel.com 1057 Behcet Sarikaya 1058 Huawei USA 1059 1700 Alma Dr. Suite 500 1060 Plano, TX 75075 1062 Email: sarikaya@ieee.org 1064 Yoshihiro Ohba 1065 Toshiba 1066 Tokyo, Japan 1068 Email: yoshihiro.ohba@toshiba.co.jp 1069 Zhen Cao 1070 China Mobile 1071 Beijing, China 1073 Email: caozhen@chinamobile.com 1075 Robert Cragie 1076 Pacific Gas and Electric 1077 89 Greenfield Crescent 1078 Wakefield, UK WF4 4WA 1080 Email: robert.cragie@gridmerge.com