| 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
This document describes threats and a security and trust bootstrap mechanism for the Home Networking Control Protocol (HNCP).
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 (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.
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.
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].
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:
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.
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:
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.
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.
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.
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.
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.
Trust Verdicts are statements of HNCP-devices about the trustworthiness of X.509-certificates. There are 5 possible verdicts in order of ascending priority:
Verdicts are differentiated in 3 groups:
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.
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.
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:
A device rechecks these conditions whenever it detects changes of announced trust verdicts anywhere in the network.
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.
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 |
Trust verdicts are announced using Trust-Verdict TLVs:
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 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.
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.
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).
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.
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.
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.
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:
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:
Revoking trust in a protocol intended for bootstrapping is non-trivial, since neither an accurate clock nor network connectivity to 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.
IANA should add HNCP TLV types with the following contents:
20: Trust-Verdict
21: Managed-PSK
| [I-D.ietf-homenet-hncp] | Stenberg, M. and S. Barth, "Home Networking Control Protocol", Internet-Draft draft-ietf-homenet-hncp-01, 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. |
| [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. |
| [RFC4861] | Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. |
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!
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.