idnits 2.17.1 draft-behringer-homenet-trust-bootstrap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 105: '...ith. The device MUST only join a home...' RFC 2119 keyword, line 114: '... MAY provide supplemental criteria f...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4209 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-04 Summary: 3 errors (**), 0 flaws (~~), 2 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: April 18, 2013 Cisco 6 October 15, 2012 8 Bootstrapping Trust on a Homenet 9 draft-behringer-homenet-trust-bootstrap-00.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 enroll 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 April 18, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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 1. Problem Statement 55 [I-D.ietf-homenet-arch] states that "It should be possible to 56 automatically perform border discovery for the different borders." 57 Simple approaches, such as terminating a homenet on a particular 58 interface type do not easily allow for devices from different 59 administrative realms to be locally connected. 60 [I-D.ietf-homenet-arch] states further that "It is important that 61 self-configuration with 'unintended' devices is avoided. Methods are 62 needed for devices to know whether they are intended to be part of 63 the same homenet site or not." 65 An approach is needed that allows to establish trust inside a homenet 66 according to a policy set by the admin of the homenet. 68 2. Approach 70 An autonomic device can be a router, switch, PC, smartphone, or any 71 other device, independent of its role in the network, which has the 72 autonomic functionality mentioned below . A homenet consists of 73 autonomic devices and non-autonomic devices. This approach requires 74 at least one autonomic networking device, such as a router or switch. 76 One autonomic device in the homenet takes on a registrar function. 77 This could be manually enabled, for example on a smartphone autonomic 78 app; in the absence of a registrar function, a device can also auto- 79 select itself to take on this function, using some detection 80 mechanism to resolve potential conflicts. 82 The registrar creates a trust anchor for the homenet, and 83 subsequently acts as a registration authority, granting domain 84 certificates to other devices. 86 Every autonomic device discovers neighbouring autonomic nodes through 87 an autonomic neighbour discovery protocol. This could be implemented 88 for example through IPv6 neighbour discovery, using a to-be-assigned 89 well-known multicast address indicating "all autonomic nodes on this 90 subnet". 92 An autonomic device signs its neighbour discovery packets. If it has 93 a domain certificate from the domain registrar, it uses that. If 94 not, it uses either a vendor certificate (e.g., an IEEE 802.1AR 96 [IDevID] credential) or a self-signed certificate. 98 If two autonomic homenet devices use the same trust anchor they can 99 verify each other's certificate thus establishing that the peer is a 100 member of the same local domain. 102 If one autonomic homenet device is member of a domain, and its 103 neighbour is not, it invites the neighbour to join the domain. The 104 device without domain credentials requests to join the first domain 105 it is presented with. The device MUST only join a homenet domain 106 when it is in the factory default configuration (e.g. it is not 107 currently a member of a homenet). The domain device proxies the 108 request to the registrar, including the device credentials of the 109 device without domain credentials. 111 The registrar accepts or declines a request to join the domain, based 112 on the credentials presented and other policy defined criteria such 113 as proxy identity. Any authorized device currently within the domain 114 MAY provide supplemental criteria for help making this decision. A 115 smartphone autonomic application would be an ideal domain member to 116 provide user interface functionality for the obtaining of 117 supplemental criteria from end users. 119 If a device is accepted into the domain, it is invited to request a 120 domain certificate through a certificate enrollment process. 122 The result is a common trust anchor and device certificates for all 123 autonomic devices in a domain. These certificates can subsequently 124 be used to determine the boundaries of the homenet, to authenticate 125 other domain nodes, and to autonomically enable services on the 126 homenet. 128 3. Security Considerations 130 The approach as outlined in this document is open to a number of 131 attacks at bootstrap time. For example, a malicious device could 132 pretend to be an expected device and assume its role. This is 133 however no different to current security models in home networks. 135 4. Informative References 137 [I-D.ietf-homenet-arch] 138 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 139 "Home Networking Architecture for IPv6", 140 draft-ietf-homenet-arch-04 (work in progress), July 2012. 142 [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 143 December 2009, . 146 Authors' Addresses 148 Michael H. Behringer 149 Cisco 151 Email: mbehring@cisco.com 153 Max Pritikin 154 Cisco 156 Email: pritikin@cisco.com 158 Steinthor Bjarnason 159 Cisco 161 Email: sbjarnas@cisco.com