Core C. O'Flynn Internet-Draft Atmel Corporation Intended status: Informational B. Sarikaya Expires: September 1, 2010 Huawei USA February 28, 2010 Initial Configuration of Resource-Constrained Devices draft-oflynn-core-bootstrapping-00 Abstract The Internet of Things is marching its way towards completion. Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP connectivity. IEEE Standards ensure connectivity at lower layers for resource-constrained devices. Yet a central problem remains at a more basic layer without a suitable answer: how to initially configure the network. Without configuration the network never advances beyond a large box of nodes. Current solutions tend to be specific to a certain vendor, node type, or application. This document outlines exactly what problems are faced in solving this problem. General problems faced in any low-power wireless network are outlined first; followed by how these apply to bootstrapping. A selection of currently proposed techniques is presented. From these a more generic approach is presented, which can solve the problem for a wide range of situations. An emphasis is on performing this bootstrapping in a secure manner. This document does not cover operation of the network securely. This document does provide the basis for allowing the network to operate securely however, by providing standard methods for key exchanges and authentication. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." O'Flynn & Sarikaya Expires September 1, 2010 [Page 1] Internet-Draft draft-oflynn-core-bootstrapping February 2010 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 BSD License. O'Flynn & Sarikaya Expires September 1, 2010 [Page 2] Internet-Draft draft-oflynn-core-bootstrapping February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5 1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Why a New Standard? . . . . . . . . . . . . . . . . . . . 6 2. Examples of Node Configuration . . . . . . . . . . . . . . . . 6 2.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Initial Meter Installation . . . . . . . . . . . . . . 6 2.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 7 2.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 7 2.2.2. Adding a TV to a network with a DVD player and remote . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. Providing GPS Location Data . . . . . . . . . . . . . 7 2.3. Commercial Building Automation . . . . . . . . . . . . . . 7 2.3.1. Light Installation . . . . . . . . . . . . . . . . . . 7 3. Background and Requirements . . . . . . . . . . . . . . . . . 8 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. IETF Requirements . . . . . . . . . . . . . . . . . . 8 3.1.2. Generic Requirements . . . . . . . . . . . . . . . . . 8 3.1.2.1. Merging . . . . . . . . . . . . . . . . . . . . . 8 3.1.2.2. Mobility . . . . . . . . . . . . . . . . . . . . . 9 3.1.2.3. Resources . . . . . . . . . . . . . . . . . . . . 10 3.1.2.4. User Interface . . . . . . . . . . . . . . . . . . 10 3.1.2.5. Security . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Requirement Summary . . . . . . . . . . . . . . . . . 11 3.2. Considerations of Requirements . . . . . . . . . . . . . . 12 3.2.1. Resources . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. Security Considerations . . . . . . . . . . . . . . . 12 3.2.2.1. Passive Attacks . . . . . . . . . . . . . . . . . 12 3.2.2.2. Active Attacks . . . . . . . . . . . . . . . . . . 12 3.2.2.3. Timing Attack . . . . . . . . . . . . . . . . . . 13 3.3. Existing Bootstrapping Methods . . . . . . . . . . . . . . 13 3.3.1. Device Label . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. Resurrecting Duckling . . . . . . . . . . . . . . . . 14 3.3.3. Button Press . . . . . . . . . . . . . . . . . . . . . 14 3.3.4. Out Of Band (OOB) Wireless . . . . . . . . . . . . . . 15 3.3.5. Out Of Band (OOB) Physical . . . . . . . . . . . . . . 15 4. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 16 5. User Interfaces . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Required Functions . . . . . . . . . . . . . . . . . . . . 17 5.1.1. User Feedback: Identify Node . . . . . . . . . . . . . 17 5.1.2. User Feedback: Confirm Authentication Data to User . . 17 5.1.3. User Feedback: FAILED . . . . . . . . . . . . . . . . 18 5.1.4. User Feedback: OK . . . . . . . . . . . . . . . . . . 18 5.1.5. User Request: Disconnect from Network & Clears . . . . 18 5.1.6. User Request: Scan for Network to Join . . . . . . . . 18 O'Flynn & Sarikaya Expires September 1, 2010 [Page 3] Internet-Draft draft-oflynn-core-bootstrapping February 2010 5.1.7. User Request: Advertise Network . . . . . . . . . . . 18 5.2. Example User Interface Profiles . . . . . . . . . . . . . 18 5.2.1. No-Interface End Node . . . . . . . . . . . . . . . . 18 5.2.2. Minimal-Interface End Node . . . . . . . . . . . . . . 18 5.2.2.1. Identify Node . . . . . . . . . . . . . . . . . . 18 5.2.2.2. Confirm Authentication Data with User . . . . . . 18 5.2.2.3. Button Input . . . . . . . . . . . . . . . . . . . 19 5.2.3. Numerical-Interface End Node . . . . . . . . . . . . . 19 5.2.3.1. Confirm Authentication Data with User . . . . . . 19 5.2.4. Alphanumeric-Interface End Node . . . . . . . . . . . 19 5.2.4.1. Confirm Authentication Data with User . . . . . . 19 6. Bootstrap Profiles . . . . . . . . . . . . . . . . . . . . . . 19 7. Communications Channel . . . . . . . . . . . . . . . . . . . . 20 7.1. Supported Communication Channels . . . . . . . . . . . . . 20 8. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 20 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. EAP-GPSK . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.3. Asymmetric with User Authentication, Followed by Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21 8.4. Asymmetric with Certificate Authority, Followed by Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21 8.5. Cryptographically Generated Address Based Address Ownership Verification . . . . . . . . . . . . . . . . . . 21 9. Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . . . 21 10. Example Exchanges . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 22 10.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 22 10.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 22 10.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 22 10.5. Consumer: Adding a TV to a network with a DVD player and remote . . . . . . . . . . . . . . . . . . . . . . . . 23 10.6. Consumer: Providing GPS Location Data . . . . . . . . . . 25 10.7. Commercial: Building Automation . . . . . . . . . . . . . 25 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 O'Flynn & Sarikaya Expires September 1, 2010 [Page 4] Internet-Draft draft-oflynn-core-bootstrapping February 2010 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] from ROLL, and RFC 5673 [RFC5673] from ROLL, and a paper by Romer and Mattern [ROMER04]. Familiarity with application specific examples is also useful, such as Zigbee or Smart Energy groups. 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 and compared to the requirements. From these the requirements of the final solution is identifiable, and a proposal is made on this. Note this document has considerable extra information that is not designed to be worked into the final I-D. It also has some example specifications of particular applications that would not be present in the final version as they are out of scope of the proposed working group. As a general guide they are very useful, but realistically will be split off to either another I-D or some other location. 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 (ie: wireless channels, link-layer encryption keys) to application-layer information (ie: 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 O'Flynn & Sarikaya Expires September 1, 2010 [Page 5] Internet-Draft draft-oflynn-core-bootstrapping February 2010 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. 1.3. Why a New Standard? Simply put, no existing standard brings together all the required aspects. At lower layers, standards exist to solve the problem in special cases. Examples are Wi-Fi Protected Setup, Bluetooth Pairing, or ZigBee solutions such as RF4CE. As will be discussed later, these are not flexible enough to run on the wide variety of nodes which a smart network will use. At higher layers, standards exist to perform a secure authentication or service discovery. However these standards almost always assume the two nodes have some existing way of communicating, such as being plugged into the same network. This will often not be the case. Thus this document is aimed to bridge this gap. Many existing standards can be applied to solve the problem (e.g.: EAP), but some guidance on their use is required to ensure all implementations interoperate. 2. 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. 2.1. Smart Energy 2.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. O'Flynn & Sarikaya Expires September 1, 2010 [Page 6] Internet-Draft draft-oflynn-core-bootstrapping February 2010 2.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 securly joined the network. 2.2. Consumer Products 2.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. 2.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. 2.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. 2.3. Commercial Building Automation 2.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. O'Flynn & Sarikaya Expires September 1, 2010 [Page 7] Internet-Draft draft-oflynn-core-bootstrapping February 2010 3. Background and Requirements 3.1. Requirements 3.1.1. IETF Requirements Analysing some of the previous RFCs will highlight requirements which are defined in the applicable RFC. For the bootstrapping protocol to remain consistent with these RFCs, support MUST be carried forward. RFC 5673 [RFC5673] defines routing requirements for using lossy networks in industrial environments. Section 10 in particular deals with network management. The protocol requires that some form of external configuration is present. In addition it strongly suggests that nodes can be configured over the air, however it does allow for information such as security tokens or communication frequencies to be pre-distributed in nodes. RFC 5548 [RFC5548] defines routing requirements for using lossy networks in urban environments. Section 4.1 deals with the deployment of nodes. It is noted that nodes will be deployed in networks of hundreds to thousands at once most likely. The configuration must remain flexible enough to support these mass roll- outs without significant overhead. RFC 4919 [RFC4919] defines considerations for a 6LoWPAN network. This includes the idea that network bootstrapping should be easy to perform, and able to work "out of the box". This suggests the bootstrapping procedure should be as autonomous as possible. Security requirements and recommendations are found in a variety of IETF sources. RFC 3748 [RFC3748] section 7.1 defines security considerations for EAP. A more focused look at LoWPAN-style network considerations is provided in draft-struik-6lowapp-security-considerations [DRAFTSTRUIK]. 3.1.2. Generic Requirements Several examples from different application spaces will be presented. This will help to furthur guide requirements. 3.1.2.1. Merging When setting up a network, many networks may be 'accidently' set up. Consider the use who brings home a blister-pack of a wireless light switch and light. The manufacturer is not aware of the environment the user will install this in; they do not know if an existing network is present. The best 'user experience' is one in which O'Flynn & Sarikaya Expires September 1, 2010 [Page 8] Internet-Draft draft-oflynn-core-bootstrapping February 2010 devices automatically form a network, as the user sees their devices 'just work'. A manufacture may pre-load devices with security keys in this case to ensure they communicate out of the box. If the user purchases products from different manufactures or product lines however, these devices may all set up different networks. These seperate networks may be totally unaware of each other. Later on the user may wish for the seperate networks to function as one system, as they wish for all lights to be centrally controlled. Similar situations could be imagined when using remote controls for home entertainment; each device such as the DVD player or TV may form a separate network. The user wishes one remote control to be used on both the TV and DVD player, and does not care about how this occurs. As users realize the power of combining systems this will become more prevalent. For example initially a company may set up separate HVAC, security, and lighting systems. Later they realize that temperatures in rooms could be automatically adjusted by detecting if anyone is present, which requires input from the security and lighting systems. Depending on the network architecture multiple networks may need to merge together to provide this intercommunication. A very simple wireless network for example would require all nodes to be on the same physical layer. Physical layer means either the same channel, or in a channel-hopping network the same channel sequence. Thus when nodes on multiple networks are brought together in these circumstances, the nodes would have to merge to one large network. More complex and larger networks may solve this problem at a higher layer. For example the HVAC, security, and lighting systems in a building may be on completely different networks. Each system however has a communications link to the same router, and nodes can communicate by normal IP routing. 3.1.2.2. Mobility Nodes will naturally be mobile; either by design in networks such as asset tracking, or by accident when nodes are broken. If a node needs to be replaced, the question is how easily can this be done. Even if nodes are fixed, the environment around them can change. A wireless network could find it's peers changed when a metal filing cabinet is installed, or the old leaking microwave is used. An extension of this mobility requirement is that the networks may not have any central authority. Pure mesh networks are one example of this. Other networks may have a central authority, but this node might be elected by the network. The end user does not know which node is the coordinator, hence the bootstrapping protocol cannot O'Flynn & Sarikaya Expires September 1, 2010 [Page 9] Internet-Draft draft-oflynn-core-bootstrapping February 2010 require the user to perform an action on the central authority. 3.1.2.3. Resources The extreme resource constraints of the nodes provides further problems. These resource constraints include cost, memory requirements, power requirements, and size requirements. These are not consistent either: some nodes may have parasitic power measured in micro-amps, but some nodes may be directly connected to the power grid. Likewise some nodes may have a tiny 8-bit microcontroller, but other nodes will have 32-bit microcontrollers running Linux. The bootstrapping process must take into account the wide range of resource constraints. The protocol should run on a tiny end node, while not making itself useless on a larger end node. 3.1.2.4. User Interface The user interface may also be constrained. Typical user interfaces may be limited to a push-button and a few LEDs. More advanced nodes may have graphical displays and keyboards, however the bootstrapping process should not assume such nodes are available. 3.1.2.5. Security Security of any network is important. The level of security required depends on a number of network parameters including what would happen if unauthorized access occurred, how easily attacks could occur, and the difficulty of tracing attackers. Some networks would require obvious protection, such as parking meters or ATMs. An attacker would have a significant financial incentive to attack such networks, and the cost of unauthorized access is very high. Less obvious requirements exist when the cost of unauthorized access is low. Someone controlling lights in your house or changing the TV channel has minimal impact financially, and the attacker has almost nothing to gain. However analysis of the other two parameters shows the danger in this attack; the attack is both very easy to perform, and it would be almost impossible to catch the attacker. A similar example occurred at the Consumer Electronics Show (CES) in 2006, where a device was brought in which would cycle through almost every known TV 'off' command, and broadcast it with an IR LED [GIZMODO]. It was used to interrupt vendor demos and presentations, showing the importance of making security part of every network. A similar consideration exists for Bluetooth; there may be very little financial incentive for attacks, but they are easy to perform and it would be difficult to get caught. Bluejacking is the act of sending unsolicited messages to another bluetooth-enabled device such O'Flynn & Sarikaya Expires September 1, 2010 [Page 10] Internet-Draft draft-oflynn-core-bootstrapping February 2010 as PDA or phone. No 'security' is broken with Bluejacking, many devices are configured to receive certain messages and prompt the user. This allows two workers with Bluetooth-enabled phones to quickly send contact details to each other for example; a perfect demonstration of the trade-off between 'easy to use' and 'secure'. EAP authentication requires EAP packets to be encapsulated at the link layer in resource constrained links. Efficient encapsulation techniques MUST be developed, separately for each link type such as IEEE 802.15.4. Address ownership verification between a node and its router using CGA requires a modified version of IPv6 neighbor discovery protocol to be executed. An example neighbor discovery protocol is 6LOWPAN neighbor discovery protocol [I-D.ietf-6lowpan-nd]. 3.1.3. Requirement Summary From the previous two sections, a summary of the requirements which a bootstrapping protocol should follow can be made. Note these are defining the requirements for the underlying protocol, they do not mean that every implementation works this way. For example in higher security environments node mobility may be disallowed, requiring new nodes to register with a central authority. However such decisions should be policy decisions, and not a limitation of the underlying protocol. o Works from any node authorized to do so by the network. In simple networks this might be any end node. o Does not rely on nodes being in a specific state. This is required to support network merging, where nodes will already be in a 'configured' state. o Minimal resource requirements. This means bootstrapping MUST NOT require nodes to contain resources for the sole use of bootstrapping. Again this is a policy decision in that nodes MAY have extra hardware to assist during bootstrapping. This must remain OPTIONAL in the protocol though. o Secure. The protocol must provide a secure link during bootstrapping if required; the security in use during normal network operation is not in the scope of this document. O'Flynn & Sarikaya Expires September 1, 2010 [Page 11] Internet-Draft draft-oflynn-core-bootstrapping February 2010 3.2. Considerations of Requirements 3.2.1. Resources Resource requirements form the most imposing requirement. Many nodes will have very strict limits on power, size, or cost. For example a node which runs on parasitic power simply cannot afford to use a high-power protocol for node configuration. Thus the protocol must run on the 'lowest common denominator' of available hardware. A realistic view of the application space shows that several protocols will need to be selected. Protocols which run on a home network may not be appropriate in industrial or medical environments for example. Ideally all nodes would support a 'base' protocol which would allow them to interoperate. This ensures that the market does not become fragmented with incompatible nodes; a user should know that without a doubt two nodes will interoperate. 3.2.2. Security Considerations Operation of the network securely is beyond the scope of this document. The bootstrapping problem is only concerned with security during the initial configuration. The bootstrapping protocol MUST provide a secure method of exchanging arbitrary information. This channel needs only to exist during bootstrapping, and for example could include OOB links. General information on network security could be found in RFC 3552 [RFC3552]. A more detailed description of problems facing these networks is found in draft-struik-6lowapp-security-considerations [DRAFTSTRUIK]. Specific attacks of interest for bootstrapping are passive attacks, active attacks, and timing attacks. Each will be considered in sequence. 3.2.2.1. Passive Attacks RF networks are naturally susceptible to passive listening attacks. Attacks can be performed with a minimum of hardware; for example on Wi-Fi networks this may require only the hardware present in a typical laptop computer. It may be expanded on by a variety of very simple or low-cost antennas. Sending a plain-text password or network key is an example of systems susceptible to passive listening. 3.2.2.2. Active Attacks Active attacks require an attacker to transmit data. This could include Man In The Middle (MITM) attacks for example, where an O'Flynn & Sarikaya Expires September 1, 2010 [Page 12] Internet-Draft draft-oflynn-core-bootstrapping February 2010 attacker inserts themselves between two nodes when they are initially forming a network. The two nodes think they are directly talking to each other, but instead are talking through a third proxy node. 3.2.2.3. Timing Attack Timing attacks are not cryptographic attacks. They instead attack protocols which have a narrow window of opportunity. For example in the push-button protocol the end user presses the button on two nodes which they wish to join. However an attacker could bring a third node close-by, and by pressing the button on this node cause the attackers node to join the network instead. 3.3. Existing Bootstrapping Methods There are a number of existing bootstrapping methods presented. This section provides an outline of them, along with discussing advantages and disadvantages to each method. 3.3.1. Device Label Device labels are used as a form of shared secret. The initial shared secret is exchanged by the user, which forms an Out Of Band (OOB) channel. An example given in Wi-Fi Protected Setup (WPS) is as follows: a user brings home a new cell phone. A PIN is written on the label on the end router, they enter this PIN into the cell phone. This allows the cell phone to securely join the network, as both the cell phone and router know the shared PIN. Later when a printer is brought home, the user reads a PIN off the printer. They again enter this PIN into the cell phone, which can communicate the PIN to the router. Now the router and printer again have a shared secret, and the printer is allowed on the network securely. [WPS] Extensions of the simple device PIN could include machine-readable barcodes. Whereas a device PIN that is entered by a human requires a label and has limited entropy, using machine-readable barcodes reduces the label size requirements while increasing the amount of information stored. Nodes which have displays would also not have a fixed PIN. Instead they display a new PIN each time. A fixed PIN could either be read covertly if an attacker had physical access, or brute-forced since it is fixed. The dynamic PIN provides additional security since it is valid only once. ADVANTAGES: O'Flynn & Sarikaya Expires September 1, 2010 [Page 13] Internet-Draft draft-oflynn-core-bootstrapping February 2010 o Simple, requires no extra hardware on end nodes. o Machine readable barcodes would assist in deploying large numbers of nodes. They could just be scanned before being deployed. o Depending on deployment details (e.g.: label entropy, dynamic PINs) security can be quite good. DISADVANTAGES: o Extra cost of labels and ensuring the labels match any preprogrammed information when using fixed PINs. o Requires one node on network to have advanced user interface. o OOB is one-way only. 3.3.2. Resurrecting Duckling This method simply works because some 'mother' node is present near the first operation of the end node. As an example, when a remote control is powered up, it simply associates with the nearby TV [STAJANO99]. This is very intuitive to the end user. To make the node associate with a new mother, the node is 'killed'. This reverts the node back to the state when it was first powered on, and it will then attempt to associate with a new nearby mother node. ADVANTAGES: o Simple, requires no extra hardware on end nodes. o Very intuitive to end users. DISADVANTAGES: o Requires at least one node to be special (aka: mother). o Could not handle a network merge. o Hard to ensure node connects to a specific 'mother' node when multiple mothers are present. 3.3.3. Button Press A button press is a simple method of making two nodes associate. In the most basic form, a button is pressed on two nodes which should associate. The nodes detect each other's presence, and join up. O'Flynn & Sarikaya Expires September 1, 2010 [Page 14] Internet-Draft draft-oflynn-core-bootstrapping February 2010 Button-press is used by WPS, Bluetooth, and other proprietary solutions (such as XBox 360's wireless controllers). ZigBee RF4CE [RF4CE] uses this method. ADVANTAGES: o Simple, most nodes probably have hardware already to run protocol. o Very intuitive to end users. o Can work with a 'merge' algorithm. DISADVANTAGES: o Low security. 3.3.4. Out Of Band (OOB) Wireless Some OOB channel is used. Examples could include IrDA or Near Field Communication (NFC). These are typically very short-range to enhance security. The end user simply touches two nodes together for example, which allows the nodes to exchange information. ADVANTAGES: o Very secure (provided OOB channel is secure). o Intuitive to end users - just touch two nodes together. o Can work with a 'merge' algorithm. o Functions in hostile / intristically safe environments DISADVANTAGES: o Requires additional hardware on end nodes, with associated cost and power requirements. 3.3.5. Out Of Band (OOB) Physical All nodes already have a physical channel. This is primarily used to program the node for example, but may also be used to download configuration information to the node. ADVANTAGES: o No-cost solution as all nodes require this interface anyway. O'Flynn & Sarikaya Expires September 1, 2010 [Page 15] Internet-Draft draft-oflynn-core-bootstrapping February 2010 o Intuitive to end users - just connect two nodes together. o Can work with almost any network configuration. o Can provide power to end nodes. DISADVANTAGES: o No current standard used between nodes. 4. Bootstrapping Architecture In order to provide a flexible architecture, the bootstrapping method is split into five distinct areas. The five areas are a 'user interface', 'bootstrap profile', 'security method', 'bootstrap protocol', and the 'communications channel'. 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 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. 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' defines what information should be exchanged 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 O'Flynn & Sarikaya Expires September 1, 2010 [Page 16] Internet-Draft draft-oflynn-core-bootstrapping February 2010 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. 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 BTL 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. 5. User Interfaces User interfaces provide an interface between the bootstrap protocols and the user. This is used for instance in selecting devices or checking security. The interface must provide a number of functions as defined here. 5.1. Required Functions 5.1.1. User Feedback: Identify Node During a join process, the user will be required to confirm which two nodes are being joined together. For this the 'identify node' function performs an action such as blinking an LED or displaying a message. 5.1.2. User Feedback: Confirm Authentication Data to User When performing a Diffie &mdash Hellman style key exchange, some form of authentication is required. This function presents the authentication data to the user, where the user confirms that the expected two devices will be joined. Example: Bluetooth Secure Simple Pairing's [BSSP] numeric comparison . O'Flynn & Sarikaya Expires September 1, 2010 [Page 17] Internet-Draft draft-oflynn-core-bootstrapping February 2010 5.1.3. User Feedback: FAILED Alerts the user to a failed bootstrap attempt. 5.1.4. User Feedback: OK Alerts the user to a successful bootstrap attempt. 5.1.5. User Request: Disconnect from Network & Clears This disconnects the node from the network, and clears settings back to a factory-default configuration. 5.1.6. User Request: Scan for Network to Join This enters the 'join' mode on an end node, scanning for a network in 'advertise' mode. 5.1.7. User Request: Advertise Network This mode advertises the current running network. If no network is running, the node may start a new network. 5.2. Example User Interface Profiles Parts of the 'required functions' that must agree between end nodes are specified here. For example on nodes which support 'confirm authentication data with user', we need to ensure that both nodes display the same authentication data. Each level higher in the interface hierarchy automatically inherits every profile below it. 5.2.1. No-Interface End Node A no-interface end node has no method of user interaction. 5.2.2. Minimal-Interface End Node A minimal-interface node has a single LED and single button. 5.2.2.1. Identify Node The LED blinks. 5.2.2.2. Confirm Authentication Data with User The authentication data will be confirmed by a blink pattern. The user can confirm that both nodes blink in the same pattern, which means both nodes have swapped the correct data. TODO: Specify the O'Flynn & Sarikaya Expires September 1, 2010 [Page 18] Internet-Draft draft-oflynn-core-bootstrapping February 2010 exact function used to generate the blink pattern from the crypto data such as public keys, etc. The user confirms the data by pressing the button on the node. If they either do not press the button, or hold the button down for X seconds, they have not confirmed the data and the authentication data will be considered INVALID. 5.2.2.3. Button Input The button controls all available user requests. When the button is pressed, the node automatically performs a scan for other networks in 'advertise' mode. If no networks are found, the node may then switch to 'advertise' mode. This sequence ensures two nodes will *always* find each other if they can communicate at the BTL. If the button is held down for X seconds, the user is requesting a Disconnect/Memory Clear. 5.2.3. Numerical-Interface End Node A numerical-interface end node has a display capable of displaying at least 6 numbers 5.2.3.1. Confirm Authentication Data with User A number is calculated based on the crypto data. Example: Bluebooth Secure Simple Pairing. 5.2.4. Alphanumeric-Interface End Node A numerical-interface end node has a display capable of displaying up to 24 characters. 5.2.4.1. Confirm Authentication Data with User A character string is calculated based on the crypto data. 6. Bootstrap Profiles The bootstrapping profile defines what and how data must be exchanged. The bootstrapping profile is where network policies can be placed, such as allowed methods of joining. Bootstrap profiles bring together the various aspects of the bootstrap method. The bootstrap profile specifies items such as: O'Flynn & Sarikaya Expires September 1, 2010 [Page 19] Internet-Draft draft-oflynn-core-bootstrapping February 2010 o o 7. 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. 7.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 the data or control channel. Nodes may have multiple data and/or control channels as wel. 8. 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 O'Flynn & Sarikaya Expires September 1, 2010 [Page 20] Internet-Draft draft-oflynn-core-bootstrapping February 2010 channel. The techniques negotiated should take advantage of hardware resources available, such as hardware encryption accelerators on an end node. 8.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. 8.2. EAP-GPSK EAP-GPSK is used as the authentication method [RFC5433]. Keys must be pre-shared through some other method. 8.3. 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. 8.4. 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. 8.5. 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. 9. Bootstrap Protocol The bootstrap protocol defines several messages which can be sent over the BTL. The bootstrap protocol is a small wrapper around the standard authentication functions used, such as EAP etc. The O'Flynn & Sarikaya Expires September 1, 2010 [Page 21] Internet-Draft draft-oflynn-core-bootstrapping February 2010 bootstrap protocol will negotiate allowable standards between nodes. When a TV is joining a remote control for example, the bootstrap protocol must understand that the remote control has very limited feedback to the user. Hence the method selected must not rely on a complex user interface on the remote, even though the TV has a complex interface available. Specifics TBD. 10. 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 Section 2. 10.1. Smart Energy: Meter Manufacture 10.2. Smart Energy: Meter Installation 10.3. Smart Energy: Home Expansion 10.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 | +----------+------------+----------------+ O'Flynn & Sarikaya Expires September 1, 2010 [Page 22] Internet-Draft draft-oflynn-core-bootstrapping February 2010 Supported Security Methods +------------------+------------+----------------+ | Method | DVD Player | Remote Control | +------------------+------------+----------------+ | None | Y | Y | | EAP-GPSK | 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. 10.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. O'Flynn & Sarikaya Expires September 1, 2010 [Page 23] Internet-Draft draft-oflynn-core-bootstrapping February 2010 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. O'Flynn & Sarikaya Expires September 1, 2010 [Page 24] Internet-Draft draft-oflynn-core-bootstrapping February 2010 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. 10.6. Consumer: Providing GPS Location Data 10.7. Commercial: Building Automation 11. Conclusion Initial configuration of a network is essential to interoperability. This process is known as bootstrapping, and a variety of solutions O'Flynn & Sarikaya Expires September 1, 2010 [Page 25] Internet-Draft draft-oflynn-core-bootstrapping February 2010 have been proposed previously. An analysis of the requirements shows that no single solution is likely to meet all the requirements, instead multiple solutions will be picked. At least one of these must remain capable of running on the most resource constrained nodes, ensuring that all nodes are capable of at least a single common communication channel. This document helps to focus on a method of solving this problem in a flexible and extensible way. It is very much a work in progress, and is expected to undergo radical changes before it becomes complete. Please comment on the mailing list or add missing sections as you see fit. 12. Contributors Initial draft by Colin O'Flynn and Behcet Sarikaya. Thanks to Zach Shelby and Robert Craige for editing, comments, and overall assistance. 13. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 14. References 14.1. Normative References [BSSP] Bluetooth Special Interest Group, "Bluetooth Secure Simple Pairing Whitepaper", August 2006. [DRAFTSTRUIK] Struik, R., "Security Architectural Design Considerations for Low-Power Wireless Sensor Networks", Oct 2009. [GIZMODO] Gizmodo, "Confessions: The Meanest Thing Gizmodo Did at CES", January 2008. [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version O'Flynn & Sarikaya Expires September 1, 2010 [Page 26] Internet-Draft draft-oflynn-core-bootstrapping February 2010 1.00", March 2009. [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. [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. [STAJANO99] Stajano, F. and A. Anderson, "The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks", Proceedings of the 7th International Workshop on Security Protocols , LNCS , vol. 1796, pp. 172-194, 1999. [WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup Specification v1.0", 2007. 14.2. Informative References [I-D.ietf-6lowpan-nd] Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., Bormann, C., and E. Nordmark, "6LoWPAN Neighbor Discovery", draft-ietf-6lowpan-nd-08 (work in progress), February 2010. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-09 (work in progress), March 2008. O'Flynn & Sarikaya Expires September 1, 2010 [Page 27] Internet-Draft draft-oflynn-core-bootstrapping February 2010 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [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. [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009. Appendix A. Additional Stuff This becomes an Appendix. Authors' Addresses Colin Patrick O'Flynn Atmel Corporation Colorado Springs, Colorado USA Phone: Email: colin.oflynn@atmel.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Email: sarikaya@ieee.org O'Flynn & Sarikaya Expires September 1, 2010 [Page 28]