Homenet Working Group S. Barth Internet-Draft Intended status: Standards Track October 14, 2014 Expires: April 17, 2015 HNCP - Security and Trust Management draft-barth-homenet-hncp-security-trust-01 Abstract This document describes threats and a security and trust bootstrap mechanism for the Home Networking Control Protocol (HNCP). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 17, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Barth Expires April 17, 2015 [Page 1]
Internet-Draft HNCP - Security and Trust Management October 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements language . . . . . . . . . . . . . . . . . . . . 2 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Border Determination . . . . . . . . . . . . . . . . . . . . 3 5. HNCP Payload Security . . . . . . . . . . . . . . . . . . . . 4 5.1. Isolated router-to-router links . . . . . . . . . . . . . 4 5.2. Authentication and Encryption of HNCP-traffic . . . . . . 4 6. Trust Management for Authentication and Encryption . . . . . 4 6.1. Pre-shared secret based trust . . . . . . . . . . . . . . 4 6.2. PKI-based trust . . . . . . . . . . . . . . . . . . . . . 5 6.3. Certificate-based trust consensus . . . . . . . . . . . . 5 6.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 5 6.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 6 6.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 6 6.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 7 7. Other homenet protocols . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.1. Revocation of Trust . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative references . . . . . . . . . . . . . . . . . . 10 10.2. Informative references . . . . . . . . . . . . . . . . . 10 Appendix A. Draft source . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction HNCP is designed to make home networks self-configuring, requiring as little user intervention as possible. However this zero- configuration goal usually conflicts with security goals and introduces a number of threats. This document describes imminent threats and different security and trust management mechanisms to mitigate them. 2. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Barth Expires April 17, 2015 [Page 2]
Internet-Draft HNCP - Security and Trust Management October 2014 3. Scope This draft is based on HNCP as described in [I-D.ietf-homenet-hncp] and the additional threats it introduces. Many of these already exist in a similar form in current single-link home networks due to the usually unauthenticated use of protocols like NDP [RFC4861] or DHCPv6 [RFC3315]. This document intentionally does not cover these and other Homenet-related threats not explicitly introduced by HNCP. HNCP is a generic state synchronization mechanism carrying information with varying threat potential. This draft will mainly consider the currently specified payloads: Network topology information such as homenet routers and their adjacent links Address assignment information such as delegated and assigned prefixes for individual links Naming and service discovery information such as auto-generated or customized names for individual links and routers IGP capabilities and preferences of individual routers 4. Border Determination In general an HNCP-router determines the internal or external state on a per-link scale and creates a firewall-perimeter and allows HNCP- and IGP-traffic based on the individual results. These are provided by either automatic border discovery or a predefined configuration indicated by e.g. the link-type, a physically dedicated (labeled) port or the administrator. Threats concerning automatic border discovery cannot be mitigated by encrypting or authenticating HNCP-traffic itself since external routers do not participate in the protocol and often cannot be authenticated by other means. These threats include propagation of forged uplinks in the homenet in order to e.g. redirect traffic destined to external locations and forged internality by external routers to e.g. circumvent the perimeter firewall. It is therefore imperative to either secure individual links on the physical or link-layer or preconfigure the adjacent interfaces of HNCP-routers to an adequate fixed-category in order to secure the homenet border. Depending on the security of the external link eavesdropping, man-in-the-middle and similar attacks on external traffic can still happen between a homenet border-router and the ISP, however these cannot be mitigated from inside the homenet. Barth Expires April 17, 2015 [Page 3]
Internet-Draft HNCP - Security and Trust Management October 2014 5. HNCP Payload Security Once the homenet border has been established there are several ways to secure HNCP against internal threats like manipulation or eavesdropping by compromised devices on a link which is enabled for HNCP-traffic. If left unsecured attackers may cause arbitrary spoofing or denial of service attacks on HNCP-services such as address assignment or service discovery. Furthermore they may manipulate routing or external connection information in order to perform eavesdropping or man-in-the-middle attacks on outbound traffic. The following security mechanisms are defined to mitigate these threats: 5.1. Isolated router-to-router links Given that links containing HNCP routers can be sufficiently secured or isolated it is possible to run HNCP in a secure manner without using any form of authentication or encryption. Detailed interface categories like "leaf" or "guest" can be used to integrate not fully trusted devices to various degrees into the homenet by not exposing them to HNCP and IGP traffic or by using firewall rules to prevent them from reaching homenet-internal resources. 5.2. Authentication and Encryption of HNCP-traffic The end-to-end mechanism DTLS [RFC6347] is used to authenticate and encrypt all HNCP unicast-traffic in order to protect its potentially sensitive payload. Methods for establishing and managing trust for this mechanism are described in the following section. HNCP also uses multicast signaling to announce changes of HNCP information but will not send any actual payload over this channel. An attacker may learn hash-values of HNCP-information and may be able to trigger unicast synchronization attempts between routers on the local link this way. An HNCP-router should therefore limit its unicast synchronizations attempts to avoid a multicast-induced denial-of-service. 6. Trust Management for Authentication and Encryption 6.1. Pre-shared secret based trust A PSK-based trust model is a simple security management mechanism that allows an administrator to deploy devices to an existing network by configuring them with a pre-defined key, similar to the configuration of an administrator password or WPA-key. Although limited in nature it is useful to provide a user-friendly security mechanism for smaller homenets. Barth Expires April 17, 2015 [Page 4]
Internet-Draft HNCP - Security and Trust Management October 2014 6.2. PKI-based trust A PKI-based trust-model enables more advanced management capabilities at the cost of increased complexity and bootstrapping effort. It however allows trust to be managed in a centralized manner and is therefore useful for larger networks with a need for an authoritative trust management. 6.3. Certificate-based trust consensus The certificate-based consensus model is designed to be a compromise between trust management effort and flexibility. It is based on X.509-certificates and allows each connected device to give a verdict on any other certificate and a consensus is found to determine whether a device using this certificate or any certificate signed by it is to be trusted. 6.3.1. Trust Verdicts Trust Verdicts are statements of HNCP-devices about the trustworthiness of X.509-certificates. There are 5 possible verdicts in order of ascending priority: 0 Neutral: no verdict exists but the homenet should find one 1 Cached Trust: the last known effective verdict was Configured or Cached Trust 2 Cached Distrust: the last known effective verdict was Configured or Cached Distrust 3 Configured Trust: trustworthy based upon an external ceremony or configuration 4 Configured Distrust: not trustworthy based upon an external ceremony or configuration Verdicts are differentiated in 3 groups: Configured verdicts are used to announce explicit verdicts a device has based on any external trust bootstrap or predefined relation a device has formed with a given certificate. Cached verdicts are used to retain the last known trust state in case all devices having configured verdicts about a given certificate have been disconnected or turned off. Barth Expires April 17, 2015 [Page 5]
Internet-Draft HNCP - Security and Trust Management October 2014 The Neutral verdict is used to announce a new device intending to join the homenet so a final verdict for it can be found. The current effective trust verdict for any certificate is defined as the one with the highest priority from all verdicts announced for said certificate at the time. A device MUST be trusted for participating in the homenet if and only if the current effective verdict for its own certificate or any one in its certificate hierarchy is (Cached or Configured) Trust and none of the certificates in its hierarchy have an effective verdict of (Cached or Configured) Distrust. In case a device has a configured verdict which is different from the current effective verdict for a certificate the current effective verdict takes precedence in deciding trustworthiness however the device still retains its configured verdict in its configuration. 6.3.2. Trust Cache Each device maintains a trust cache containing the current effective trust verdicts for all certificates currently announced in the homenet. This cache is used as a backup of the last known state in case there is no device announcing an configured verdict for a known certificate. It SHOULD be saved to a non-volatile memory at reasonable time intervals to survive a reboot or power outage. Every time a device (re)joins the homenet or detects the change of an effective trust verdict for any certificate it will synchronize its cache and store the new effective verdict overwriting any previously cached verdicts. Configured verdicts are stored in the cache as their respective cached counterparts, Neutral verdicts are never stored. 6.3.3. Announcement of Verdicts A device always announces any configured trust verdicts it has established by itself. It also announces cached trust verdicts it has stored in its trust cache if one of the following conditions applies: The stored verdict is Cached Trust and the current effective verdict is Neutral or does not exist. The stored verdict is Cached Distrust and the current effective verdict is Cached Trust. A device rechecks these conditions whenever it detects changes of announced trust verdicts anywhere in the network. Barth Expires April 17, 2015 [Page 6]
Internet-Draft HNCP - Security and Trust Management October 2014 Upon encountering a device with a hierarchy of certificates for which there is no effective verdict a router announces Neutral verdicts for all certificates found in the hierarchy until an effective verdict different from Neutral can be found for any of the certificates or a reasonable amount of time (10 minutes is suggested) with no reaction and no further connection attempts has passed. Such verdicts SHOULD also be limited in rate and number to prevent denial-of-service attacks. Trust verdicts are announced using Trust-Verdict TLVs: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Trust-Verdict (20) | Length: 41-104 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verdict | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | SHA-256 Fingerprint | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Name | Verdict represents the numerical index of the verdict. (reserved) is reserved for future additions and MUST be set to 0 when creating TLVs and ignored when parsing them. SHA-256 [RFC6234] Fingerprint contains the fingerprint of the certificate. Common Name contains the variable-length (1-64 bytes) common name of the certificate. 6.3.4. Bootstrap Ceremonies The following methods are defined to establish trust relationships between HNCP-routers and router certificates. Trust establishment is a two-way process in which the existing homenet must trust the newly added device and the newly added device must trust at least one of its neighboring routers. It is therefore necessary that both the newly added device and an already trusted device perform such a Barth Expires April 17, 2015 [Page 7]
Internet-Draft HNCP - Security and Trust Management October 2014 ceremony to successfully introduce a device into a homenet. In all cases an administrator MUST be provided with external means to identify the device belonging to a certificate based on its fingerprint and a meaningful common name. 6.3.4.1. Trust by Identification A device implementing certificate-based trust MUST provide an interface to retrieve the current set of effective trust verdicts, fingerprints and names of all certificates currently known and set configured trust verdicts to be announced. Alternatively it MAY provide a companion HNCP-device or application with these capabilities with which it has a pre-established trust relationship. 6.3.4.2. Preconfigured Trust A device MAY be preconfigured to trust a certain set of device or CA certificates. However such trust relationships MUST NOT result in unwanted or unrelated trust for devices not intended to be run inside the same network (e.g. all other devices of that manufacturer). 6.3.4.3. Trust on Button Press A device MAY provide a physical or virtual interface to put one or more of its internal network interfaces temporarily into a mode in which it trusts the certificate of the first HNCP-device it can successfully establish a connection with. 6.3.4.4. Trust on First Use A device which is not associated with any other homenet-router MAY trust the certificate of the first HNCP-device it can successfully establish a connection with. This method MUST NOT be used when the device has already associated with any other HNCP-router. 7. Other homenet protocols An IGP is usually run alongside HNCP in a homenet therefore the individual security aspects of the respective protocols must be considered. It can however be summarized that current candidate protocols (namely Babel, OSPFv3, RIP and IS-IS) provide - to a certain extent - similar security mechanisms. All mentioned protocols do not support encryption and only support authentication based on pre-shared keys natively. This influences the effectiveness of any encryption-based security mechanism deployed by HNCP as homenet routing information is usually not confidential. Barth Expires April 17, 2015 [Page 8]
Internet-Draft HNCP - Security and Trust Management October 2014 As a PSK is required to authenticate IGP-traffic and potential other protocols, HNCP is used to create and manage it. The key length is defined to be 32 Bytes to be reasonably secure. The following rules determine how a key is managed and used: If no Managed-PSK-TLV is currently being announced, an HNCP-router creates one with a random key and adds it to its node-data. In case multiple routers announce such a TLV at the same time, all but the one with the highest router-ID stop advertising it and adopt the remaining one. The router currently advertising the Managed-PSK-TLV must generate and advertise a new random one whenever the HNCP security mechanism stops trusting one or more trusted devices - i.e. HNCP is secured with a PSK itself and it was changed or a certificate has changed from trusted to distrusted. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Managed-PSK (21) | Length: 36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Random PSK | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PSKs for individual protocols are derived from the random PSK through the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol HMAC-key in ASCII-format. The following HMAC-keys are currently defined to derive PSKs for the respective protocols: "ROUTING": to be used for IGPs. If a Random PSK exists then the derived PSK MUST be used to secure the chosen IGP. 8. Security Considerations 8.1. Revocation of Trust Revoking trust in a protocol intended for bootstrapping is non- trivial, since neither an accurate clock nor network connectivity to Barth Expires April 17, 2015 [Page 9]
Internet-Draft HNCP - Security and Trust Management October 2014 retrieve authenticated revocation information can be assumed in all situations. The Certificate-based trust consensus mechanism defined in this document allows for a consenting revocation, however in case of a compromised device the trust cache may be poisoned before the actual revocation happens allowing the distrusted device to rejoin the network using a different identity. Stopping such an attack might require physical intervention and flushing of the trust caches. However such an attack is often times more easily detectable than threats discussed earlier in this document such as a silent manipulation of routing information and related man-in-the-middle attacks. 9. IANA Considerations IANA should add HNCP TLV types with the following contents: 20: Trust-Verdict 21: Managed-PSK 10. References 10.1. Normative references [I-D.ietf-homenet-hncp] Stenberg, M. and S. Barth, "Home Networking Control Protocol", draft-ietf-homenet-hncp-01 (work in progress), June 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 10.2. Informative references [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Barth Expires April 17, 2015 [Page 10]
Internet-Draft HNCP - Security and Trust Management October 2014 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Appendix A. Draft source As usual, this draft is available at https://github.com/fingon/ietf- drafts/ in source format (with nice Makefile too). Feel free to send comments and/or pull requests if and when you have changes to it! Appendix B. Acknowledgements Thanks to Markus Stenberg, Pierre Pfister and Mark Baugher for their contributions to the draft and Xavier Bonnetain for ideas on a web of trust and PSK-management in I-D.bonnetain-hncp-security-00. Author's Address Steven Barth Email: cyrus@openwrt.org Barth Expires April 17, 2015 [Page 11]