Internet DRAFT - draft-barth-homenet-hncp-security-trust
draft-barth-homenet-hncp-security-trust
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]
