idnits 2.17.1 draft-sarikaya-solace-setup-framework-00.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 66 has weird spacing: '...mmetric with ...' == Line 250 has weird spacing: '...mmetric with ...' -- The document date (September 17, 2012) is 4238 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: 'RFC3748' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 701, but no explicit reference was found in the text ** 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 (-06) exists of draft-garcia-core-security-04 -- 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 (~~), 8 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: March 21, 2013 Toshiba 6 R. Moskowitz 7 Verizon Business Systems 8 Z. Cao 9 China Mobile 10 R. Cragie 11 Pacific Gas and Electric 12 September 17, 2012 14 Framework for Securely Setting Up Smart Objects 15 draft-sarikaya-solace-setup-framework-00 17 Abstract 19 This document describes a framework for initially configuring smart 20 objects securely. Initial setup architecture, communication channel 21 and bootstrap security methods are described. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 21, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 4 60 3.1. Areas of Boostrapping . . . . . . . . . . . . . . . . . . 4 61 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 6 63 4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Asymmetric with User Authentication, Followed by 65 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.3. Asymmetric with Certificate Authority, Followed by 67 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.4. Cryptographically Generated Address Based Address 69 Ownership Verification . . . . . . . . . . . . . . . . . . 6 70 5. Secure Bootstrapping System Level Objectives . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. EAP, PANA, HIP-DEX and 802.1X . . . . . . . . . . . . . . . . 9 73 7.1. EAP Authentication Framework . . . . . . . . . . . . . . . 9 74 7.2. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.3. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.4. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 IP-based constrained devices in the Internet of Things (IOT) are 87 being used in Machine-to-Machine (M2M) applications ranging from 88 building automation to production environments to smart metering to 89 personal area networks (PAN). Constrained devices in these 90 applications may be very different "things" such as a temperature 91 sensor, a luminaire, or an RFID tag and might interact with each 92 other, with a smart phone, or with backend services. The 93 introduction of IPv6 and web services as fundamental building blocks 94 enables these devices to be networked and at the same time it 95 introduces security vulnarabilities [I-D.garcia-core-security]. 97 Bootstrapping is any processing required before the network can 98 operate. Typically this will require a number of settings to be 99 transferred between nodes at all layers. This could include anything 100 from link-layer information (i.e., wireless channels, link-layer 101 encryption keys) to application-layer information (i.e., network 102 names, application encryption keys). 104 Bootstrapping is complete when settings have been securely 105 transferred prior to normal operation in the network. 107 The bootstrapping problem is not specific to any MAC or PHY. This 108 problem exists across any two nodes which have no previous knowledge 109 of each other. In particular, this problem is complicated when the 110 nodes are resource-constrained and may not have an advanced user 111 interface. The IETF is instrumental in defining standards which will 112 be used by the Internet of Things (IOT). Ensuring these standards 113 can be used across nodes and networks requires some form of 114 bootstrapping which the sensor nodes can use [ROMER04]. 116 Existing standards will be used as much as possible in this document. 117 The method proposed here should work across many different underlying 118 layers. It could be used to allow two nodes on the same physical 119 network to join at the physical layer, or allow two nodes on an 120 incompatible physical network to join at the IPv6 layer. 122 The document continues in Section 3 on bootstrapping architecture, in 123 Section 4 on allowable security methods in bootstrapping, in 124 Section 5 on system level objectives of securely setting up the 125 constrained nodes. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Bootstrapping Architecture 135 3.1. Areas of Boostrapping 137 In order to provide a flexible architecture, the bootstrapping method 138 is split into five distinct areas and two distinct phases. The five 139 areas are a 'user interface', 'bootstrap profile', 'security method', 140 'bootstrap protocol', and the 'communications channel'. 142 The phases are provisioning phase and bootstrapping phase. In the 143 provisioning phase, statically configured parameters (e.g., 144 certificates) needed for the bootstrapping phase is provisioned. In 145 the bootstrapping phase, dynamically configured information is set up 146 using the statically configured information provided in the 147 provisioning phase. 149 Two nodes communicate through some channel. For our purposes this is 150 split into the 'control channel' and 'data channel'. The control 151 channel is used for the bootstrap protocol, and the data channel is 152 used during normal network operation. A node may support multiple 153 control or data channels. When the control and data channels are the 154 same, the bootstrapping is done In Band (IB). When the control and 155 data channels are different, the bootstrapping is performed Out Of 156 Band (OOB). An 802.15.4 network for instance would use an 802.15.4 157 control channel for IB bootstrapping, but a control channel of 158 perhaps IrDA or USB for OOB bootstrapping. 160 The 'bootstrap profile', i.e. statically configured parameters during 161 the provisioning phase, defines what information should be exchanged 162 during the process. A single node may run the protocol multiple 163 times with different profiles. If the user wishes to associate a new 164 lightswitch, the protocol is first run with the '802.15.4 Wireless 165 Profile', through which it learns the channel and PAN-ID. The node 166 then runs a 'Security Exchange Profile' to learn the needed 167 encryption keys. Finally it runs a 'Lightswitch Association Profile' 168 through which it learns which light to associate with. 170 An example of the 'bootstrap profile' attribute is the 171 'administrative domain name'. 'Bootstrap profiles' are required to 172 be modified when the corresponding administrative domains are 173 changed, a.k.a. recommissioning. In recommissioning, the domains are 174 administratively repartitioned and nodes are therefore 175 recommissioned. 177 The 'security method' defines supported security methods for 178 bootstrapping. The supported security methods will depend on the 179 control channel and bootstrap profile. In one node if the control 180 channel is secure, then a simple clear-text security method is 181 supported. For example when a physical connection between two nodes 182 is used, the control channel is considered secure. However when the 183 control channel is not secure, this clear-text security method is not 184 supported. The 'bootstrap profile' additionally defines allowed 185 security methods. Higher security nodes may outlaw ever performing a 186 clear-text exchange, even if the control channel is deemed secure. 188 The 'bootstrap protocol' defines the actual messages exchanged during 189 bootstrapping. The messages are used to transfer between nodes data, 190 node information, and network state. The selected security method 191 runs on top of the control channel, such as EAP-GPSK etc. 193 3.2. Architecture 195 Security bootstrapping architecture is structured in a hierarchy of 196 nodes going from the least resource constraint to the most resource 197 constraint. At the top there is a root node. The root node is 198 called Coordinator or Trust Center in Zigbee and 6LowPAN Border 199 Router (6LBR) in 6LoWPAN ND. 201 At the next level there are interior Routers. Routers are able to 202 run a routing protocol between other routers and the root. Routers 203 are called 6LowPAN Routers (6BR) in 6LoWPAN ND. 205 At the lowest level there are the nodes. The nodes do not run a 206 routing protocol. They can connect to the nearest router over a 207 single radio link. The nodes are called End Devices in Zigbee and 208 hosts in 6LoWPAN ND. 210 Routers first join the network as a node and go through security 211 bootstrapping operations in order to create a Master Session Key 212 (MSK). Next, routers execute routing protocol, e.g. [RFC6550] 213 specific steps to create session keys with their neighbors and to 214 establish upstream and downstream next hop parents. 216 At each node hierarachy level described above, there are lower-layer 217 and higher-layer protocols to bootstrap their ciphering keys, where 218 the lower-layer refers to layers below IP layer including IEEE 219 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer 220 refers to IP layer and the above. In general, required bootstrapping 221 procedures depend on the bootstrapping protocols to use. 223 4. Bootstrap Security Method 225 The bootstrap security method defines allowable security methods. A 226 node may choose to support or use a subset of these methods. This is 227 NOT the security architecture used for the application, but only the 228 security used during bootstrapping. Typically some high-security 229 method is used to generate a shared secret, which then switches to 230 simplier symmetric encryption to secure the actual bootstrapping 231 channel. The techniques negotiated should take advantage of hardware 232 resources available, such as hardware encryption accelerators on an 233 end node. 235 4.1. None 237 This is the simplist security method. No encryption or 238 authentication is provided, messages are exchanged completely in 239 clear-text. It is assumed some other layer provides security, such 240 as a physical connection between devices. 242 4.2. Asymmetric with User Authentication, Followed by Symmetric 244 A Diffie-Hellman style key exchange is used to generate a shared 245 secret. The authentication will be provided by the user, by 246 confirming cryptographic signatures between two devices. With the 247 shared secret generated through the DH, some symmetric encryption is 248 used to secure the actual bootstrapping channel. 250 4.3. Asymmetric with Certificate Authority, Followed by Symmetric 252 Public key exchanges are used (aka: DH again), but with a Certificate 253 Authority. Once a shared secret exists, symmetric encryption is used 254 to secure the actual bootstrapping channel. 256 4.4. Cryptographically Generated Address Based Address Ownership 257 Verification 259 A node may generate the global unique address using different 260 techniques other than the stateless address autoconfiguration. For 261 example, Cryptographically Generated Addresses (CGA) [RFC3972] is a 262 type of global unique address that can be used to verify the address 263 ownership. When the node uses CGA, it MUST execute SeND protocol 264 [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol 265 [I-D.ietf-6lowpan-nd] must be executed between the node and the edge 266 router. 268 5. Secure Bootstrapping System Level Objectives 270 Authentication/ reauthentication: nodes joining the network MUST at 271 the first place authenticate to the trust center. In order to 272 achieve secure multi-hop routing, the node MUST authenticate to its 273 upstream and downstream neighbors. A bootstrapping solution MUST 274 support re-authentication of resource-constrained devices and re- 275 keying of dynamically generated keys. 277 Data Confidentiality: the data communication between two endpoints 278 MAY be encrypted using the derived key, avoiding being eavesdropped 279 by a non-trusted third part. 281 Data Integrity: the data communication between two endpoints MUST NOT 282 be altered by some intermediate nodes. The nodes should be able to 283 detect the non-integral data. 285 Keys and key freshness: the keys used for data communication MUST 286 have a lifetime, in order to keep their freshness. A bootstrapping 287 solution MUST support both symmetric and asymmetric key 288 authentication. If distribution of a key to be used for a resource- 289 constrained device is required, a bootstrapping solution MUST support 290 secure key distribution to prevent the key from eavesdropping, 291 alternation and replay attacks. 293 Multi domain support: A bootstrapping solution MUST be able to allow 294 resource-constrained devices that may be subscribed to different 295 administrative domains to be connected to the same access network at 296 the same time. 298 Multi domain support: A bootstrapping solution MUST be able to allow 299 resource-constrained devices to be recommissioned. Recommissioning a 300 device is defined to be (1) an resource-constrained device is 301 administratively switched to a different domain, or (2) acting a new 302 role with a different function set, or (3) both administrative domain 303 and function set are modified. 305 Identities: A bootstrapping solution MUST be able to allow a 306 resource-constrained device to use various types of identities used 307 for authentication, including device identities, user identities or 308 combinations of different types of identities. Also a bootstrapping 309 solution MUST be able to allow a resource-constrained device to 310 change its identities used for authentication over time. 312 Authentication infrastructure: A bootstrapping solution MUST be able 313 to operate with or without an authentication infrastructure. 315 6. Security Considerations 317 When security bootstrapping resource constraint nodes is undertaken, 318 several attacks are possible and security bootstrapping methods 319 described in this document do not protect the nodes against such 320 attacks. These attacks are similar to the ones described in 321 [RFC3971] and mainly stem from unsecured link layer. Link layer must 322 be secured on each node before the node can begin security 323 bootstrapping. 325 If a bootstrapping protocol does not rely on a pre-shared key for 326 peer authentication, it must rely on an online or offline third-party 327 (e.g., an authentication server, a key distribution center in 328 Kerberos, a certification authority in PKI, a private key generator 329 in ID-based cryptography and so on) to prevent man-in-the-middle 330 attacks during peer authentication. Depending on use cases, a 331 resource-constrained device may not always have access to an online 332 third-party for peer authentication. 334 Depending on use cases, a bootstrapping protocol may deal with 335 authorization separately from authentication in terms of timing and 336 signaling path. For example, two resource-constrained devices A and 337 B may perform mutual authentication using authentication credentials 338 provided by an offline third-party X whereas resource-constrained 339 device A obtains authorization for running a particular application 340 with resource-constrained device B from an online third-party Y 341 before or after the authentication. In some use cases, 342 authentication and authorization are tightly coupled, e.g., 343 successful authentication also means successful authorization. A 344 bootstrapping protocol supports various types of authentication and 345 authorization or different bootstrapping protocols may be used for 346 different types of authentication and authorization. 348 If authorization information includes cryptographic keys, a special 349 care must be taken for dealing with the keys, e.g., guidelines for 350 AAA-based key management are described in [RFC4962]. A 351 recommissioning use case may require revocation and re-installation 352 of authentication credentials (i.e., a certificate or a shared secret 353 and identity information, etc.) to a large number of resource- 354 constrained devices that are already deployed. Re-installation of 355 authentication credentials must be as secure as the initial 356 installation regardless of whether the re-installation is done 357 manually or automatically. 359 If resource-constrained devices use a multicast group key for peer 360 authentication or message authentication or encryption, the group key 361 must be securely distributed to the current members of the group for 362 both initial key distribution and key update. Protocols designed for 363 group key management such as GSAKMP [RFC4535], GDOI [RFC3547] and 364 MIKEY [RFC3830] may be used for group key distribution. 365 Alternatively, key wrap attributes for securely encapsulating group 366 key may be defined in network access authentication protocols such as 367 PANA [RFC5191] and EAP-TTLSv0 [RFC5281]. Those protocols use an end- 368 to-end, point-to-point communication channel with a pair-wise 369 security association between a key distribution center and each key 370 recipient. Further considerations may be needed for more efficient 371 group key management to support a large number of resource- 372 constrained devices. 374 7. EAP, PANA, HIP-DEX and 802.1X 376 7.1. EAP Authentication Framework 378 EAP is an authentication protocol that supports a number of 379 authentication algorithms called EAP methods [RFC5247]. EAP messages 380 can be transported in different layers: using 802.1X, EAP messages 381 are carried in Layer 2 and using PANA in IP or Layer 3 between EAP 382 peer and the authenticator. EAP messages between the authenticator 383 and authentication server are carried using AAA protocols (RADIUS or 384 Diameter). The associated AAA server address of each resource- 385 constrained device is assigned by the domain administrator. In the 386 recommissioning case, another AAA server is reassigned to devices by 387 the domain administrator if the device is switched to another domain. 389 At the end of a successful EAP method execution a master session key 390 (MSK) is generated at both the EAP peer and EAP server. 391 Authenticator receives MSK from EAP server at the end of EAP method 392 execution using key transport. MSK is used in deriving a session key 393 between the node and the authenticator using a protocol called secure 394 association protocol (SAP). Derivation of the session key terminates 395 bootstrapping of a node. 397 Additional keying material derived between EAP client and server that 398 is exported by the EAP method is called Extended Master Session Key 399 (EMSK). EMSK is not used in session key derivation but it could be 400 used for the needs of other applications in higher layer protocols. 402 In the architecture introduced in Section 3.2 the node or router is 403 the peer and the root is the authenticator. When the supplicant and 404 authenticator are one hop away the authenticator can be reached 405 directly. However, this is rarely the case. In other cases the 406 authenticator authenticates neighboring supplicants first. The 407 router nodes that are authenticated become relay authenticators in 408 the next phase and they relay authentication messages from the 409 supplicants to the authenticator and vice versa. This continues 410 until all nodes are authenticated. 412 EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request 413 messages sent by the server and EAP-Response messages sent by the 414 peer. At the end, the server indicates the status of authentication, 415 usually by EAP-Success message which also carries the MSK. The first 416 EAP-Request/Response pair is used for the server to request the 417 identity and the peer to provide it. In the other pairs of EAP 418 exchanges EAP method is executed. 420 Several EAP methods have been standardized each for different 421 purposes. To authenticate devices with certificates, EAP Transport 422 Layer Security (TLS) v1.2 specified in [RFC5216] which supports 423 certificate-based mutual authentication is used. 425 Zigbee Alliance's Smart Energy Profile 2.0 Application Protocol 426 Specification [SE2.0] mandates each device to be factory programmed 427 with a certificate. The certificate is bound to a unique network ID, 428 e.g. the device's MAC address or EUI-64 address. During EAP-Identity 429 exchange the EAP peer provides its EUI-64 address as an identity to 430 EAP server. This enables the server to validate the device 431 certificate. 433 There are three bootstrapping scenarios using EAP. 435 1. Use of EAP for bootstrapping link-layer security. 437 In this case, EAP is used for network access authentication to 438 bootstrap link-layer ciphering. Security for higher-layer (i.e., 439 IP layer and above) protocols is bootstrapped from an IB or OOB 440 mechanism other than EAP. 442 2. Use of EAP for bootstrapping higher-layer security. 444 In this case, EAP is used as an OOB mechanism for higher-layer 445 authentication to bootstrap ciphering keys for one or more 446 higher-layer protocols independently of network access 447 authentication. When bootstrapping Constrained Application 448 Protocol (CoAP) security with DTLS protection, a PSK (Pre-Shared 449 Key) credential in the combined usage of DTLS (Datagram Transport 450 Layer Security) [RFC4347] and PSK mode of TLS [RFC4279] is 451 derived from EAP key material and DTLS ciphering keys are 452 generated as a result of a successful DTLS handshake. Similarly, 453 when bootstrapping CoAP security with IPsec ESP protection, a PSK 454 credential of IKEv2 [RFC5996] is derived from EAP key material 455 and IPsec ESP ciphering keys are generated as a result of a 456 successful IKEv2 handshake. 458 The ability to bootstrap multiple higher-layer protocols from a 459 single execution of PANA authentication is important to save the 460 computational resources for resource-constrained devices 461 especially where public-key based authentication is used. 463 3. Use of EAP for bootstrapping both link-layer and higher-layer 464 security. 466 This case is the combination of the other two cases, and the most 467 optimized way for bootstrapping resource-constrained devices. 468 This case is only applicable where both the network access 469 authentication and the higher-layer authentication use the same 470 authentication server with the same authentication credentials. 472 The second and third scenarios are generally referred to as Single 473 Sign-On in Section 4.2.2.2 of [NISTIR7628VOL1], where the root keys 474 for higher-layer protocols can be derived from EAP EMSK (Extended 475 Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295]. 477 7.2. PANA 479 PANA (Protocol for carrying Authentication for Network Access) 480 [RFC5191] defines an EAP transport over UDP where a PANA Client (PaC) 481 is an EAP peer and a PANA Authentication Agent (PAA) is an EAP 482 authenticator. 484 PANA can achieve the authentication, key freshness and data 485 confidentiality objectives of security bootstrapping. 487 Multi domain operation is intrinsically supported due to the use of 488 EAP and AAA. 490 Even though PANA architecture consisting of PaC, PAA and AAA Server 491 is generic enough to be used in security bootstrapping, the 492 architecture introduced in Section 3.2 requires a new element called 493 PANA Relay Element (PRE). PRE is needed to enable PANA messaging 494 between a PaC and PAA because the two nodes cannot reach each other 495 by means of regular IP routing since only a link-local IPv6 address 496 can be used by PaC prior to the completion of a succesful 497 authentication. 499 PRE which is one hop away from PaC receives PANA messages and relays 500 the message contents (payload) by encapsulating it in a message 501 parameter called Attribute Value Pair (AVP). PRE also needs to send 502 header contents such as PaC's IP address and UDP port number in a 503 different AVP. PRE has IP routing established with PAA which could 504 be several hops away. PAA sends its reply messages in which the 505 payload is encapsulated in an AVP. It also adds the AVP containing 506 PaC's IP address and UDP port number. PRE creates a link local PDU 507 using these AVPs and sends it to PaC [I-D.ohba-pana-relay]. 509 The requirements for the use of PANA as a bootsrapping protocol can 510 be stated as follows: 512 o A new entity called PANA Relay Element may be added to the PANA 513 architecture. Behaviour of PANA Relay Element needs to be 514 defined. New AVPs needed for PANA Relay Element operation for 515 properly relaying messages from the client to the authenticator 516 and vice versa are required to be specified. 518 o An extension to PANA to securely distribute keys from the PANA 519 Authentication Agent to the PANA Client using AES Key Wrap with 520 Padding algorithm needs to be defined. This is needed in order to 521 use PANA for multicast group key distribution. 523 7.3. HIP-DEX 525 [RFC4423] introduces the Host Identity Protocol (HIP) where the Host 526 Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit 527 length Host Identity Tag (HIT) is derived from the HI (hashed) and 528 functions as an IPv6 address (/128 prefix) for applications. A four- 529 packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX) 530 establishes a security association (SA, similar to IKE), indexed by 531 the HITs, but independent of the IP address. So HIP can be 532 considered as a shim layer between the transport(TCP/UDP) and IP, 533 providing authentication, data confidentiality, mobility in one 534 basket. 536 As with IKE, HIP is typically used as a Key Management Protocol (KMP) 537 for ESP. However, HIP is independent of IP and ESP and can be used 538 for a KMP for any secure communication protocol at any level. Thus 539 HIP can provide keying material for the MAC, IP, and Transport 540 layers. HIP can be run directly over the MAC in an Ethernet Frame or 541 within an Information Element in a MAC control frame. HIP can be run 542 over UDP, traversing firewalls, and push keys over to Transport 543 security protocols like SRTP or (D)TLS. Further, HIP could start on 544 the MAC, then be enveloped over UDP after the first link. 546 The HIP-BEX involves many crypto primitives that are difficult to run 547 on constrained nodes. HIP Diet Exchange (HIP-DEX) 548 [I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight. 549 Basically, HIP-DEX a variant of the HIP-BEX specifically designed to 550 use as few crypto primitives as possible yet still provide the same 551 class of security features as HIP-BEX. 553 HIP-DEX can be used for mutual authentication between two endpoints. 555 After mutual authentication, the two endpints establish a shared 556 secret, which is fresh and fed into the encryption algorithm for data 557 confidentiality. So HIP-DEX can achieve the authentication, key 558 freshness and data confidentiality objectives of security 559 bootstrapping. 561 When a node wants to authenticate to the network using HIP and Diet- 562 HIP, it should be able to complete the HIP-BEX or HIP-DEX with the 563 trust anchor or some delegate. In HIP, it does not matter how many 564 domains, and nodes can authenticate each other as long as they have 565 the secret. 567 In the architecture introduced in Section 3.2 the node and router 568 could be the HIP end-points. Or the router could be a HIP Rendezvous 569 Server, with the node registering to the rendezvous server (RVS) 570 [RFC5204] to be reachable by other nodes. Typically the initial 571 interaction will have the node be the HIP DEX Initiator with the 572 router being the Responder. Using the RVS function on a Router any 573 node could be the Initiator with any other Responder node. As long 574 as there is IP connectivity between the Initiator and Responder, they 575 can be multiple hops away from each other. Alternatively if the 576 first hop from the Initiator has knowledge of the IP address of the 577 Responder, it can act as a MAC/IP gateway for HIP. 579 An important requirement for the HIP-DEX to work in the architecture, 580 the initiator should be able to get the IP address of the responder 581 or have a gateway function as a forwarder. The IP address can be 582 obtained from a 3rd party source like DNS of Distributed Hash Table 583 (DHT), from local configuration, or from an RVS. 585 7.4. 802.1X 587 IEEE 802.1X defines how EAP packets can be transported over in Layer 588 2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into 589 EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and 590 the authenticator. EAPOL can also be used in 802.11 wireless links. 592 To enable IEEE 802.15.4 devices to use EAP authentication, EAP 593 packets encapsulated in EAPOL frames can be carried as payload in 594 802.15.4 data frames [802.15.4]. EAPOL is well defined and widely 595 used and it lends itself to be easily carried in 802.15.4 data 596 frames. For this, Frame Type subfield of the Frame Control Field of 597 IEEE 802.15.4 MAC header needs to be set to a special value to 598 indicate the type of the payload, i.e. 802.1X encapsulated EAP 599 packets. EAPOL packets are encoded following common EAPOL PDU 600 structure defined in [802.1x] into the data payload field of 802.15.4 601 data frames. 603 Authentication proceeds as follows: authenticator authenticates the 604 supplicants that are on the next hop first. This enables a secure 605 link between the authenticator and these first-hop nodes. The 606 architecture introduced in Section 3.2 requires a new entity called 607 Relay Authenticator. First-hop nodes or router become Relay 608 Authenticators in the next phase of authentication. Relay 609 Authenticators tunnel EAPOL frames to the authenticator in the secure 610 link established. This way all the supplicants are gradually 611 authenticated. 613 After the keys are established from a successful EAP method (such as 614 PSK mode of TLS), the node runs neighbor discovery protocol to get an 615 IPv6 address assigned [I-D.ietf-6lowpan-nd]. Data transfer can be 616 secured using DTLS or IPSec. Keys derived from EAP TLS are used in 617 either generating DTLS ciphering keys after a successful DTLS 618 handshake or IPSec ESP ciphering keys after a successful IKEv2 619 handshake. 621 802.1X can achieve the authentication, key freshness and data 622 confidentiality objectives of security bootstrapping. 624 Multi domain operation is intrinsically supported due to the use of 625 EAP and AAA. In order to support a device recommissioning case 626 whereby the device's administrative domain is modified, after a new 627 AAA server address assigned and a successful 802.1X method execution, 628 the old set of device 'name and password' MUST be overwritten into 629 the device by a new set of 'name and password' that are assigned by 630 the domain administrator. The device MUST be rebooted to execute EAP 631 method again for authentication and a new master session key MUST be 632 generated. 634 It should be noted that currently 802.15.4 does not allow 635 multiplexing multiple protocols on the same link like ethernet does. 636 However this might change in the future. 638 The requirements for the use of 802.1X defined EAPOL as a 639 bootsrapping protocol can be stated as follows: 641 o A special value in the Frame Type subfield of the Frame Control 642 Field of IEEE 802.15.4 MAC header to indicate the type of the 643 payload, 645 o Link Layer Multicast Group addresses for 802.15.4 corresponding to 646 EAPOL Group Address Assignments defined in Table 11.1 of [802.1x], 647 especially to be used in EAPOL-Start packet. 649 o Which MAC frames of beacon, data, acknowledgment and MAC command 650 as defined in [802.15.4] with what security levels are mapped to 651 controlled port, which MAC frames with what security levels are 652 mapped to uncontrolled port and which MAC frames are never mapped 653 to any of controlled/uncontrolled port (i.e., the payload of those 654 frames are used by the MAC-layer ieself and never used by upper 655 layers). 657 o A new entity called Relay Authenticator may be added to the 802.1x 658 architecture. Behaviour of Relay Authenticator needs to be 659 defined. 661 8. IANA Considerations 663 This memo includes no request to IANA. 665 9. Acknowledgements 667 TBD. 669 10. References 671 10.1. Normative References 673 [802.15.4] 674 IEEE Std 802.15.4-2006, "Wireless Medium Access Control 675 (MAC) and Physical Layer (PHY) Specifications for Low Rate 676 Wireless Personal Area Networks (WPANs)", September 2006. 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, March 1997. 681 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 682 Levkowetz, "Extensible Authentication Protocol (EAP)", 683 RFC 3748, June 2004. 685 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 686 over Low-Power Wireless Personal Area Networks (6LoWPANs): 687 Overview, Assumptions, Problem Statement, and Goals", 688 RFC 4919, August 2007. 690 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 691 Yegin, "Protocol for Carrying Authentication for Network 692 Access (PANA)", RFC 5191, May 2008. 694 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 695 Authentication Protocol", RFC 5216, March 2008. 697 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 698 "Routing Requirements for Urban Low-Power and Lossy 699 Networks", RFC 5548, May 2009. 701 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 702 "Industrial Routing Requirements in Low-Power and Lossy 703 Networks", RFC 5673, October 2009. 705 10.2. Informative References 707 [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network 708 Access Control", February 2010. 710 [I-D.garcia-core-security] 711 Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and 712 R. Struik, "Security Considerations in the IP-based 713 Internet of Things", draft-garcia-core-security-04 (work 714 in progress), March 2012. 716 [I-D.ietf-6lowpan-nd] 717 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 718 Discovery Optimization for Low Power and Lossy Networks 719 (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), 720 August 2012. 722 [I-D.moskowitz-hip-rg-dex] 723 Moskowitz, R., "HIP Diet EXchange (DEX)", 724 draft-moskowitz-hip-rg-dex-06 (work in progress), 725 May 2012. 727 [I-D.ohba-pana-relay] 728 Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 729 Yegin, "Protocol for Carrying Authentication for Network 730 Access (PANA) Relay Element", draft-ohba-pana-relay-03 731 (work in progress), February 2011. 733 [NISTIR7628VOL1] 734 The Smart Grid Interoperability Panel - Cyber Security 735 Working Group, "Guidelines for Smart Grid Cyber Security: 736 Vol. 1, Smart Grid Cyber Security Strategy, Architecture, 737 and High-Level Requirements", NISTIR 7628, vol. 1, 2010. 739 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 740 Group Domain of Interpretation", RFC 3547, July 2003. 742 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 743 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 744 August 2004. 746 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 747 Neighbor Discovery (SEND)", RFC 3971, March 2005. 749 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 750 RFC 3972, March 2005. 752 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 753 for Transport Layer Security (TLS)", RFC 4279, 754 December 2005. 756 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 757 Security", RFC 4347, April 2006. 759 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 760 (HIP) Architecture", RFC 4423, May 2006. 762 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 763 "GSAKMP: Group Secure Association Key Management 764 Protocol", RFC 4535, June 2006. 766 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 767 Authorization, and Accounting (AAA) Key Management", 768 BCP 132, RFC 4962, July 2007. 770 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 771 Rendezvous Extension", RFC 5204, April 2008. 773 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 774 Authentication Protocol (EAP) Key Management Framework", 775 RFC 5247, August 2008. 777 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 778 Protocol Tunneled Transport Layer Security Authenticated 779 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 781 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 782 "Specification for the Derivation of Root Keys from an 783 Extended Master Session Key (EMSK)", RFC 5295, 784 August 2008. 786 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 787 "Internet Key Exchange Protocol Version 2 (IKEv2)", 788 RFC 5996, September 2010. 790 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 791 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 792 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 793 Lossy Networks", RFC 6550, March 2012. 795 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 796 sensor networks", IEEE Wireless Communications, vol. 11, 797 no. 6, pp. 54-61, December 2004. 799 [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical 800 Requirements Document", April 2010. 802 Authors' Addresses 804 Behcet Sarikaya 805 Huawei USA 806 5340 Legacy Dr. 807 Plano, TX 75024 809 Email: sarikaya@ieee.org 811 Yoshihiro Ohba 812 Toshiba 813 Tokyo, Japan 815 Email: yoshihiro.ohba@toshiba.co.jp 817 Robert Moskowitz 818 Verizon Business Systems 819 15210 Sutherland 820 Oak Park, MI 48237 822 Email: rgm@labs.htt-consult.com 824 Zhen Cao 825 China Mobile 826 Beijing, China 828 Email: caozhen@chinamobile.com 830 Robert Cragie 831 Pacific Gas and Electric 832 89 Greenfield Crescent 833 Wakefield, UK WF4 4WA 835 Email: robert.cragie@gridmerge.com