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