idnits 2.17.1 draft-barth-homenet-hncp-security-trust-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2014) is 3454 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-01 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet Working Group S. Barth 3 Internet-Draft 4 Intended status: Standards Track October 14, 2014 5 Expires: April 17, 2015 7 HNCP - Security and Trust Management 8 draft-barth-homenet-hncp-security-trust-01 10 Abstract 12 This document describes threats and a security and trust bootstrap 13 mechanism for the Home Networking Control Protocol (HNCP). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 17, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Requirements language . . . . . . . . . . . . . . . . . . . . 2 51 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Border Determination . . . . . . . . . . . . . . . . . . . . 3 53 5. HNCP Payload Security . . . . . . . . . . . . . . . . . . . . 4 54 5.1. Isolated router-to-router links . . . . . . . . . . . . . 4 55 5.2. Authentication and Encryption of HNCP-traffic . . . . . . 4 56 6. Trust Management for Authentication and Encryption . . . . . 4 57 6.1. Pre-shared secret based trust . . . . . . . . . . . . . . 4 58 6.2. PKI-based trust . . . . . . . . . . . . . . . . . . . . . 5 59 6.3. Certificate-based trust consensus . . . . . . . . . . . . 5 60 6.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 5 61 6.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 6 62 6.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 6 63 6.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 7 64 7. Other homenet protocols . . . . . . . . . . . . . . . . . . . 8 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8.1. Revocation of Trust . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative references . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative references . . . . . . . . . . . . . . . . . 10 71 Appendix A. Draft source . . . . . . . . . . . . . . . . . . . . 11 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 HNCP is designed to make home networks self-configuring, requiring as 78 little user intervention as possible. However this zero- 79 configuration goal usually conflicts with security goals and 80 introduces a number of threats. 82 This document describes imminent threats and different security and 83 trust management mechanisms to mitigate them. 85 2. Requirements language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 3. Scope 93 This draft is based on HNCP as described in [I-D.ietf-homenet-hncp] 94 and the additional threats it introduces. Many of these already 95 exist in a similar form in current single-link home networks due to 96 the usually unauthenticated use of protocols like NDP [RFC4861] or 97 DHCPv6 [RFC3315]. This document intentionally does not cover these 98 and other Homenet-related threats not explicitly introduced by HNCP. 100 HNCP is a generic state synchronization mechanism carrying 101 information with varying threat potential. This draft will mainly 102 consider the currently specified payloads: 104 Network topology information such as homenet routers and their 105 adjacent links 107 Address assignment information such as delegated and assigned 108 prefixes for individual links 110 Naming and service discovery information such as auto-generated or 111 customized names for individual links and routers 113 IGP capabilities and preferences of individual routers 115 4. Border Determination 117 In general an HNCP-router determines the internal or external state 118 on a per-link scale and creates a firewall-perimeter and allows HNCP- 119 and IGP-traffic based on the individual results. These are provided 120 by either automatic border discovery or a predefined configuration 121 indicated by e.g. the link-type, a physically dedicated (labeled) 122 port or the administrator. 124 Threats concerning automatic border discovery cannot be mitigated by 125 encrypting or authenticating HNCP-traffic itself since external 126 routers do not participate in the protocol and often cannot be 127 authenticated by other means. These threats include propagation of 128 forged uplinks in the homenet in order to e.g. redirect traffic 129 destined to external locations and forged internality by external 130 routers to e.g. circumvent the perimeter firewall. 132 It is therefore imperative to either secure individual links on the 133 physical or link-layer or preconfigure the adjacent interfaces of 134 HNCP-routers to an adequate fixed-category in order to secure the 135 homenet border. Depending on the security of the external link 136 eavesdropping, man-in-the-middle and similar attacks on external 137 traffic can still happen between a homenet border-router and the ISP, 138 however these cannot be mitigated from inside the homenet. 140 5. HNCP Payload Security 142 Once the homenet border has been established there are several ways 143 to secure HNCP against internal threats like manipulation or 144 eavesdropping by compromised devices on a link which is enabled for 145 HNCP-traffic. If left unsecured attackers may cause arbitrary 146 spoofing or denial of service attacks on HNCP-services such as 147 address assignment or service discovery. Furthermore they may 148 manipulate routing or external connection information in order to 149 perform eavesdropping or man-in-the-middle attacks on outbound 150 traffic. The following security mechanisms are defined to mitigate 151 these threats: 153 5.1. Isolated router-to-router links 155 Given that links containing HNCP routers can be sufficiently secured 156 or isolated it is possible to run HNCP in a secure manner without 157 using any form of authentication or encryption. Detailed interface 158 categories like "leaf" or "guest" can be used to integrate not fully 159 trusted devices to various degrees into the homenet by not exposing 160 them to HNCP and IGP traffic or by using firewall rules to prevent 161 them from reaching homenet-internal resources. 163 5.2. Authentication and Encryption of HNCP-traffic 165 The end-to-end mechanism DTLS [RFC6347] is used to authenticate and 166 encrypt all HNCP unicast-traffic in order to protect its potentially 167 sensitive payload. Methods for establishing and managing trust for 168 this mechanism are described in the following section. 170 HNCP also uses multicast signaling to announce changes of HNCP 171 information but will not send any actual payload over this channel. 172 An attacker may learn hash-values of HNCP-information and may be able 173 to trigger unicast synchronization attempts between routers on the 174 local link this way. An HNCP-router should therefore limit its 175 unicast synchronizations attempts to avoid a multicast-induced 176 denial-of-service. 178 6. Trust Management for Authentication and Encryption 180 6.1. Pre-shared secret based trust 182 A PSK-based trust model is a simple security management mechanism 183 that allows an administrator to deploy devices to an existing network 184 by configuring them with a pre-defined key, similar to the 185 configuration of an administrator password or WPA-key. Although 186 limited in nature it is useful to provide a user-friendly security 187 mechanism for smaller homenets. 189 6.2. PKI-based trust 191 A PKI-based trust-model enables more advanced management capabilities 192 at the cost of increased complexity and bootstrapping effort. It 193 however allows trust to be managed in a centralized manner and is 194 therefore useful for larger networks with a need for an authoritative 195 trust management. 197 6.3. Certificate-based trust consensus 199 The certificate-based consensus model is designed to be a compromise 200 between trust management effort and flexibility. It is based on 201 X.509-certificates and allows each connected device to give a verdict 202 on any other certificate and a consensus is found to determine 203 whether a device using this certificate or any certificate signed by 204 it is to be trusted. 206 6.3.1. Trust Verdicts 208 Trust Verdicts are statements of HNCP-devices about the 209 trustworthiness of X.509-certificates. There are 5 possible verdicts 210 in order of ascending priority: 212 0 Neutral: no verdict exists but the homenet should find one 214 1 Cached Trust: the last known effective verdict was Configured or 215 Cached Trust 217 2 Cached Distrust: the last known effective verdict was Configured 218 or Cached Distrust 220 3 Configured Trust: trustworthy based upon an external ceremony or 221 configuration 223 4 Configured Distrust: not trustworthy based upon an external 224 ceremony or configuration 226 Verdicts are differentiated in 3 groups: 228 Configured verdicts are used to announce explicit verdicts a 229 device has based on any external trust bootstrap or predefined 230 relation a device has formed with a given certificate. 232 Cached verdicts are used to retain the last known trust state in 233 case all devices having configured verdicts about a given 234 certificate have been disconnected or turned off. 236 The Neutral verdict is used to announce a new device intending to 237 join the homenet so a final verdict for it can be found. 239 The current effective trust verdict for any certificate is defined as 240 the one with the highest priority from all verdicts announced for 241 said certificate at the time. A device MUST be trusted for 242 participating in the homenet if and only if the current effective 243 verdict for its own certificate or any one in its certificate 244 hierarchy is (Cached or Configured) Trust and none of the 245 certificates in its hierarchy have an effective verdict of (Cached or 246 Configured) Distrust. In case a device has a configured verdict 247 which is different from the current effective verdict for a 248 certificate the current effective verdict takes precedence in 249 deciding trustworthiness however the device still retains its 250 configured verdict in its configuration. 252 6.3.2. Trust Cache 254 Each device maintains a trust cache containing the current effective 255 trust verdicts for all certificates currently announced in the 256 homenet. This cache is used as a backup of the last known state in 257 case there is no device announcing an configured verdict for a known 258 certificate. It SHOULD be saved to a non-volatile memory at 259 reasonable time intervals to survive a reboot or power outage. 261 Every time a device (re)joins the homenet or detects the change of an 262 effective trust verdict for any certificate it will synchronize its 263 cache and store the new effective verdict overwriting any previously 264 cached verdicts. Configured verdicts are stored in the cache as 265 their respective cached counterparts, Neutral verdicts are never 266 stored. 268 6.3.3. Announcement of Verdicts 270 A device always announces any configured trust verdicts it has 271 established by itself. It also announces cached trust verdicts it 272 has stored in its trust cache if one of the following conditions 273 applies: 275 The stored verdict is Cached Trust and the current effective 276 verdict is Neutral or does not exist. 278 The stored verdict is Cached Distrust and the current effective 279 verdict is Cached Trust. 281 A device rechecks these conditions whenever it detects changes of 282 announced trust verdicts anywhere in the network. 284 Upon encountering a device with a hierarchy of certificates for which 285 there is no effective verdict a router announces Neutral verdicts for 286 all certificates found in the hierarchy until an effective verdict 287 different from Neutral can be found for any of the certificates or a 288 reasonable amount of time (10 minutes is suggested) with no reaction 289 and no further connection attempts has passed. Such verdicts SHOULD 290 also be limited in rate and number to prevent denial-of-service 291 attacks. 293 Trust verdicts are announced using Trust-Verdict TLVs: 295 0 1 2 3 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type: Trust-Verdict (20) | Length: 41-104 | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Verdict | (reserved) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 | | 304 | | 305 | SHA-256 Fingerprint | 306 | | 307 | | 308 | | 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Common Name | 313 Verdict represents the numerical index of the verdict. 315 (reserved) is reserved for future additions and MUST be set to 0 316 when creating TLVs and ignored when parsing them. 318 SHA-256 [RFC6234] Fingerprint contains the fingerprint of the 319 certificate. 321 Common Name contains the variable-length (1-64 bytes) common name 322 of the certificate. 324 6.3.4. Bootstrap Ceremonies 326 The following methods are defined to establish trust relationships 327 between HNCP-routers and router certificates. Trust establishment is 328 a two-way process in which the existing homenet must trust the newly 329 added device and the newly added device must trust at least one of 330 its neighboring routers. It is therefore necessary that both the 331 newly added device and an already trusted device perform such a 332 ceremony to successfully introduce a device into a homenet. In all 333 cases an administrator MUST be provided with external means to 334 identify the device belonging to a certificate based on its 335 fingerprint and a meaningful common name. 337 6.3.4.1. Trust by Identification 339 A device implementing certificate-based trust MUST provide an 340 interface to retrieve the current set of effective trust verdicts, 341 fingerprints and names of all certificates currently known and set 342 configured trust verdicts to be announced. Alternatively it MAY 343 provide a companion HNCP-device or application with these 344 capabilities with which it has a pre-established trust relationship. 346 6.3.4.2. Preconfigured Trust 348 A device MAY be preconfigured to trust a certain set of device or CA 349 certificates. However such trust relationships MUST NOT result in 350 unwanted or unrelated trust for devices not intended to be run inside 351 the same network (e.g. all other devices of that manufacturer). 353 6.3.4.3. Trust on Button Press 355 A device MAY provide a physical or virtual interface to put one or 356 more of its internal network interfaces temporarily into a mode in 357 which it trusts the certificate of the first HNCP-device it can 358 successfully establish a connection with. 360 6.3.4.4. Trust on First Use 362 A device which is not associated with any other homenet-router MAY 363 trust the certificate of the first HNCP-device it can successfully 364 establish a connection with. This method MUST NOT be used when the 365 device has already associated with any other HNCP-router. 367 7. Other homenet protocols 369 An IGP is usually run alongside HNCP in a homenet therefore the 370 individual security aspects of the respective protocols must be 371 considered. It can however be summarized that current candidate 372 protocols (namely Babel, OSPFv3, RIP and IS-IS) provide - to a 373 certain extent - similar security mechanisms. All mentioned 374 protocols do not support encryption and only support authentication 375 based on pre-shared keys natively. This influences the effectiveness 376 of any encryption-based security mechanism deployed by HNCP as 377 homenet routing information is usually not confidential. 379 As a PSK is required to authenticate IGP-traffic and potential other 380 protocols, HNCP is used to create and manage it. The key length is 381 defined to be 32 Bytes to be reasonably secure. The following rules 382 determine how a key is managed and used: 384 If no Managed-PSK-TLV is currently being announced, an HNCP-router 385 creates one with a random key and adds it to its node-data. 387 In case multiple routers announce such a TLV at the same time, all 388 but the one with the highest router-ID stop advertising it and 389 adopt the remaining one. 391 The router currently advertising the Managed-PSK-TLV must generate 392 and advertise a new random one whenever the HNCP security 393 mechanism stops trusting one or more trusted devices - i.e. HNCP 394 is secured with a PSK itself and it was changed or a certificate 395 has changed from trusted to distrusted. 397 0 1 2 3 398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type: Managed-PSK (21) | Length: 36 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 | | 404 | | 405 | Random PSK | 406 | | 407 | | 408 | | 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 PSKs for individual protocols are derived from the random PSK through 413 the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol 414 HMAC-key in ASCII-format. The following HMAC-keys are currently 415 defined to derive PSKs for the respective protocols: 417 "ROUTING": to be used for IGPs. If a Random PSK exists then the 418 derived PSK MUST be used to secure the chosen IGP. 420 8. Security Considerations 422 8.1. Revocation of Trust 424 Revoking trust in a protocol intended for bootstrapping is non- 425 trivial, since neither an accurate clock nor network connectivity to 426 retrieve authenticated revocation information can be assumed in all 427 situations. 429 The Certificate-based trust consensus mechanism defined in this 430 document allows for a consenting revocation, however in case of a 431 compromised device the trust cache may be poisoned before the actual 432 revocation happens allowing the distrusted device to rejoin the 433 network using a different identity. Stopping such an attack might 434 require physical intervention and flushing of the trust caches. 435 However such an attack is often times more easily detectable than 436 threats discussed earlier in this document such as a silent 437 manipulation of routing information and related man-in-the-middle 438 attacks. 440 9. IANA Considerations 442 IANA should add HNCP TLV types with the following contents: 444 20: Trust-Verdict 446 21: Managed-PSK 448 10. References 450 10.1. Normative references 452 [I-D.ietf-homenet-hncp] 453 Stenberg, M. and S. Barth, "Home Networking Control 454 Protocol", draft-ietf-homenet-hncp-01 (work in progress), 455 June 2014. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 461 Security Version 1.2", RFC 6347, January 2012. 463 10.2. Informative references 465 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 466 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 468 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 469 and M. Carney, "Dynamic Host Configuration Protocol for 470 IPv6 (DHCPv6)", RFC 3315, July 2003. 472 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 473 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 474 September 2007. 476 Appendix A. Draft source 478 As usual, this draft is available at https://github.com/fingon/ietf- 479 drafts/ in source format (with nice Makefile too). Feel free to send 480 comments and/or pull requests if and when you have changes to it! 482 Appendix B. Acknowledgements 484 Thanks to Markus Stenberg, Pierre Pfister and Mark Baugher for their 485 contributions to the draft and Xavier Bonnetain for ideas on a web of 486 trust and PSK-management in I-D.bonnetain-hncp-security-00. 488 Author's Address 490 Steven Barth 492 Email: cyrus@openwrt.org