Core B. Sarikaya Internet-Draft Huawei USA Intended status: Informational Y. Ohba Expires: May 3, 2012 Toshiba R. Moskowitz Verizon Business Systems Z. Cao China Mobile R. Cragie Pacific Gas and Electric October 31, 2011 Security Bootstrapping of Resource-Constrained Devices draft-sarikaya-core-sbootstrapping-03 Abstract This document describes how to initially configure the network of resource constrained nodes securely, a.k.a., security bootstrapping. Bootstrapping architecture, communication channel and bootstrap security methods are described. System level objectives for security bootstrapping are stated followed by the protocols that can be used. Requirements on these protocols to be used as security bootstrapping protocols are identified. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Sarikaya, et al. Expires May 3, 2012 [Page 1] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Sarikaya, et al. Expires May 3, 2012 [Page 2] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5 1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 6 2.1. Areas of Boostrapping . . . . . . . . . . . . . . . . . . 6 2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 3. Communications Channel . . . . . . . . . . . . . . . . . . . . 8 3.1. Supported Communication Channels . . . . . . . . . . . . . 8 4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 9 4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Asymmetric with User Authentication, Followed by Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Asymmetric with Certificate Authority, Followed by Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Cryptographically Generated Address Based Address Ownership Verification . . . . . . . . . . . . . . . . . . 9 5. Bootstrapping Protocols . . . . . . . . . . . . . . . . . . . 10 5.1. System Level Objectives . . . . . . . . . . . . . . . . . 10 5.2. EAP Authentication Framework . . . . . . . . . . . . . . . 11 5.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Examples of Node Configuration . . . . . . . . . . . 21 A.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 22 A.1.1. Initial Meter Installation . . . . . . . . . . . . . . 22 A.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 22 A.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 22 A.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 22 A.2.2. Adding a TV to a network with a DVD player and remote . . . . . . . . . . . . . . . . . . . . . . . . 22 A.2.3. Providing GPS Location Data . . . . . . . . . . . . . 22 A.3. Commercial Building Automation . . . . . . . . . . . . . . 22 A.3.1. Light Installation . . . . . . . . . . . . . . . . . . 23 Appendix B. Example Exchanges . . . . . . . . . . . . . . . . . . 23 B.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 23 B.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 23 B.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 23 B.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 23 B.5. Consumer: Adding a TV to a network with a DVD player Sarikaya, et al. Expires May 3, 2012 [Page 3] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 and remote . . . . . . . . . . . . . . . . . . . . . . . . 24 B.6. Consumer: Providing GPS Location Data . . . . . . . . . . 26 B.7. Commercial: Building Automation . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Sarikaya, et al. Expires May 3, 2012 [Page 4] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 1. Introduction Familiarity with constrained network types is assumed here. Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups (WGs) would be a useful reference for the reader. In particular RFC 4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] and RFC 5673 [RFC5673] from ROLL, CoAP [I-D.ietf-core-coap] from CoRE, and a paper by Romer and Mattern [ROMER04]. Familiarity with application specific examples such as Zigbee or Smart Energy groups is assumed. A summary of those will be presented, as far as network requirements are concerned. The general network requirements will be further concentrated into requirements surrounding only the bootstrapping issues. A number of solutions which are currently in use will be presented. Requirements on each solution will be stated to enable their use as a security bootstrapping protocol. 1.1. What is Bootstrapping? Node configuration is known as bootstrapping in this document. Bootstrapping is any processing required before the network can operate. Typically this will require a number of settings to be transferred between nodes at all layers. This could include anything from link-layer information (i.e., wireless channels, link-layer encryption keys) to application-layer information (i.e., network names, application encryption keys). Bootstrapping is complete when settings have been securely transferred prior to normal operation in the network. 1.2. Why IETF? The bootstrapping problem is not specific to any MAC or PHY. This problem exists across any two nodes which have no previous knowledge of each other. In particular, this problem is complicated when the nodes are resource-constrained and may not have an advanced user interface. The IETF is instrumental in defining standards which will be used by The Internet of Things. Ensuring these standards can be used across nodes and networks requires some form of bootstrapping which any node can use. Existing standards will be used as much as possible in this document. The method proposed here should work across many different underlying layers. It could be used to allow two nodes on the same physical network to join at the physical layer, or allow two nodes on an incompatible physical network to join at the IPv6 layer. Sarikaya, et al. Expires May 3, 2012 [Page 5] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 2. Bootstrapping Architecture 2.1. Areas of Boostrapping In order to provide a flexible architecture, the bootstrapping method is split into five distinct areas and two distinct phases. The five areas are a 'user interface', 'bootstrap profile', 'security method', 'bootstrap protocol', and the 'communications channel'. The phases are provisioning phase and bootstrapping phase. In the provisioning phase, statically configured parameters (e.g., certificates) needed for the bootstrapping phase is provisioned. In the bootstrapping phase, dynamically configured information is set up using the statically configured information provided in the provisioning phase. The user interface provides both user input and user output. Simple nodes may only have a push-button and LED, more complex nodes may have a graphical display and keyboard. The user interface (which could be implemented as network management software graphical user interface running at the remote end) provides interaction between the user and bootstrapping methods. The user interface would be used during bootstrapping as an OOB channel. It may also be used to specify bootstrapping policies. The user interface provides the interaction between the user and the bootstrap protocol. The user interface will vary depending on the capabilities of the node. Examples might include a push-button and LED on simple nodes, to full-blown graphical user interfaces. Note that a 'bootstrapping tool' used to initially deploy a network is just a special user interface. This allows a very uniform protocol in deployment and use of networks. User interface is out-of-scope and will not be further discussed. Two nodes communicate through some channel. For our purposes this is split into the 'control channel' and 'data channel'. The control channel is used for the bootstrap protocol, and the data channel is used during normal network operation. A node may support multiple control or data channels. When the control and data channels are the same, the bootstrapping is done In Band (IB). When the control and data channels are different, the bootstrapping is performed Out Of Band (OOB). An 802.15.4 network for instance would use an 802.15.4 control channel for IB bootstrapping, but a control channel of perhaps IrDA or USB for OOB bootstrapping. The 'bootstrap profile', i.e. statically configured parameters during the provisioning phase, defines what information should be exchanged Sarikaya, et al. Expires May 3, 2012 [Page 6] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 during the process. A single node may run the protocol multiple times with different profiles. If the user wishes to associate a new lightswitch, the protocol is first run with the '802.15.4 Wireless Profile', through which it learns the channel and PAN-ID. The node then runs a 'Security Exchange Profile' to learn the needed encryption keys. Finally it runs a 'Lightswitch Association Profile' through which it learns which light to associate with. An example of the 'bootstrap profile' attribute is the 'administrative domain name'. 'Bootstrap profiles' are required to be modified when the corresponding administrative domains are changed, a.k.a. recommissioning. In recommissioning, the domains are administratively repartitioned and nodes are therefore recommissioned. The 'security method' defines supported security methods for bootstrapping. The supported security methods will depend on the control channel and bootstrap profile. In one node if the control channel is secure, then a simple clear-text security method is supported. For example when a physical connection between two nodes is used, the control channel is considered secure. However when the control channel is not secure, this clear-text security method is not supported. The 'bootstrap profile' additionally defines allowed security methods. Higher security nodes may outlaw ever performing a clear-text exchange, even if the control channel is deemed secure. The 'bootstrap protocol' defines the actual messages exchanged during bootstrapping. The messages are used to transfer between nodes data, node information, and network state. The selected security method runs on top of the control channel, such as EAP-GPSK etc. 2.2. Architecture Security bootstrapping architecture is structured in a hierarchy of nodes going from the least resource constraint to the most resource constraint. At the top there is a root node. The root node is called Coordinator or Trust Center in Zigbee and 6LowPAN Border Router (6LBR) in 6LoWPAN ND. At the next level there are interior Routers. Routers are able to run a routing protocol between other routers and the root. Routers are called 6LowPAN Routers (6BR) in 6LoWPAN ND. At the lowest level there are the nodes. The nodes do not run a routing protocol. They can connect to the nearest router over a single radio link. The nodes are called End Devices in Zigbee and hosts in in 6LoWPAN ND. Sarikaya, et al. Expires May 3, 2012 [Page 7] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 Routers first join the network as a node and go through security bootstrapping operations in order to create a Master Session Key (MSK). Next, routers execute routing protocol, e.g. [I-D.ietf-roll-rpl] specific steps to create session keys with their neighbors and to establish upstream and downstream next hop parents. At each node hierarachy level described above, there are lower-layer and higher-layer protocols to bootstrap their ciphering keys, where the lower-layer refers to layers below IP layer including IEEE 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer refers to IP layer and the above. In general, required bootstrapping procedures depend on the bootstrapping protocols to use. Section Section 5 describes the bootstrapping procedures where EAP (Extensible Authentication Protocol) [RFC3748] and other protocols are used as the bootstrapping protocols. 3. Communications Channel The communications channel is the method used between two nodes to communicate. There are two main communication channels: the 'control' and 'data' channels. The control channel is used during bootstrapping, and the data channel is used during network operation. 3.1. Supported Communication Channels There is no limit on what communications channels are supported. The following gives an example of several supported channels: o IEEE 802.15.4 o Power-Line Communications o IrDA o RFID o Some simple physical link o Cellular o Ethernet o IPv6 o Wi-Fi Depending on the node's function, it may use different channels as Sarikaya, et al. Expires May 3, 2012 [Page 8] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 the data or control channel. Nodes may have multiple data and/or control channels as wel. 4. Bootstrap Security Method The bootstrap security method defines allowable security methods. A node may choose to support or use a subset of these methods. This is NOT the security architecture used for the application, but only the security used during bootstrapping. Typically some high-security method is used to generate a shared secret, which then switches to simplier symmetric encryption to secure the actual bootstrapping channel. The techniques negotiated should take advantage of hardware resources available, such as hardware encryption accelerators on an end node. 4.1. None This is the simplist security method. No encryption or authentication is provided, messages are exchanged completely in clear-text. It is assumed some other layer provides security, such as a physical connection between devices. 4.2. Asymmetric with User Authentication, Followed by Symmetric A Diffie-Hellman style key exchange is used to generate a shared secret. The authentication will be provided by the user, by confirming cryptographic signatures between two devices. With the shared secret generated through the DH, some symmetric encryption is used to secure the actual bootstrapping channel. 4.3. Asymmetric with Certificate Authority, Followed by Symmetric Public key exchanges are used (aka: DH again), but with a Certificate Authority. Once a shared secret exists, symmetric encryption is used to secure the actual bootstrapping channel. 4.4. Cryptographically Generated Address Based Address Ownership Verification A node may generate the global unique address using different techniques other than the stateless address autoconfiguration. For example, Cryptographically Generated Addresses (CGA) [RFC3972] is a type of global unique address that can be used to verify the address ownership. When the node uses CGA, it MUST execute SeND protocol [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol [I-D.ietf-6lowpan-nd] must be executed between the node and the edge router. Sarikaya, et al. Expires May 3, 2012 [Page 9] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 5. Bootstrapping Protocols In this section we first present system level objectives that security bootstrapping protocols are expected to achieve. Next, we present EAP authentication framework and then describe three different protocols. 5.1. System Level Objectives Authentication/ reauthentication: nodes joining the network MUST at the first place authenticate to the trust center. In order to achieve secure multi-hop routing, the node MUST authenticate to its upstream and downstream neighbors. A bootstrapping solution MUST support re-authentication of resource-constrained devices and re- keying of dynamically generated keys. Data Confidentiality: the data communication between two endpoints MAY be encrypted using the derived key, avoiding being eavesdropped by a non-trusted third part. Data Integrity: the data communication between two endpoints MUST NOT be altered by some intermediate nodes. The nodes should be able to detect the non-integral data. Keys and key freshness: the keys used for data communication MUST have a lifetime, in order to keep their freshness. A bootstrapping solution MUST support both symmetric and asymmetric key authentication. If distribution of a key to be used for a resource- constrained device is required, a bootstrapping solution MUST support secure key distribution to prevent the key from eavesdropping, alternation and replay attacks. Multi domain support: A bootstrapping solution MUST be able to allow resource-constrained devices that may be subscribed to different administrative domains to be connected to the same access network at the same time. Multi domain support: A bootstrapping solution MUST be able to allow resource-constrained devices to be recommissioned. Recommissioning a device is defined to be (1) an resource-constrained device is administratively switched to a different domain, or (2) acting a new role with a different function set, or (3) both administrative domain and function set are modified. Identities: A bootstrapping solution MUST be able to allow a resource-constrained device to use various types of identities used for authentication, including device identities, user identities or combinations of different types of identities. Also a bootstrapping Sarikaya, et al. Expires May 3, 2012 [Page 10] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 solution MUST be able to allow a resource-constrained device to change its identities used for authentication over time. Authentication infrastructure: A bootstrapping solution MUST be able to operate with or without an authentication infrastructure. 5.2. EAP Authentication Framework EAP is an authentication protocol that supports a number of authentication algorithms called EAP methods [RFC5247]. EAP messages can be transported in different layers: using 802.1X, EAP messages are carried in Layer 2 and using PANA in IP or Layer 3 between EAP peer and the authenticator. EAP messages between the authenticator and authentication server are carried using AAA protocols (RADIUS or Diameter). The associated AAA server address of each resource- constrained device is assigned by the domain administrator. In the recommissioning case, another AAA server is reassigned to devices by the domain administrator if the device is switched to another domain. At the end of a successful EAP method execution a master session key (MSK) is generated at both the EAP peer and EAP server. Authenticator receives MSK from EAP server at the end of EAP method execution using key transport. MSK is used in deriving a session key between the node and the authenticator using a protocol called secure association protocol (SAP). Derivation of the session key terminates bootstrapping of a node. Additional keying material derived between EAP client and server that is exported by the EAP method is called Extended Master Session Key (EMSK). EMSK is not used in session key derivation but it could be used for the needs of other applications in higher layer protocols. In the architecture introduced in Section 2.2 the node or router is the peer and the root is the authenticator. When the supplicant and authenticator are one hop away the authenticator can be reached directly. However, this is rarely the case. In other cases the authenticator authenticates neighboring supplicants first. The router nodes that are authenticated become relay authenticators in the next phase and they relay authentication messages from the supplicants to the authenticator and vice versa. This continues until all nodes are authenticated. EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request messages sent by the server and EAP-Response messages sent by the peer. At the end, the server indicates the status of authentication, usually by EAP-Success message which also carries the MSK. The first EAP-Request/Response pair is used for the server to request the identity and the peer to provide it. In the other pairs of EAP Sarikaya, et al. Expires May 3, 2012 [Page 11] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 exchanges EAP method is executed. Several EAP methods have been standardized each for different purposes. To authenticate devices with certificates, EAP Transport Layer Security (TLS) v1.2 specified in [RFC5216] which supports certificate-based mutual authentication is used. Zigbee Alliance's Smart Energy Profile 2.0 Application Protocol Specification [SE2.0] mandates each device to be factory programmed with a certificate. The certificate is bound to a unique network ID, e.g. the device's MAC address or EUI-64 address. During EAP-Identity exchange the EAP peer provides its EUI-64 address as an identity to EAP server. This enables the server to validate the device certificate. There are three bootstrapping scenarios using EAP. 1. Use of EAP for bootstrapping link-layer security. In this case, EAP is used for network access authentication to bootstrap link-layer ciphering. Security for higher-layer (i.e., IP layer and above) protocols is bootstrapped from an IB or OOB mechanism other than EAP. 2. Use of EAP for bootstrapping higher-layer security. In this case, EAP is used as an OOB mechanism for higher-layer authentication to bootstrap ciphering keys for one or more higher-layer protocols independently of network access authentication. When bootstrapping Constrained Application Protocol (CoAP) security with DTLS protection, a PSK (Pre-Shared Key) credential in the combined usage of DTLS (Datagram Transport Layer Security) [RFC4347] and PSK mode of TLS [RFC4279] is derived from EAP key material and DTLS ciphering keys are generated as a result of a successful DTLS handshake. Similarly, when bootstrapping CoAP security with IPsec ESP protection, a PSK credential of IKEv2 [RFC5996] is derived from EAP key material and IPsec ESP ciphering keys are generated as a result of a successful IKEv2 handshake. The ability to bootstrap multiple higher-layer protocols from a single execution of PANA authentication is important to save the computational resources for resource-constrained devices especially where public-key based authentication is used. 3. Use of EAP for bootstrapping both link-layer and higher-layer security. Sarikaya, et al. Expires May 3, 2012 [Page 12] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 This case is the combination of the other two cases, and the most optimized way for bootstrapping resource-constrained devices. This case is only applicable where both the network access authentication and the higher-layer authentication use the same authentication server with the same authentication credentials. The second and third scenarios are generally referred to as Single Sign-On in Section 4.2.2.2 of [NISTIR7628VOL1], where the root keys for higher-layer protocols can be derived from EAP EMSK (Extended Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295]. 5.3. PANA PANA (Protocol for carrying Authentication for Network Access) [RFC5191] defines an EAP transport over UDP where a PANA Client (PaC) is an EAP peer and a PANA Authentication Agent (PAA) is an EAP authenticator. PANA can achieve the authentication, key freshness and data confidentiality objectives of security bootstrapping. Multi domain operation is intrinsically supported due to the use of EAP and AAA. Even though PANA architecture consisting of PaC, PAA and AAA Server is generic enough to be used in security bootstrapping, the architecture introduced in Section 2.2 requires a new element called PANA Relay Element (PRE). PRE is needed to enable PANA messaging between a PaC and PAA because the two nodes cannot reach each other by means of regular IP routing since only a link-local IPv6 address can be used by PaC prior to the completion of a succesful authentication. PRE which is one hop away from PaC receives PANA messages and relays the message contents (payload) by encapsulating it in a message parameter called Attribute Value Pair (AVP). PRE also needs to send header contents such as PaC's IP address and UDP port number in a different AVP. PRE has IP routing established with PAA which could be several hops away. PAA sends its reply messages in which the payload is encapsulated in an AVP. It also adds the AVP containing PaC's IP address and UDP port number. PRE creates a link local PDU using these AVPs and sends it to PaC [I-D.ohba-pana-relay]. The requirements for the use of PANA as a bootsrapping protocol can be stated as follows: o A new entity called PANA Relay Element may be added to the PANA architecture. Behaviour of PANA Relay Element needs to be Sarikaya, et al. Expires May 3, 2012 [Page 13] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 defined. New AVPs needed for PANA Relay Element operation for properly relaying messages from the client to the authenticator and vice versa are required to be specified. o An extension to PANA to securely distribute keys from the PANA Authentication Agent to the PANA Client using AES Key Wrap with Padding algorithm needs to be defined. This is needed in order to use PANA for multicast group key distribution. 5.4. HIP-DEX [RFC4423] introduces the Host Identity Protocol (HIP) where the Host Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit length Host Identity Tag (HIT) is derived from the HI (hashed) and functions as an IPv6 address (/128 prefix) for applications. A four- packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX) establishes a security association (SA, similar to IKE), indexed by the HITs, but independent of the IP address. So HIP can be considered as a shim layer between the transport(TCP/UDP) and IP, providing authentication, data confidentiality, mobility in one basket. As with IKE, HIP is typically used as a Key Management Protocol (KMP) for ESP. However, HIP is independent of IP and ESP and can be used for a KMP for any secure communication protocol at any level. Thus HIP can provide keying material for the MAC, IP, and Transport layers. HIP can be run directly over the MAC in an Ethernet Frame or within an Information Element in a MAC control frame. HIP can be run over UDP, traversing firewalls, and push keys over to Transport security protocols like SRTP or (D)TLS. Further, HIP could start on the MAC, then be enveloped over UDP after the first link. The HIP-BEX involves many crypto primitives that are difficult to run on constrained nodes. HIP Diet Exchange (HIP-DEX) [I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight. Basically, HIP-DEX a variant of the HIP-BEX specifically designed to use as few crypto primitives as possible yet still provide the same class of security features as HIP-BEX. HIP-DEX can be used for mutual authentication between two endpoints. After mutual authentication, the two endpints establish a shared secret, which is fresh and fed into the encryption algorithm for data confidentiality. So HIP-DEX can achieve the authentication, key freshness and data confidentiality objectives of security bootstrapping. When a node wants to authenticate to the network using HIP and Diet- HIP, it should be able to complete the HIP-BEX or HIP-DEX with the Sarikaya, et al. Expires May 3, 2012 [Page 14] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 trust anchor or some delegate. In HIP, it does not matter how many domains, and nodes can authenticate each other as long as they have the secret. In the architecture introduced in Section 2.2 the node and router could be the HIP end-points. Or the router could be a HIP Rendezvous Server, with the node registering to the rendezvous server (RVS) [RFC5204] to be reachable by other nodes. Typically the initial interaction will have the node be the HIP DEX Initiator with the router being the Responder. Using the RVS function on a Router any node could be the Initiator with any other Responder node. As long as there is IP connectivity between the Initiator and Responder, they can be multiple hops away from each other. Alternatively if the first hop from the Initiator has knowledge of the IP address of the Responder, it can act as a MAC/IP gateway for HIP. An important requirement for the HIP-DEX to work in the architecture, the initiator should be able to get the IP address of the responder or have a gateway function as a forwarder. The IP address can be obtained from a 3rd party source like DNS of Distributed Hash Table (DHT), from local configuration, or from an RVS. 5.5. 802.1X IEEE 802.1X defines how EAP packets can be transported over in Layer 2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and the authenticator. EAPOL can also be used in 802.11 wireless links. To enable IEEE 802.15.4 devices to use EAP authentication, EAP packets encapsulated in EAPOL frames can be carried as payload in 802.15.4 data frames [802.15.4]. EAPOL is well defined and widely used and it lends itself to be easily carried in 802.15.4 data frames. For this, Frame Type subfield of the Frame Control Field of IEEE 802.15.4 MAC header needs to be set to a special value to indicate the type of the payload, i.e. 802.1X encapsulated EAP packets. EAPOL packets are encoded following common EAPOL PDU structure defined in [802.1x] into the data payload field of 802.15.4 data frames. Authentication proceeds as follows: authenticator authenticates the supplicants that are on the next hop first. This enables a secure link between the authenticator and these first-hop nodes. The architecture introduced in Section 2.2 requires a new entity called Relay Authenticator. First-hop nodes or router become Relay Authenticators in the next phase of authentication. Relay Authenticators tunnel EAPOL frames to the authenticator in the secure link established. This way all the supplicants are gradually Sarikaya, et al. Expires May 3, 2012 [Page 15] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 authenticated. After the keys are established from a successful EAP method (such as PSK mode of TLS), the node runs neighbor discovery protocol to get an IPv6 address assigned [I-D.ietf-6lowpan-nd]. Data transfer can be secured using DTLS or IPSec. Keys derived from EAP TLS are used in either generating DTLS ciphering keys after a successful DTLS handshake or IPSec ESP ciphering keys after a successful IKEv2 handshake. 802.1X can achieve the authentication, key freshness and data confidentiality objectives of security bootstrapping. Multi domain operation is intrinsically supported due to the use of EAP and AAA. In order to support a device recommissioning case whereby the device's administrative domain is modified, after a new AAA server address assigned and a successful 802.1X method execution, the old set of device 'name and password' MUST be overwritten into the device by a new set of 'name and password' that are assigned by the domain administrator. The device MUST be rebooted to execute EAP method again for authentication and a new master session key MUST be generated. The requirements for the use of 802.1X defined EAPOL as a bootsrapping protocol can be stated as follows: o A special value in the Frame Type subfield of the Frame Control Field of IEEE 802.15.4 MAC header to indicate the type of the payload, o Link Layer Multicast Group addresses for 802.15.4 corresponding to EAPOL Group Address Assignments defined in Table 11.1 of [802.1x], especially to be used in EAPOL-Start packet. o Which MAC frames of beacon, data, acknowledgment and MAC command as defined in [802.15.4] with what security levels are mapped to controlled port, which MAC frames with what security levels are mapped to uncontrolled port and which MAC frames are never mapped to any of controlled/uncontrolled port (i.e., the payload of those frames are used by the MAC-ayer ieself and never used by upper layers). o A new entity called Relay Authenticator may be added to the 802.1x architecture. Behaviour of Relay Authenticator needs to be defined. Sarikaya, et al. Expires May 3, 2012 [Page 16] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 6. Security Considerations When security bootstrapping resource constraint nodes is undertaken, several attacks are possible and security bootstrapping methods described in this document do not protect the nodes against such attacks. These attacks are similar to the ones described in [RFC3971] and mainly stem from unsecured link layer. Link layer must be secured on each node before the node can begin security bootstrapping. If a bootstrapping protocol does not rely on a pre-shared key for peer authentication, it must rely on an online or offline third-party (e.g., an authentication server, a key distribution center in Kerberos, a certification authority in PKI, a private key generator in ID-based cryptography and so on) to prevent man-in-the-middle attacks during peer authentication. Depending on use cases, a resource-constrained device may not always have access to an online third-party for peer authentication. Depending on use cases, a bootstrapping protocol may deal with authorization separately from authentication in terms of timing and signaling path. For example, two resource-constrained devices A and B may perform mutual authentication using authentication credentials provided by an offline third-party X whereas resource-constrained device A obtains authorization for running a particular application with resource-constrained device B from an online third-party Y before or after the authentication. In some use cases, authentication and authorization are tightly coupled, e.g., successful authentication also means successful authorization. A bootstrapping protocol supports various types of authentication and authorization or different bootstrapping protocols may be used for different types of authentication and authorization. If authorization information includes cryptographic keys, a special care must be taken for dealing with the keys, e.g., guidelines for AAA-based key management are described in [RFC4962]. A recommissioning use case may require revocation and re-installation of authentication credentials (i.e., a certificate or a shared secret and identity information, etc.) to a large number of resource- constrained devices that are already deployed. Re-installation of authentication credentials must be as secure as the initial installation regardless of whether the re-installation is done manually or automatically. If resource-constrained devices use a multicast group key for peer authentication or message authentication or encryption, the group key must be securely distributed to the current members of the group for both initial key distribution and key update. Protocols designed for Sarikaya, et al. Expires May 3, 2012 [Page 17] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 group key management such as GSAKMP [RFC4535], GDOI [RFC3547] and MIKEY [RFC3830] may be used for group key distribution. Alternatively, key wrap attributes for securely encapsulating group key may be defined in network access authentication protocols such as PANA [RFC5191] and EAP-TTLSv0 [RFC5281]. Those protocols use an end- to-end, point-to-point communication channel with a pair-wise security association between a key distribution center and each key recipient. Further considerations may be needed for more efficient group key management to support a large number of resource- constrained devices. 7. IANA Considerations This memo includes no request to IANA. 8. Contributors The people listed below have made significant text contributions to this document. Colin O'Flynn colin.oflynn@atmel.com 9. Acknowledgements Thanks to Zach Shelby for editing, comments, and overall assistance. Special thanks also to Rene Struik, Carsten Borman, Gary Yang and Alper Yegin for their comments that helped us improve the writing. 10. References 10.1. Normative References [802.15.4] IEEE Std 802.15.4-2006, "Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs)", September 2006. [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network Access Control", February 2010. [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version 1.00", March 2009. Sarikaya, et al. Expires May 3, 2012 [Page 18] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [ROMER04] Romer, K. and F. Mattern, "The design space of wireless sensor networks", IEEE Wireless Communications, vol. 11, no. 6, pp. 54-61, December 2004. [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical Requirements Document", April 2010. 10.2. Informative References [C1222] American National Standard, "Protocol Specification For Interfacing to Data Communication Networks", ANSI C12.22- 2008, 2008. [I-D.ietf-6lowpan-nd] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress), October 2011. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Sarikaya, et al. Expires May 3, 2012 [Page 19] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-07 (work in progress), July 2011. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. [I-D.moskowitz-hip-rg-dex] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-hip-rg-dex-05 (work in progress), March 2011. [I-D.ohba-pana-keywrap] Cragie, R., Duffy, P., Ohba, Y., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Extension for Key Wrap", draft-ohba-pana-keywrap-04 (work in progress), September 2011. [I-D.ohba-pana-relay] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", draft-ohba-pana-relay-03 (work in progress), February 2011. [NISTIR7628VOL1] The Smart Grid Interoperability Panel - Cyber Security Working Group, "Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements", NISTIR 7628, vol. 1, 2010. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, Sarikaya, et al. Expires May 3, 2012 [Page 20] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 December 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Appendix A. Examples of Node Configuration Before any detail on methods is explored, the following section will provide various examples this document could cover. Exact requirements will be brought forward in subsequent sections. For the reader's general understanding this section is placed to give an idea of an acceptable usage scenario. Sarikaya, et al. Expires May 3, 2012 [Page 21] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 A.1. Smart Energy A.1.1. Initial Meter Installation The meter is initially loaded with code and network keys through a physical interface at the factory. The meter is installed at a customers home, and configured by the installer through the backbone link (via GSM modem, etc). Both operations can be performed through methods defined herein. A.1.2. Home Expansions The user wishes to join a thermostat onto the network. They press a button on the thermostat, which enters join mode. They press a button on the smart meter, which allows nodes to join the network. The devices both have displays, so they display a certain number which the user verifies match on both devices. The thermostat has now securely joined the network. A.2. Consumer Products A.2.1. Connecting DVD Remote to DVD Player The user pushes a join button on the DVD remote and DVD player. The devices find each other, and blink in unison to indicate to the user which two devices will join. The user presses the button to confirm this, and the two devices are now joined together. A.2.2. Adding a TV to a network with a DVD player and remote The user then presses the join button on the DVD player and TV. The devices again find each other and blink in unison, with the addition that the remote control also blinks to indicate it is present in the network. A.2.3. Providing GPS Location Data A user has a simple GPS receiver (that has no user interface) they wish to broadcast location data with. The user switches on their camera, and enters a PIN from the base of the GPS. The user can now view GPS information such as satellite health from their camera. In addition photos are automatically tagged with location information. A.3. Commercial Building Automation Sarikaya, et al. Expires May 3, 2012 [Page 22] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 A.3.1. Light Installation The electrician installs the light fixture. Each light has a barcode printed on it. They use a handheld barcode scanner tool, which acts as the commissioning tool. When they scan a barcode with the tool, the tool asks the electrician to enter some additional information such as light fixture location. The tool securely registers the light fixture on the network, along with setting parameters inside the light fixture. Appendix B. Example Exchanges The following details how the protocol handles certain conditions and situations through examples. Note that each example is a more detailed description of the examples in Appendix A. B.1. Smart Energy: Meter Manufacture B.2. Smart Energy: Meter Installation B.3. Smart Energy: Home Expansion B.4. Consumer: Connecting DVD Remote to DVD Player Supported User Interface Profiles +----------------+------------+----------------+ | Profile | DVD Player | Remote Control | +----------------+------------+----------------+ | none | Y | Y | | simple | Y | Y | | numerical | Y | N | | alphanumerical | Y | N | | Graphical | Y | N | +----------------+------------+----------------+ Supported Bootstrap Transport Layers +----------+------------+----------------+ | Layer | DVD Player | Remote Control | +----------+------------+----------------+ | Physical | Y | Y | | 802.15.4 | Y | Y | | IrDA | Y | N | +----------+------------+----------------+ Sarikaya, et al. Expires May 3, 2012 [Page 23] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 Supported Security Methods +------------------+------------+----------------+ | Method | DVD Player | Remote Control | +------------------+------------+----------------+ | None | Y | Y | | EAP | Y | N | | Asymmetric, User | Y | Y | | Asymmetric, CA | Y | N | +------------------+------------+----------------+ The DVD player and remote control have a number of ways in which they could be joined together. The remote control does not have any unique identifier printed on it, thus no pre-shared key can be identified. This leaves either an unsecure joining method, or some asymmetric security method. The remote control has a button on it for 'join', as does the DVD player. The user pushes the button on the DVD player, and then pushes the button on the remote control. Based on the UI profile, this causes the following to occur: o DVD Player scans for existing network in advertise mode. Finding none, it starts a new network and that network enters advertise mode. o The DVD remote scans for a network, and then finds the DVD player's network. o The devices generate a shared secret (ie: Diffie-Hellman), and both blink their LED in a unique pattern based on this shared secret. o The user user confirms both devices are blinking the same pattern, as both LEDs are blinking in unison. o The DVD player displays 'JOIN OK' on it's LCD panel. B.5. Consumer: Adding a TV to a network with a DVD player and remote This network will have three devices: a TV, a DVD Player, and a Remote Control. The user will run the bootstrap protocol between the TV and Remote Control in this example, although it could also be run between the TV and DVD player. Sarikaya, et al. Expires May 3, 2012 [Page 24] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 Supported User Interface Profiles +----------------+----+----------------+ | Profile | TV | Remote Control | +----------------+----+----------------+ | none | Y | Y | | simple | Y | Y | | numerical | Y | N | | alphanumerical | Y | N | | Graphical | Y | N | +----------------+----+----------------+ Supported Bootstrap Transport Layers +----------+----+----------------+ | Layer | TV | Remote Control | +----------+----+----------------+ | Physical | Y | Y | | 802.15.4 | Y | Y | | IrDA | Y | N | +----------+----+----------------+ Supported Security Methods +------------------+----+----------------+ | Method | TV | Remote Control | +------------------+----+----------------+ | None | Y | Y | | EAP-GPSK | Y | N | | Asymmetric, User | Y | Y | | Asymmetric, CA | Y | N | +------------------+----+----------------+ The TV and remote control have a number of ways in which they could be joined together. The remote control does not have any unique identifier printed on it, thus no pre-shared key can be identified. This leaves either an unsecure joining method, or some asymmetric security method. The remote control has a button on it for 'join', as does the TV. In this example two sequence will be considered: where the TV button is pressed first, and where the remote control button is pressed first. If the TV join button is pressed first: o TV scans for existing networks in advertise mode. Finding none, it starts a new network and that network enters advertise mode. Sarikaya, et al. Expires May 3, 2012 [Page 25] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 o The remote scans for a network, and then finds the TV's network. o The remote informs the TV it is on an existing network, and thus will require the TV to join this network. o The devices generate a shared secret, and both blink their LED in a unique pattern. o The DVD player in addition blinks, so the user is informed that if they confirm the join action the resulting network will have all three devices in it. o The user confirms both devices are blinking the same pattern, as both LEDs are blinking in unison. o The TV displays 'JOIN OK' onscreen, along with any information about the network it just joined. If the remote control join button is pressed first: o Remote control scans for existing networks in advertise mode. Finding none, it advertises it's network. o The TV scans for a network, and then finds the remote control's network. o The devices generate a shared secret, and both blink their LED in a unique pattern. o The DVD player in addition blinks, so the user is informed that if they confirm the join action the resulting network will have all three devices in it. o The user confirms both devices are blinking the same pattern, as both LEDs are blinking in unison. o The TV displays 'JOIN OK' onscreen, along with any information about the network it just joined. B.6. Consumer: Providing GPS Location Data B.7. Commercial: Building Automation Sarikaya, et al. Expires May 3, 2012 [Page 26] Internet-Draft draft-sarikaya-core-sbootstrapping October 2011 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Email: sarikaya@ieee.org Yoshihiro Ohba Toshiba Tokyo, Japan Email: yoshihiro.ohba@toshiba.co.jp Robert Moskowitz Verizon Business Systems 15210 Sutherland Oak Park, MI 48237 Email: rgm@labs.htt-consult.com Zhen Cao China Mobile Beijing, China Email: caozhen@chinamobile.com Robert Cragie Pacific Gas and Electric 89 Greenfield Crescent Wakefield, UK WF4 4WA Email: robert.cragie@gridmerge.com Sarikaya, et al. Expires May 3, 2012 [Page 27]