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