idnits 2.17.1 draft-behringer-homenet-trust-bootstrap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 208: '... A device MAY require an invitation ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3696 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-01) exists of draft-pritikin-bootstrapping-keyinfrastructures-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Behringer 3 Internet-Draft M. Pritikin 4 Intended status: Informational S. Bjarnason 5 Expires: August 17, 2014 Cisco 6 February 13, 2014 8 Bootstrapping Trust on a Homenet 9 draft-behringer-homenet-trust-bootstrap-02.txt 11 Abstract 13 A homenet must be aware of its borders, and the realms within those. 14 This document proposes an approach to bootstrap trust in such an 15 environment. The idea is to select one device as the trust anchor 16 and to enrol other devices into the domain. The result is the 17 creation of a domain of trust in the homenet, with a common trust 18 anchor. This trust model can subsequently be used to determine 19 boundaries, and to autonomically bootstrap network services. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 17, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2.1. Summary of the approach . . . . . . . . . . . . . . . . . 3 58 2.2. Autonomic devices . . . . . . . . . . . . . . . . . . . . 3 59 2.3. User interface . . . . . . . . . . . . . . . . . . . . . 3 60 2.4. The Registrar . . . . . . . . . . . . . . . . . . . . . . 4 61 2.5. Autonomic Adjacency Discovery . . . . . . . . . . . . . . 4 62 2.6. Validating a new device's identity . . . . . . . . . . . 4 63 2.7. Services . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.8. Network boundaries . . . . . . . . . . . . . . . . . . . 5 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 4. Informative References . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Problem Statement 71 [I-D.ietf-homenet-arch] states that "A homenet will most likely also 72 have internal borders between internal realms, e.g. a guest realm or 73 a corporate network extension realm. It should be possible to 74 automatically discover these borders." Simple approaches, such as 75 terminating a homenet on a particular interface type do not easily 76 allow for devices from different administrative realms to be locally 77 connected. [I-D.ietf-homenet-arch] states further that "It is 78 important that self-configuration with 'unintended' devices is 79 avoided. There should be a way for a user to administratively assert 80 in a simple way whether or not a device belongs to a homenet." 82 An approach is needed that allows to establish trust inside a homenet 83 according to a policy set by the user of the homenet. 85 2. Approach 87 This approach is based on making homenet devices behave in autonomic 88 mode where devices discover each others and autonomically establish 89 trust boundaries. See [I-D.behringer-autonomic-network-framework] 90 for more information on autonomic networking. 92 The document "Bootstrapping Key Infrastructures" 93 [I-D.pritikin-bootstrapping-keyinfrastructures] explains in detail 94 how key infrastructures can be securely and automatically deployed. 95 This document applied those concepts to a homenet. 97 2.1. Summary of the approach 99 In short, the approach is: 101 o The user pairs a smart phone (or similar device) with one of the 102 devices in the homenet, for example the CPE. The smart phone acts 103 as a user interface only. 105 o The selected device automatically becomes the trust anchor of the 106 homenet. Technically, it acts as a certification authority (CA) 107 as well as a registration authority (RA) (see section 3.1 and 3.2 108 of [I-D.pritikin-bootstrapping-keyinfrastructures]). 110 o Devices in the homenet use a protocol to exchange identities. 112 o A new device is added to the homenet by the user accepting it on 113 the smart phone, and the CA issuing a domain certificate to the 114 new device. 116 o The boundary of the network is determined by checking the 117 certificates of devices. 119 2.2. Autonomic devices 121 An autonomic device can be a router, switch, PC, smartphone, or any 122 other device, independent of its role in the network, which has the 123 autonomic functionality mentioned below. A homenet consists of 124 autonomic devices and non-autonomic devices. This approach requires 125 at least one autonomic networking device, such as a router or switch. 127 2.3. User interface 129 The user interface can be provided by the devices themselves or for 130 example through a smart phone interface. It is also possible to 131 access the devices indirectly through the manufactures web site. 132 Options are: 134 o The user connects a PC to a physical port on network device and 135 gets access to devices's user interface. 137 o Using a smartphone app which is automatically downloaded when 138 scanning a QR code on the device. This will then allow the user 139 to connect to the device on an SSID which is dynamically created 140 based on the device serial number. The device will only allow 141 connections from smartphones using the manufactures app. 143 2.4. The Registrar 145 One autonomic device in the homenet takes on a registrar function, 146 which contains a registration autority and a certificate authority. 147 In a homenet, the simplest method should be chosen: The first device 148 the user connects to automatically takes on these functions. 149 Therefore, the function of the registrar is essentially hidden to the 150 user. 152 Technically, the registrar creates a trust anchor for the homenet 153 domain, and subsequently acts as a certification authority, granting 154 domain certificates to other devices. 156 2.5. Autonomic Adjacency Discovery 158 Every autonomic device discovers neighbouring autonomic nodes through 159 an autonomic secure neighbour discovery protocol. This could be 160 implemented for example through IPv6 secure neighbour discovery, 161 using a to-be-assigned well-known multicast address indicating "all 162 autonomic nodes on this subnet". 164 The identity exchanged in this protocol is either a domain 165 certificate, for devices that have already joined the domain, or a 166 vendor certificate (802.1AR) [IDevID] if available, or an insecure 167 device identity (serial number). 169 If two autonomic homenet devices use the same trust anchor they can 170 verify each other's certificate thus establishing that the peer is a 171 member of the same local domain. 173 An autonomic device signs its neighbour discovery packets. If it has 174 a domain certificate from the domain registrar, it uses that. If 175 not, it uses either a vendor certificate (e.g., an IEEE 802.1AR 176 [IDevID] credential) or a self-signed certificate. 178 2.6. Validating a new device's identity 180 If one autonomic homenet device is member of the homenet domain, and 181 its neighbour is not, the device without domain credentials requests 182 to join the first domain it is presented with. The device must only 183 join a homenet domain when it is in the factory default configuration 184 (e.g. it is not currently a member of a homenet). The domain device 185 proxies the request to the registrar, including the device 186 credentials of the device without domain credentials. The registrar 187 informs the user about the new device, using the user interface, for 188 example the smart phone. 190 The user decides to accept the device based on various criteria: 192 o Allow any device to join within a specific time period. 194 o Allow only devices with specific serial numbers to join. These 195 can either be entered manually into the registrar or by scanning a 196 QR code using the manufactures autonomic app on a smartphone. 198 o Allow only devices to join on a specific proxy device, or 199 interface on that proxy. 201 o If the device has a vendor certificate (e.g., an IEEE 802.1AR 202 [IDevID] credential), the device can be validated using a Cloud 203 service from the vendor. 205 If a device is accepted into the domain, it is then invited to 206 request a domain certificate through a certificate enrolment process. 208 A device MAY require an invitation to be signed by the manufacturer, 209 stating that it has been claimed by the user before it decides to 210 join the domain. 212 The result is a common trust anchor and device certificates for all 213 autonomic devices in a domain. These certificates can subsequently 214 be used to determine the boundaries of the homenet, to authenticate 215 other domain nodes, and to autonomically enable services on the 216 homenet. 218 Section 4 of [I-D.pritikin-bootstrapping-keyinfrastructures] explains 219 the functional overview of the solution, including all the functional 220 elements and additional options, for example how to securely claim a 221 device. The homenet case can be significantly more restrictive, for 222 example work with serial numbers only, or using physical methods, 223 such as pressing a button to pair a device, or typing a key displayed 224 on an LED display into the registrar. 226 2.7. Services 228 As the devices have a common trust anchor, device identity can be 229 securely established, making it possible to automatically deploy 230 services across the domain in a secure manner. 232 Examples of services are device management, routing authentication, 233 and service discovery. 235 2.8. Network boundaries 237 When a device has joined the domain, it can validate the domain 238 membership of other devices. This makes it possible to create trust 239 boundaries where domain members have higher level of trusted than 240 external devices. Using the autonomic User Interface, specific 241 devices can be grouped into to sub domains and specific trust levels 242 can be implemented between those. 244 3. Security Considerations 246 The approach as outlined in this document is open to a number of 247 attacks at bootstrap time. For example, a malicious device could 248 pretend to be an expected device and assume its role. 250 There are counter-measures against these attacks, with various 251 security levels, and corresponding various ease of use. The options 252 are (in order of increased security): 254 o Only allow new devices to join in a specific time period. 256 o Only allow specific devices to join by matching their serial 257 numbers. 259 o Validating the vendor certificate on new devices using the vendors 260 Cloud portal. 262 In order to support a variety of use cases, devices can be claimed by 263 a registrar without proving possession of the device in question. 264 This would result in a nonceless, and thus always valid, claim. 265 Future registrars are recommended to take the audit history of a 266 device into account when deciding to join the device into their 267 network. 269 4. Informative References 271 [I-D.behringer-autonomic-network-framework] 272 Behringer, M., Pritikin, M., Bjarnason, S., and A. Clemm, 273 "A Framework for Autonomic Networking", draft-behringer- 274 autonomic-network-framework-01 (work in progress), October 275 2013. 277 [I-D.ietf-homenet-arch] 278 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 279 "IPv6 Home Networking Architecture Principles", draft- 280 ietf-homenet-arch-11 (work in progress), October 2013. 282 [I-D.pritikin-bootstrapping-keyinfrastructures] 283 Pritikin, M., Behringer, M., and S. Bjarnason, 284 "Bootstrapping Key Infrastructures", draft-pritikin- 285 bootstrapping-keyinfrastructures-00 (work in progress), 286 January 2014. 288 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 289 December 2009, . 292 Authors' Addresses 294 Michael H. Behringer 295 Cisco 297 Email: mbehring@cisco.com 299 Max Pritikin 300 Cisco 302 Email: pritikin@cisco.com 304 Steinthor Bjarnason 305 Cisco 307 Email: sbjarnas@cisco.com