idnits 2.17.1 draft-oflynn-core-bootstrapping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 139 has weird spacing: '...mmetric with ...' == Line 938 has weird spacing: '...mmetric with ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 28, 2010) is 5161 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1239, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-08 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Core C. O'Flynn 3 Internet-Draft Atmel Corporation 4 Intended status: Informational B. Sarikaya 5 Expires: September 1, 2010 Huawei USA 6 February 28, 2010 8 Initial Configuration of Resource-Constrained Devices 9 draft-oflynn-core-bootstrapping-00 11 Abstract 13 The Internet of Things is marching its way towards completion. Nodes 14 can use standards from the 6LoWPAN and ROLL WG to achieve IP 15 connectivity. IEEE Standards ensure connectivity at lower layers for 16 resource-constrained devices. Yet a central problem remains at a 17 more basic layer without a suitable answer: how to initially 18 configure the network. Without configuration the network never 19 advances beyond a large box of nodes. Current solutions tend to be 20 specific to a certain vendor, node type, or application. 22 This document outlines exactly what problems are faced in solving 23 this problem. General problems faced in any low-power wireless 24 network are outlined first; followed by how these apply to 25 bootstrapping. A selection of currently proposed techniques is 26 presented. From these a more generic approach is presented, which 27 can solve the problem for a wide range of situations. 29 An emphasis is on performing this bootstrapping in a secure manner. 30 This document does not cover operation of the network securely. This 31 document does provide the basis for allowing the network to operate 32 securely however, by providing standard methods for key exchanges and 33 authentication. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on September 1, 2010. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5 76 1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.3. Why a New Standard? . . . . . . . . . . . . . . . . . . . 6 78 2. Examples of Node Configuration . . . . . . . . . . . . . . . . 6 79 2.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.1.1. Initial Meter Installation . . . . . . . . . . . . . . 6 81 2.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 7 82 2.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 7 83 2.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 7 84 2.2.2. Adding a TV to a network with a DVD player and 85 remote . . . . . . . . . . . . . . . . . . . . . . . . 7 86 2.2.3. Providing GPS Location Data . . . . . . . . . . . . . 7 87 2.3. Commercial Building Automation . . . . . . . . . . . . . . 7 88 2.3.1. Light Installation . . . . . . . . . . . . . . . . . . 7 89 3. Background and Requirements . . . . . . . . . . . . . . . . . 8 90 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 91 3.1.1. IETF Requirements . . . . . . . . . . . . . . . . . . 8 92 3.1.2. Generic Requirements . . . . . . . . . . . . . . . . . 8 93 3.1.2.1. Merging . . . . . . . . . . . . . . . . . . . . . 8 94 3.1.2.2. Mobility . . . . . . . . . . . . . . . . . . . . . 9 95 3.1.2.3. Resources . . . . . . . . . . . . . . . . . . . . 10 96 3.1.2.4. User Interface . . . . . . . . . . . . . . . . . . 10 97 3.1.2.5. Security . . . . . . . . . . . . . . . . . . . . . 10 98 3.1.3. Requirement Summary . . . . . . . . . . . . . . . . . 11 99 3.2. Considerations of Requirements . . . . . . . . . . . . . . 12 100 3.2.1. Resources . . . . . . . . . . . . . . . . . . . . . . 12 101 3.2.2. Security Considerations . . . . . . . . . . . . . . . 12 102 3.2.2.1. Passive Attacks . . . . . . . . . . . . . . . . . 12 103 3.2.2.2. Active Attacks . . . . . . . . . . . . . . . . . . 12 104 3.2.2.3. Timing Attack . . . . . . . . . . . . . . . . . . 13 105 3.3. Existing Bootstrapping Methods . . . . . . . . . . . . . . 13 106 3.3.1. Device Label . . . . . . . . . . . . . . . . . . . . . 13 107 3.3.2. Resurrecting Duckling . . . . . . . . . . . . . . . . 14 108 3.3.3. Button Press . . . . . . . . . . . . . . . . . . . . . 14 109 3.3.4. Out Of Band (OOB) Wireless . . . . . . . . . . . . . . 15 110 3.3.5. Out Of Band (OOB) Physical . . . . . . . . . . . . . . 15 111 4. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 16 112 5. User Interfaces . . . . . . . . . . . . . . . . . . . . . . . 17 113 5.1. Required Functions . . . . . . . . . . . . . . . . . . . . 17 114 5.1.1. User Feedback: Identify Node . . . . . . . . . . . . . 17 115 5.1.2. User Feedback: Confirm Authentication Data to User . . 17 116 5.1.3. User Feedback: FAILED . . . . . . . . . . . . . . . . 18 117 5.1.4. User Feedback: OK . . . . . . . . . . . . . . . . . . 18 118 5.1.5. User Request: Disconnect from Network & Clears . . . . 18 119 5.1.6. User Request: Scan for Network to Join . . . . . . . . 18 120 5.1.7. User Request: Advertise Network . . . . . . . . . . . 18 121 5.2. Example User Interface Profiles . . . . . . . . . . . . . 18 122 5.2.1. No-Interface End Node . . . . . . . . . . . . . . . . 18 123 5.2.2. Minimal-Interface End Node . . . . . . . . . . . . . . 18 124 5.2.2.1. Identify Node . . . . . . . . . . . . . . . . . . 18 125 5.2.2.2. Confirm Authentication Data with User . . . . . . 18 126 5.2.2.3. Button Input . . . . . . . . . . . . . . . . . . . 19 127 5.2.3. Numerical-Interface End Node . . . . . . . . . . . . . 19 128 5.2.3.1. Confirm Authentication Data with User . . . . . . 19 129 5.2.4. Alphanumeric-Interface End Node . . . . . . . . . . . 19 130 5.2.4.1. Confirm Authentication Data with User . . . . . . 19 131 6. Bootstrap Profiles . . . . . . . . . . . . . . . . . . . . . . 19 132 7. Communications Channel . . . . . . . . . . . . . . . . . . . . 20 133 7.1. Supported Communication Channels . . . . . . . . . . . . . 20 134 8. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 20 135 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 136 8.2. EAP-GPSK . . . . . . . . . . . . . . . . . . . . . . . . . 21 137 8.3. Asymmetric with User Authentication, Followed by 138 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21 139 8.4. Asymmetric with Certificate Authority, Followed by 140 Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21 141 8.5. Cryptographically Generated Address Based Address 142 Ownership Verification . . . . . . . . . . . . . . . . . . 21 143 9. Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . . . 21 144 10. Example Exchanges . . . . . . . . . . . . . . . . . . . . . . 22 145 10.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 22 146 10.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 22 147 10.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 22 148 10.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 22 149 10.5. Consumer: Adding a TV to a network with a DVD player 150 and remote . . . . . . . . . . . . . . . . . . . . . . . . 23 151 10.6. Consumer: Providing GPS Location Data . . . . . . . . . . 25 152 10.7. Commercial: Building Automation . . . . . . . . . . . . . 25 153 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25 154 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 155 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 156 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 157 14.1. Normative References . . . . . . . . . . . . . . . . . . . 26 158 14.2. Informative References . . . . . . . . . . . . . . . . . . 27 159 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 28 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 162 1. Introduction 164 Familiarity with constrained network types is assumed here. 165 Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups 166 (WGs) would be a useful reference for the reader. In particular RFC 167 4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] from ROLL, and RFC 168 5673 [RFC5673] from ROLL, and a paper by Romer and Mattern [ROMER04]. 169 Familiarity with application specific examples is also useful, such 170 as Zigbee or Smart Energy groups. 172 A summary of those will be presented, as far as network requirements 173 are concerned. The general network requirements will be further 174 concentrated into requirements surrounding only the bootstrapping 175 issues. 177 A number of solutions which are currently in use will be presented 178 and compared to the requirements. From these the requirements of the 179 final solution is identifiable, and a proposal is made on this. 181 Note this document has considerable extra information that is not 182 designed to be worked into the final I-D. It also has some example 183 specifications of particular applications that would not be present 184 in the final version as they are out of scope of the proposed working 185 group. As a general guide they are very useful, but realistically 186 will be split off to either another I-D or some other location. 188 1.1. What is Bootstrapping? 190 Node configuration is known as bootstrapping in this document. 191 Bootstrapping is any processing required before the network can 192 operate. Typically this will require a number of settings to be 193 transferred between nodes at all layers. This could include anything 194 from link-layer information (ie: wireless channels, link-layer 195 encryption keys) to application-layer information (ie: network names, 196 application encryption keys). 198 Bootstrapping is complete when settings have been securely 199 transferred prior to normal operation in the network. 201 1.2. Why IETF? 203 The bootstrapping problem is not specific to any MAC or PHY. This 204 problem exists across any two nodes which have no previous knowledge 205 of each other. In particular, this problem is complicated when the 206 nodes are resource-constrained and may not have an advanced user 207 interface. The IETF is instrumental in defining standards which will 208 be used by The Internet of Things. Ensuring these standards can be 209 used across nodes and networks requires some form of bootstrapping 210 which any node can use. 212 Existing standards will be used as much as possible in this document. 213 The method proposed here should work across many different underlying 214 layers. It could be used to allow two nodes on the same physical 215 network to join at the physical layer, or allow two nodes on an 216 incompatible physical network to join at the IPv6 layer. 218 1.3. Why a New Standard? 220 Simply put, no existing standard brings together all the required 221 aspects. At lower layers, standards exist to solve the problem in 222 special cases. Examples are Wi-Fi Protected Setup, Bluetooth 223 Pairing, or ZigBee solutions such as RF4CE. As will be discussed 224 later, these are not flexible enough to run on the wide variety of 225 nodes which a smart network will use. 227 At higher layers, standards exist to perform a secure authentication 228 or service discovery. However these standards almost always assume 229 the two nodes have some existing way of communicating, such as being 230 plugged into the same network. This will often not be the case. 232 Thus this document is aimed to bridge this gap. Many existing 233 standards can be applied to solve the problem (e.g.: EAP), but some 234 guidance on their use is required to ensure all implementations 235 interoperate. 237 2. Examples of Node Configuration 239 Before any detail on methods is explored, the following section will 240 provide various examples this document could cover. Exact 241 requirements will be brought forward in subsequent sections. For the 242 reader's general understanding this section is placed to give an idea 243 of an acceptable usage scenario. 245 2.1. Smart Energy 247 2.1.1. Initial Meter Installation 249 The meter is initially loaded with code and network keys through a 250 physical interface at the factory. The meter is installed at a 251 customers home, and configured by the installer through the backbone 252 link (via GSM modem, etc). Both operations can be performed through 253 methods defined herein. 255 2.1.2. Home Expansions 257 The user wishes to join a thermostat onto the network. They press a 258 button on the thermostat, which enters join mode. They press a 259 button on the smart meter, which allows nodes to join the network. 260 The devices both have displays, so they display a certain number 261 which the user verifies match on both devices. The thermostat has 262 now securly joined the network. 264 2.2. Consumer Products 266 2.2.1. Connecting DVD Remote to DVD Player 268 The user pushes a join button on the DVD remote and DVD player. The 269 devices find each other, and blink in unison to indicate to the user 270 which two devices will join. The user presses the button to confirm 271 this, and the two devices are now joined together. 273 2.2.2. Adding a TV to a network with a DVD player and remote 275 The user then presses the join button on the DVD player and TV. The 276 devices again find each other and blink in unison, with the addition 277 that the remote control also blinks to indicate it is present in the 278 network. 280 2.2.3. Providing GPS Location Data 282 A user has a simple GPS receiver (that has no user interface) they 283 wish to broadcast location data with. The user switches on their 284 camera, and enters a PIN from the base of the GPS. The user can now 285 view GPS information such as satellite health from their camera. In 286 addition photos are automatically tagged with location information. 288 2.3. Commercial Building Automation 290 2.3.1. Light Installation 292 The electrician installs the light fixture. Each light has a barcode 293 printed on it. They use a handheld barcode scanner tool, which acts 294 as the commissioning tool. When they scan a barcode with the tool, 295 the tool asks the electrician to enter some additional information 296 such as light fixture location. The tool securely registers the 297 light fixture on the network, along with setting parameters inside 298 the light fixture. 300 3. Background and Requirements 302 3.1. Requirements 304 3.1.1. IETF Requirements 306 Analysing some of the previous RFCs will highlight requirements which 307 are defined in the applicable RFC. For the bootstrapping protocol to 308 remain consistent with these RFCs, support MUST be carried forward. 310 RFC 5673 [RFC5673] defines routing requirements for using lossy 311 networks in industrial environments. Section 10 in particular deals 312 with network management. The protocol requires that some form of 313 external configuration is present. In addition it strongly suggests 314 that nodes can be configured over the air, however it does allow for 315 information such as security tokens or communication frequencies to 316 be pre-distributed in nodes. 318 RFC 5548 [RFC5548] defines routing requirements for using lossy 319 networks in urban environments. Section 4.1 deals with the 320 deployment of nodes. It is noted that nodes will be deployed in 321 networks of hundreds to thousands at once most likely. The 322 configuration must remain flexible enough to support these mass roll- 323 outs without significant overhead. 325 RFC 4919 [RFC4919] defines considerations for a 6LoWPAN network. 326 This includes the idea that network bootstrapping should be easy to 327 perform, and able to work "out of the box". This suggests the 328 bootstrapping procedure should be as autonomous as possible. 330 Security requirements and recommendations are found in a variety of 331 IETF sources. RFC 3748 [RFC3748] section 7.1 defines security 332 considerations for EAP. A more focused look at LoWPAN-style network 333 considerations is provided in 334 draft-struik-6lowapp-security-considerations [DRAFTSTRUIK]. 336 3.1.2. Generic Requirements 338 Several examples from different application spaces will be presented. 339 This will help to furthur guide requirements. 341 3.1.2.1. Merging 343 When setting up a network, many networks may be 'accidently' set up. 344 Consider the use who brings home a blister-pack of a wireless light 345 switch and light. The manufacturer is not aware of the environment 346 the user will install this in; they do not know if an existing 347 network is present. The best 'user experience' is one in which 348 devices automatically form a network, as the user sees their devices 349 'just work'. A manufacture may pre-load devices with security keys 350 in this case to ensure they communicate out of the box. If the user 351 purchases products from different manufactures or product lines 352 however, these devices may all set up different networks. 354 These seperate networks may be totally unaware of each other. Later 355 on the user may wish for the seperate networks to function as one 356 system, as they wish for all lights to be centrally controlled. 357 Similar situations could be imagined when using remote controls for 358 home entertainment; each device such as the DVD player or TV may form 359 a separate network. The user wishes one remote control to be used on 360 both the TV and DVD player, and does not care about how this occurs. 362 As users realize the power of combining systems this will become more 363 prevalent. For example initially a company may set up separate HVAC, 364 security, and lighting systems. Later they realize that temperatures 365 in rooms could be automatically adjusted by detecting if anyone is 366 present, which requires input from the security and lighting systems. 368 Depending on the network architecture multiple networks may need to 369 merge together to provide this intercommunication. A very simple 370 wireless network for example would require all nodes to be on the 371 same physical layer. Physical layer means either the same channel, 372 or in a channel-hopping network the same channel sequence. Thus when 373 nodes on multiple networks are brought together in these 374 circumstances, the nodes would have to merge to one large network. 376 More complex and larger networks may solve this problem at a higher 377 layer. For example the HVAC, security, and lighting systems in a 378 building may be on completely different networks. Each system 379 however has a communications link to the same router, and nodes can 380 communicate by normal IP routing. 382 3.1.2.2. Mobility 384 Nodes will naturally be mobile; either by design in networks such as 385 asset tracking, or by accident when nodes are broken. If a node 386 needs to be replaced, the question is how easily can this be done. 387 Even if nodes are fixed, the environment around them can change. A 388 wireless network could find it's peers changed when a metal filing 389 cabinet is installed, or the old leaking microwave is used. 391 An extension of this mobility requirement is that the networks may 392 not have any central authority. Pure mesh networks are one example 393 of this. Other networks may have a central authority, but this node 394 might be elected by the network. The end user does not know which 395 node is the coordinator, hence the bootstrapping protocol cannot 396 require the user to perform an action on the central authority. 398 3.1.2.3. Resources 400 The extreme resource constraints of the nodes provides further 401 problems. These resource constraints include cost, memory 402 requirements, power requirements, and size requirements. These are 403 not consistent either: some nodes may have parasitic power measured 404 in micro-amps, but some nodes may be directly connected to the power 405 grid. Likewise some nodes may have a tiny 8-bit microcontroller, but 406 other nodes will have 32-bit microcontrollers running Linux. The 407 bootstrapping process must take into account the wide range of 408 resource constraints. The protocol should run on a tiny end node, 409 while not making itself useless on a larger end node. 411 3.1.2.4. User Interface 413 The user interface may also be constrained. Typical user interfaces 414 may be limited to a push-button and a few LEDs. More advanced nodes 415 may have graphical displays and keyboards, however the bootstrapping 416 process should not assume such nodes are available. 418 3.1.2.5. Security 420 Security of any network is important. The level of security required 421 depends on a number of network parameters including what would happen 422 if unauthorized access occurred, how easily attacks could occur, and 423 the difficulty of tracing attackers. Some networks would require 424 obvious protection, such as parking meters or ATMs. An attacker 425 would have a significant financial incentive to attack such networks, 426 and the cost of unauthorized access is very high. 428 Less obvious requirements exist when the cost of unauthorized access 429 is low. Someone controlling lights in your house or changing the TV 430 channel has minimal impact financially, and the attacker has almost 431 nothing to gain. However analysis of the other two parameters shows 432 the danger in this attack; the attack is both very easy to perform, 433 and it would be almost impossible to catch the attacker. A similar 434 example occurred at the Consumer Electronics Show (CES) in 2006, 435 where a device was brought in which would cycle through almost every 436 known TV 'off' command, and broadcast it with an IR LED [GIZMODO]. 437 It was used to interrupt vendor demos and presentations, showing the 438 importance of making security part of every network. 440 A similar consideration exists for Bluetooth; there may be very 441 little financial incentive for attacks, but they are easy to perform 442 and it would be difficult to get caught. Bluejacking is the act of 443 sending unsolicited messages to another bluetooth-enabled device such 444 as PDA or phone. No 'security' is broken with Bluejacking, many 445 devices are configured to receive certain messages and prompt the 446 user. This allows two workers with Bluetooth-enabled phones to 447 quickly send contact details to each other for example; a perfect 448 demonstration of the trade-off between 'easy to use' and 'secure'. 450 EAP authentication requires EAP packets to be encapsulated at the 451 link layer in resource constrained links. Efficient encapsulation 452 techniques MUST be developed, separately for each link type such as 453 IEEE 802.15.4. 455 Address ownership verification between a node and its router using 456 CGA requires a modified version of IPv6 neighbor discovery protocol 457 to be executed. An example neighbor discovery protocol is 6LOWPAN 458 neighbor discovery protocol [I-D.ietf-6lowpan-nd]. 460 3.1.3. Requirement Summary 462 From the previous two sections, a summary of the requirements which a 463 bootstrapping protocol should follow can be made. Note these are 464 defining the requirements for the underlying protocol, they do not 465 mean that every implementation works this way. For example in higher 466 security environments node mobility may be disallowed, requiring new 467 nodes to register with a central authority. However such decisions 468 should be policy decisions, and not a limitation of the underlying 469 protocol. 471 o Works from any node authorized to do so by the network. In simple 472 networks this might be any end node. 474 o Does not rely on nodes being in a specific state. This is 475 required to support network merging, where nodes will already be 476 in a 'configured' state. 478 o Minimal resource requirements. This means bootstrapping MUST NOT 479 require nodes to contain resources for the sole use of 480 bootstrapping. Again this is a policy decision in that nodes MAY 481 have extra hardware to assist during bootstrapping. This must 482 remain OPTIONAL in the protocol though. 484 o Secure. The protocol must provide a secure link during 485 bootstrapping if required; the security in use during normal 486 network operation is not in the scope of this document. 488 3.2. Considerations of Requirements 490 3.2.1. Resources 492 Resource requirements form the most imposing requirement. Many nodes 493 will have very strict limits on power, size, or cost. For example a 494 node which runs on parasitic power simply cannot afford to use a 495 high-power protocol for node configuration. Thus the protocol must 496 run on the 'lowest common denominator' of available hardware. 498 A realistic view of the application space shows that several 499 protocols will need to be selected. Protocols which run on a home 500 network may not be appropriate in industrial or medical environments 501 for example. Ideally all nodes would support a 'base' protocol which 502 would allow them to interoperate. This ensures that the market does 503 not become fragmented with incompatible nodes; a user should know 504 that without a doubt two nodes will interoperate. 506 3.2.2. Security Considerations 508 Operation of the network securely is beyond the scope of this 509 document. The bootstrapping problem is only concerned with security 510 during the initial configuration. The bootstrapping protocol MUST 511 provide a secure method of exchanging arbitrary information. This 512 channel needs only to exist during bootstrapping, and for example 513 could include OOB links. General information on network security 514 could be found in RFC 3552 [RFC3552]. A more detailed description of 515 problems facing these networks is found in 516 draft-struik-6lowapp-security-considerations [DRAFTSTRUIK]. 518 Specific attacks of interest for bootstrapping are passive attacks, 519 active attacks, and timing attacks. Each will be considered in 520 sequence. 522 3.2.2.1. Passive Attacks 524 RF networks are naturally susceptible to passive listening attacks. 525 Attacks can be performed with a minimum of hardware; for example on 526 Wi-Fi networks this may require only the hardware present in a 527 typical laptop computer. It may be expanded on by a variety of very 528 simple or low-cost antennas. Sending a plain-text password or 529 network key is an example of systems susceptible to passive 530 listening. 532 3.2.2.2. Active Attacks 534 Active attacks require an attacker to transmit data. This could 535 include Man In The Middle (MITM) attacks for example, where an 536 attacker inserts themselves between two nodes when they are initially 537 forming a network. The two nodes think they are directly talking to 538 each other, but instead are talking through a third proxy node. 540 3.2.2.3. Timing Attack 542 Timing attacks are not cryptographic attacks. They instead attack 543 protocols which have a narrow window of opportunity. For example in 544 the push-button protocol the end user presses the button on two nodes 545 which they wish to join. However an attacker could bring a third 546 node close-by, and by pressing the button on this node cause the 547 attackers node to join the network instead. 549 3.3. Existing Bootstrapping Methods 551 There are a number of existing bootstrapping methods presented. This 552 section provides an outline of them, along with discussing advantages 553 and disadvantages to each method. 555 3.3.1. Device Label 557 Device labels are used as a form of shared secret. The initial 558 shared secret is exchanged by the user, which forms an Out Of Band 559 (OOB) channel. An example given in Wi-Fi Protected Setup (WPS) is as 560 follows: a user brings home a new cell phone. A PIN is written on 561 the label on the end router, they enter this PIN into the cell phone. 562 This allows the cell phone to securely join the network, as both the 563 cell phone and router know the shared PIN. Later when a printer is 564 brought home, the user reads a PIN off the printer. They again enter 565 this PIN into the cell phone, which can communicate the PIN to the 566 router. Now the router and printer again have a shared secret, and 567 the printer is allowed on the network securely. [WPS] 569 Extensions of the simple device PIN could include machine-readable 570 barcodes. Whereas a device PIN that is entered by a human requires a 571 label and has limited entropy, using machine-readable barcodes 572 reduces the label size requirements while increasing the amount of 573 information stored. 575 Nodes which have displays would also not have a fixed PIN. Instead 576 they display a new PIN each time. A fixed PIN could either be read 577 covertly if an attacker had physical access, or brute-forced since it 578 is fixed. The dynamic PIN provides additional security since it is 579 valid only once. 581 ADVANTAGES: 583 o Simple, requires no extra hardware on end nodes. 585 o Machine readable barcodes would assist in deploying large numbers 586 of nodes. They could just be scanned before being deployed. 588 o Depending on deployment details (e.g.: label entropy, dynamic 589 PINs) security can be quite good. 591 DISADVANTAGES: 593 o Extra cost of labels and ensuring the labels match any 594 preprogrammed information when using fixed PINs. 596 o Requires one node on network to have advanced user interface. 598 o OOB is one-way only. 600 3.3.2. Resurrecting Duckling 602 This method simply works because some 'mother' node is present near 603 the first operation of the end node. As an example, when a remote 604 control is powered up, it simply associates with the nearby TV 605 [STAJANO99]. This is very intuitive to the end user. 607 To make the node associate with a new mother, the node is 'killed'. 608 This reverts the node back to the state when it was first powered on, 609 and it will then attempt to associate with a new nearby mother node. 611 ADVANTAGES: 613 o Simple, requires no extra hardware on end nodes. 615 o Very intuitive to end users. 617 DISADVANTAGES: 619 o Requires at least one node to be special (aka: mother). 621 o Could not handle a network merge. 623 o Hard to ensure node connects to a specific 'mother' node when 624 multiple mothers are present. 626 3.3.3. Button Press 628 A button press is a simple method of making two nodes associate. In 629 the most basic form, a button is pressed on two nodes which should 630 associate. The nodes detect each other's presence, and join up. 632 Button-press is used by WPS, Bluetooth, and other proprietary 633 solutions (such as XBox 360's wireless controllers). ZigBee RF4CE 634 [RF4CE] uses this method. 636 ADVANTAGES: 638 o Simple, most nodes probably have hardware already to run protocol. 640 o Very intuitive to end users. 642 o Can work with a 'merge' algorithm. 644 DISADVANTAGES: 646 o Low security. 648 3.3.4. Out Of Band (OOB) Wireless 650 Some OOB channel is used. Examples could include IrDA or Near Field 651 Communication (NFC). These are typically very short-range to enhance 652 security. The end user simply touches two nodes together for 653 example, which allows the nodes to exchange information. 655 ADVANTAGES: 657 o Very secure (provided OOB channel is secure). 659 o Intuitive to end users - just touch two nodes together. 661 o Can work with a 'merge' algorithm. 663 o Functions in hostile / intristically safe environments 665 DISADVANTAGES: 667 o Requires additional hardware on end nodes, with associated cost 668 and power requirements. 670 3.3.5. Out Of Band (OOB) Physical 672 All nodes already have a physical channel. This is primarily used to 673 program the node for example, but may also be used to download 674 configuration information to the node. 676 ADVANTAGES: 678 o No-cost solution as all nodes require this interface anyway. 680 o Intuitive to end users - just connect two nodes together. 682 o Can work with almost any network configuration. 684 o Can provide power to end nodes. 686 DISADVANTAGES: 688 o No current standard used between nodes. 690 4. Bootstrapping Architecture 692 In order to provide a flexible architecture, the bootstrapping method 693 is split into five distinct areas. The five areas are a 'user 694 interface', 'bootstrap profile', 'security method', 'bootstrap 695 protocol', and the 'communications channel'. 697 The user interface provides both user input and user output. Simple 698 nodes may only have a push-button and LED, more complex nodes may 699 have a graphical display and keyboard. The user interface provides 700 interaction between the user and bootstrapping methods. The user 701 interface would be used during bootstrapping as an OOB channel. It 702 may also be used to specify bootstrapping policies. 704 The user interface provides the interaction between the user and the 705 bootstrap protocol. The user interface will vary depending on the 706 capabilities of the node. Examples might include a push-button and 707 LED on simple nodes, to full-blown graphical user interfaces. Note 708 that a 'bootstrapping tool' used to initially deploy a network is 709 just a special user interface. This allows a very uniform protocol 710 in deployment and use of networks. 712 Two nodes communicate through some channel. For our purposes this is 713 split into the 'control channel' and 'data channel'. The control 714 channel is used for the bootstrap protocol, and the data channel is 715 used during normal network operation. A node may support multiple 716 control or data channels. When the control and data channels are the 717 same, the bootstrapping is done In Band (IB). When the control and 718 data channels are different, the bootstrapping is performed Out Of 719 Band (OOB). An 802.15.4 network for instance would use an 802.15.4 720 control channel for IB bootstrapping, but a control channel of 721 perhaps IrDA or USB for OOB bootstrapping. 723 The 'bootstrap profile' defines what information should be exchanged 724 during the process. A single node may run the protocol multiple 725 times with different profiles. If the user wishes to associate a new 726 lightswitch, the protocol is first run with the '802.15.4 Wireless 727 Profile', through which it learns the channel and PAN-ID. The node 728 then runs a 'Security Exchange Profile' to learn the needed 729 encryption keys. Finally it runs a 'Lightswitch Association Profile' 730 through which it learns which light to associate with. 732 The 'security method' defines supported security methods for 733 bootstrapping. The supported security methods will depend on the 734 control channel and bootstrap profile. In one node if the control 735 channel is secure, then a simple clear-text security method is 736 supported. For example when a physical connection between two nodes 737 is used, the control channel is considered secure. However when the 738 BTL is not secure, this clear-text security method is not supported. 739 The 'bootstrap profile' additionally defines allowed security 740 methods. Higher security nodes may outlaw ever performing a clear- 741 text exchange, even if the control channel is deemed secure. 743 The 'bootstrap protocol' defines the actual messages exchanged during 744 bootstrapping. The messages are used to transfer between nodes data, 745 node information, and network state. The selected security method 746 runs on top of the control channel, such as EAP-GPSK etc. 748 5. User Interfaces 750 User interfaces provide an interface between the bootstrap protocols 751 and the user. This is used for instance in selecting devices or 752 checking security. The interface must provide a number of functions 753 as defined here. 755 5.1. Required Functions 757 5.1.1. User Feedback: Identify Node 759 During a join process, the user will be required to confirm which two 760 nodes are being joined together. For this the 'identify node' 761 function performs an action such as blinking an LED or displaying a 762 message. 764 5.1.2. User Feedback: Confirm Authentication Data to User 766 When performing a Diffie &mdash Hellman style key exchange, some form 767 of authentication is required. This function presents the 768 authentication data to the user, where the user confirms that the 769 expected two devices will be joined. Example: Bluetooth Secure 770 Simple Pairing's [BSSP] numeric comparison . 772 5.1.3. User Feedback: FAILED 774 Alerts the user to a failed bootstrap attempt. 776 5.1.4. User Feedback: OK 778 Alerts the user to a successful bootstrap attempt. 780 5.1.5. User Request: Disconnect from Network & Clears 782 This disconnects the node from the network, and clears settings back 783 to a factory-default configuration. 785 5.1.6. User Request: Scan for Network to Join 787 This enters the 'join' mode on an end node, scanning for a network in 788 'advertise' mode. 790 5.1.7. User Request: Advertise Network 792 This mode advertises the current running network. If no network is 793 running, the node may start a new network. 795 5.2. Example User Interface Profiles 797 Parts of the 'required functions' that must agree between end nodes 798 are specified here. For example on nodes which support 'confirm 799 authentication data with user', we need to ensure that both nodes 800 display the same authentication data. Each level higher in the 801 interface hierarchy automatically inherits every profile below it. 803 5.2.1. No-Interface End Node 805 A no-interface end node has no method of user interaction. 807 5.2.2. Minimal-Interface End Node 809 A minimal-interface node has a single LED and single button. 811 5.2.2.1. Identify Node 813 The LED blinks. 815 5.2.2.2. Confirm Authentication Data with User 817 The authentication data will be confirmed by a blink pattern. The 818 user can confirm that both nodes blink in the same pattern, which 819 means both nodes have swapped the correct data. TODO: Specify the 820 exact function used to generate the blink pattern from the crypto 821 data such as public keys, etc. The user confirms the data by 822 pressing the button on the node. If they either do not press the 823 button, or hold the button down for X seconds, they have not 824 confirmed the data and the authentication data will be considered 825 INVALID. 827 5.2.2.3. Button Input 829 The button controls all available user requests. 831 When the button is pressed, the node automatically performs a scan 832 for other networks in 'advertise' mode. If no networks are found, 833 the node may then switch to 'advertise' mode. This sequence ensures 834 two nodes will *always* find each other if they can communicate at 835 the BTL. 837 If the button is held down for X seconds, the user is requesting a 838 Disconnect/Memory Clear. 840 5.2.3. Numerical-Interface End Node 842 A numerical-interface end node has a display capable of displaying at 843 least 6 numbers 845 5.2.3.1. Confirm Authentication Data with User 847 A number is calculated based on the crypto data. Example: Bluebooth 848 Secure Simple Pairing. 850 5.2.4. Alphanumeric-Interface End Node 852 A numerical-interface end node has a display capable of displaying up 853 to 24 characters. 855 5.2.4.1. Confirm Authentication Data with User 857 A character string is calculated based on the crypto data. 859 6. Bootstrap Profiles 861 The bootstrapping profile defines what and how data must be 862 exchanged. The bootstrapping profile is where network policies can 863 be placed, such as allowed methods of joining. 865 Bootstrap profiles bring together the various aspects of the 866 bootstrap method. The bootstrap profile specifies items such as: 868 o 870 o 872 7. Communications Channel 874 The communications channel is the method used between two nodes to 875 communicate. There are two main communication channels: the 876 'control' and 'data' channels. The control channel is used during 877 bootstrapping, and the data channel is used during network operation. 879 7.1. Supported Communication Channels 881 There is no limit on what communications channels are supported. The 882 following gives an example of several supported channels: 884 o IEEE 802.15.4 886 o Power-Line Communications 888 o IrDA 890 o RFID 892 o Some simple physical link 894 o Cellular 896 o Ethernet 898 o IPv6 900 o Wi-Fi 902 Depending on the node's function, it may use different channels as 903 the data or control channel. Nodes may have multiple data and/or 904 control channels as wel. 906 8. Bootstrap Security Method 908 The bootstrap security method defines allowable security methods. A 909 node may choose to support or use a subset of these methods. This is 910 NOT the security architecture used for the application, but only the 911 security used during bootstrapping. Typically some high-security 912 method is used to generate a shared secret, which then switches to 913 simplier symmetric encryption to secure the actual bootstrapping 914 channel. The techniques negotiated should take advantage of hardware 915 resources available, such as hardware encryption accelerators on an 916 end node. 918 8.1. None 920 This is the simplist security method. No encryption or 921 authentication is provided, messages are exchanged completely in 922 clear-text. It is assumed some other layer provides security, such 923 as a physical connection between devices. 925 8.2. EAP-GPSK 927 EAP-GPSK is used as the authentication method [RFC5433]. Keys must 928 be pre-shared through some other method. 930 8.3. Asymmetric with User Authentication, Followed by Symmetric 932 A Diffie-Hellman style key exchange is used to generate a shared 933 secret. The authentication will be provided by the user, by 934 confirming cryptographic signatures between two devices. With the 935 shared secret generated through the DH, some symmetric encryption is 936 used to secure the actual bootstrapping channel. 938 8.4. Asymmetric with Certificate Authority, Followed by Symmetric 940 Public key exchanges are used (aka: DH again), but with a Certificate 941 Authority. Once a shared secret exists, symmetric encryption is used 942 to secure the actual bootstrapping channel. 944 8.5. Cryptographically Generated Address Based Address Ownership 945 Verification 947 A node may generate the global unique address using different 948 techniques other than the stateless address autoconfiguration. For 949 example, Cryptographically Generated Addresses (CGA) [RFC3972] is a 950 type of global unique address that can be used to verify the address 951 ownership. When the node uses CGA, it MUST execute SeND protocol 952 [RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol 953 [I-D.ietf-6lowpan-nd] must be executed between the node and the edge 954 router. 956 9. Bootstrap Protocol 958 The bootstrap protocol defines several messages which can be sent 959 over the BTL. The bootstrap protocol is a small wrapper around the 960 standard authentication functions used, such as EAP etc. The 961 bootstrap protocol will negotiate allowable standards between nodes. 962 When a TV is joining a remote control for example, the bootstrap 963 protocol must understand that the remote control has very limited 964 feedback to the user. Hence the method selected must not rely on a 965 complex user interface on the remote, even though the TV has a 966 complex interface available. 968 Specifics TBD. 970 10. Example Exchanges 972 The following details how the protocol handles certain conditions and 973 situations through examples. Note that each example is a more 974 detailed description of the examples in Section 2. 976 10.1. Smart Energy: Meter Manufacture 978 10.2. Smart Energy: Meter Installation 980 10.3. Smart Energy: Home Expansion 982 10.4. Consumer: Connecting DVD Remote to DVD Player 984 Supported User Interface Profiles 986 +----------------+------------+----------------+ 987 | Profile | DVD Player | Remote Control | 988 +----------------+------------+----------------+ 989 | none | Y | Y | 990 | simple | Y | Y | 991 | numerical | Y | N | 992 | alphanumerical | Y | N | 993 | Graphical | Y | N | 994 +----------------+------------+----------------+ 996 Supported Bootstrap Transport Layers 998 +----------+------------+----------------+ 999 | Layer | DVD Player | Remote Control | 1000 +----------+------------+----------------+ 1001 | Physical | Y | Y | 1002 | 802.15.4 | Y | Y | 1003 | IrDA | Y | N | 1004 +----------+------------+----------------+ 1005 Supported Security Methods 1007 +------------------+------------+----------------+ 1008 | Method | DVD Player | Remote Control | 1009 +------------------+------------+----------------+ 1010 | None | Y | Y | 1011 | EAP-GPSK | Y | N | 1012 | Asymmetric, User | Y | Y | 1013 | Asymmetric, CA | Y | N | 1014 +------------------+------------+----------------+ 1016 The DVD player and remote control have a number of ways in which they 1017 could be joined together. The remote control does not have any 1018 unique identifier printed on it, thus no pre-shared key can be 1019 identified. This leaves either an unsecure joining method, or some 1020 asymmetric security method. 1022 The remote control has a button on it for 'join', as does the DVD 1023 player. The user pushes the button on the DVD player, and then 1024 pushes the button on the remote control. Based on the UI profile, 1025 this causes the following to occur: 1027 o DVD Player scans for existing network in advertise mode. Finding 1028 none, it starts a new network and that network enters advertise 1029 mode. 1031 o The DVD remote scans for a network, and then finds the DVD 1032 player's network. 1034 o The devices generate a shared secret (ie: Diffie-Hellman), and 1035 both blink their LED in a unique pattern based on this shared 1036 secret. 1038 o The user user confirms both devices are blinking the same pattern, 1039 as both LEDs are blinking in unison. 1041 o The DVD player displays 'JOIN OK' on it's LCD panel. 1043 10.5. Consumer: Adding a TV to a network with a DVD player and remote 1045 This network will have three devices: a TV, a DVD Player, and a 1046 Remote Control. The user will run the bootstrap protocol between the 1047 TV and Remote Control in this example, although it could also be run 1048 between the TV and DVD player. 1050 Supported User Interface Profiles 1052 +----------------+----+----------------+ 1053 | Profile | TV | Remote Control | 1054 +----------------+----+----------------+ 1055 | none | Y | Y | 1056 | simple | Y | Y | 1057 | numerical | Y | N | 1058 | alphanumerical | Y | N | 1059 | Graphical | Y | N | 1060 +----------------+----+----------------+ 1062 Supported Bootstrap Transport Layers 1064 +----------+----+----------------+ 1065 | Layer | TV | Remote Control | 1066 +----------+----+----------------+ 1067 | Physical | Y | Y | 1068 | 802.15.4 | Y | Y | 1069 | IrDA | Y | N | 1070 +----------+----+----------------+ 1072 Supported Security Methods 1074 +------------------+----+----------------+ 1075 | Method | TV | Remote Control | 1076 +------------------+----+----------------+ 1077 | None | Y | Y | 1078 | EAP-GPSK | Y | N | 1079 | Asymmetric, User | Y | Y | 1080 | Asymmetric, CA | Y | N | 1081 +------------------+----+----------------+ 1083 The TV and remote control have a number of ways in which they could 1084 be joined together. The remote control does not have any unique 1085 identifier printed on it, thus no pre-shared key can be identified. 1086 This leaves either an unsecure joining method, or some asymmetric 1087 security method. 1089 The remote control has a button on it for 'join', as does the TV. In 1090 this example two sequence will be considered: where the TV button is 1091 pressed first, and where the remote control button is pressed first. 1093 If the TV join button is pressed first: 1095 o TV scans for existing networks in advertise mode. Finding none, 1096 it starts a new network and that network enters advertise mode. 1098 o The remote scans for a network, and then finds the TV's network. 1100 o The remote informs the TV it is on an existing network, and thus 1101 will require the TV to join this network. 1103 o The devices generate a shared secret, and both blink their LED in 1104 a unique pattern. 1106 o The DVD player in addition blinks, so the user is informed that if 1107 they confirm the join action the resulting network will have all 1108 three devices in it. 1110 o The user confirms both devices are blinking the same pattern, as 1111 both LEDs are blinking in unison. 1113 o The TV displays 'JOIN OK' onscreen, along with any information 1114 about the network it just joined. 1116 If the remote control join button is pressed first: 1118 o Remote control scans for existing networks in advertise mode. 1119 Finding none, it advertises it's network. 1121 o The TV scans for a network, and then finds the remote control's 1122 network. 1124 o The devices generate a shared secret, and both blink their LED in 1125 a unique pattern. 1127 o The DVD player in addition blinks, so the user is informed that if 1128 they confirm the join action the resulting network will have all 1129 three devices in it. 1131 o The user confirms both devices are blinking the same pattern, as 1132 both LEDs are blinking in unison. 1134 o The TV displays 'JOIN OK' onscreen, along with any information 1135 about the network it just joined. 1137 10.6. Consumer: Providing GPS Location Data 1139 10.7. Commercial: Building Automation 1141 11. Conclusion 1143 Initial configuration of a network is essential to interoperability. 1144 This process is known as bootstrapping, and a variety of solutions 1145 have been proposed previously. An analysis of the requirements shows 1146 that no single solution is likely to meet all the requirements, 1147 instead multiple solutions will be picked. At least one of these 1148 must remain capable of running on the most resource constrained 1149 nodes, ensuring that all nodes are capable of at least a single 1150 common communication channel. 1152 This document helps to focus on a method of solving this problem in a 1153 flexible and extensible way. It is very much a work in progress, and 1154 is expected to undergo radical changes before it becomes complete. 1155 Please comment on the mailing list or add missing sections as you see 1156 fit. 1158 12. Contributors 1160 Initial draft by Colin O'Flynn and Behcet Sarikaya. Thanks to Zach 1161 Shelby and Robert Craige for editing, comments, and overall 1162 assistance. 1164 13. IANA Considerations 1166 This memo includes no request to IANA. 1168 All drafts are required to have an IANA considerations section (see 1169 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 1170 for a guide). If the draft does not require IANA to do anything, the 1171 section contains an explicit statement that this is the case (as 1172 above). If there are no requirements for IANA, the section will be 1173 removed during conversion into an RFC by the RFC Editor. 1175 14. References 1177 14.1. Normative References 1179 [BSSP] Bluetooth Special Interest Group, "Bluetooth Secure Simple 1180 Pairing Whitepaper", August 2006. 1182 [DRAFTSTRUIK] 1183 Struik, R., "Security Architectural Design Considerations 1184 for Low-Power Wireless Sensor Networks", Oct 2009. 1186 [GIZMODO] Gizmodo, "Confessions: The Meanest Thing Gizmodo Did at 1187 CES", January 2008. 1189 [RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version 1190 1.00", March 2009. 1192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1193 Requirement Levels", BCP 14, RFC 2119, March 1997. 1195 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1196 Levkowetz, "Extensible Authentication Protocol (EAP)", 1197 RFC 3748, June 2004. 1199 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1200 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1201 Overview, Assumptions, Problem Statement, and Goals", 1202 RFC 4919, August 2007. 1204 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1205 "Routing Requirements for Urban Low-Power and Lossy 1206 Networks", RFC 5548, May 2009. 1208 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1209 "Industrial Routing Requirements in Low-Power and Lossy 1210 Networks", RFC 5673, October 2009. 1212 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 1213 sensor networks", IEEE Wireless Communications, vol. 11, 1214 no. 6, pp. 54-61, December 2004. 1216 [STAJANO99] 1217 Stajano, F. and A. Anderson, "The Resurrecting Duckling: 1218 Security Issues for Ad-hoc Wireless Networks", Proceedings 1219 of the 7th International Workshop on Security Protocols , 1220 LNCS , vol. 1796, pp. 172-194, 1999. 1222 [WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup Specification 1223 v1.0", 2007. 1225 14.2. Informative References 1227 [I-D.ietf-6lowpan-nd] 1228 Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., 1229 Bormann, C., and E. Nordmark, "6LoWPAN Neighbor 1230 Discovery", draft-ietf-6lowpan-nd-08 (work in progress), 1231 February 2010. 1233 [I-D.narten-iana-considerations-rfc2434bis] 1234 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1235 IANA Considerations Section in RFCs", 1236 draft-narten-iana-considerations-rfc2434bis-09 (work in 1237 progress), March 2008. 1239 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1240 June 1999. 1242 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1243 Text on Security Considerations", BCP 72, RFC 3552, 1244 July 2003. 1246 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1247 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1249 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1250 RFC 3972, March 2005. 1252 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1253 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1254 RFC 5433, February 2009. 1256 Appendix A. Additional Stuff 1258 This becomes an Appendix. 1260 Authors' Addresses 1262 Colin Patrick O'Flynn 1263 Atmel Corporation 1264 Colorado Springs, Colorado 1265 USA 1267 Phone: 1268 Email: colin.oflynn@atmel.com 1270 Behcet Sarikaya 1271 Huawei USA 1272 1700 Alma Dr. Suite 500 1273 Plano, TX 75075 1275 Email: sarikaya@ieee.org