One document matched: draft-barth-homenet-hncp-security-trust-01.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc autobreaks="yes"?>
<?rfc compact="yes"?>
<?rfc strict='yes'?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc
ipr='trust200902'
docName='draft-barth-homenet-hncp-security-trust-01'
category='std'
>
<front>
<title abbrev="HNCP - Security and Trust Management">
HNCP - Security and Trust Management
</title>
<author initials="S" surname="Barth" fullname="Steven Barth">
<address>
<postal>
<street/>
<city></city>
<code></code>
<country></country>
</postal>
<email>cyrus@openwrt.org</email>
</address>
</author>
<date month="October" year="2014" />
<area>Internet</area>
<workgroup>Homenet Working Group</workgroup>
<keyword>HNCP</keyword>
<keyword>Homenet</keyword>
<abstract>
<t>This document describes threats and a security and trust bootstrap mechanism
for the Home Networking Control Protocol (HNCP).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>This document describes imminent threats and different security and trust management mechanisms
to mitigate them.</t>
</section>
<section anchor="kwd" title='Requirements language'>
<t>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
<xref target='RFC2119'>RFC 2119</xref>.</t>
</section>
<section title="Scope">
<t>This draft is based on HNCP as described in <xref target="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 <xref target="RFC4861">NDP</xref> or <xref target="RFC3315">DHCPv6</xref>. This document intentionally does not cover
these and other Homenet-related threats not explicitly introduced by HNCP.</t>
<t>HNCP is a generic state synchronization mechanism carrying information
with varying threat potential. This draft will mainly consider the currently specified payloads:
<list>
<t>Network topology information such as homenet routers and their adjacent links</t>
<t>Address assignment information such as delegated and assigned prefixes for individual links</t>
<t>Naming and service discovery information such as auto-generated or
customized names for individual links and routers</t>
<t>IGP capabilities and preferences of individual routers</t>
</list>
</t>
</section>
<section title="Border Determination">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="HNCP Payload Security">
<t>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:</t>
<section title="Isolated router-to-router links">
<t>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.</t>
</section>
<section title="Authentication and Encryption of HNCP-traffic">
<t>The end-to-end mechanism <xref target="RFC6347">DTLS</xref>
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.</t>
<t>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.</t>
</section>
</section>
<section title="Trust Management for Authentication and Encryption">
<section title="Pre-shared secret based trust">
<t>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.
</t>
</section>
<section title="PKI-based trust">
<t>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.</t>
</section>
<section title="Certificate-based trust consensus">
<t>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.</t>
<section title="Trust Verdicts">
<t>Trust Verdicts are statements of HNCP-devices about the trustworthiness of X.509-certificates.
There are 5 possible verdicts in order of ascending priority:
<list>
<t>0 Neutral: no verdict exists but the homenet should find one</t>
<t>1 Cached Trust: the last known effective verdict was Configured or Cached Trust</t>
<t>2 Cached Distrust: the last known effective verdict was Configured or Cached Distrust</t>
<t>3 Configured Trust: trustworthy based upon an external ceremony or configuration</t>
<t>4 Configured Distrust: not trustworthy based upon an external ceremony or configuration</t>
</list>
</t>
<t>
Verdicts are differentiated in 3 groups:
<list>
<t>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.</t>
<t>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.</t>
<t>The Neutral verdict is used to announce a new device intending to join the homenet so a final
verdict for it can be found.</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="Trust Cache">
<t>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.</t>
<t>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.</t>
</section>
<section title="Announcement of Verdicts">
<t>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:
<list>
<t>The stored verdict is Cached Trust and the current effective verdict is Neutral or does not exist.</t>
<t>The stored verdict is Cached Distrust and the current effective verdict is Cached Trust.</t>
</list>
A device rechecks these conditions whenever it detects changes of announced trust verdicts
anywhere in the network.
</t>
<t>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.</t>
<t>Trust verdicts are announced using Trust-Verdict TLVs:
<figure>
<artwork>
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 |
</artwork>
</figure>
<list>
<t>Verdict represents the numerical index of the verdict.</t>
<t>(reserved) is reserved for future additions and MUST be set to 0 when
creating TLVs and ignored when parsing them.</t>
<t><xref target="RFC6234">SHA-256</xref> Fingerprint contains the fingerprint of the certificate.</t>
<t>Common Name contains the variable-length (1-64 bytes) common name of the certificate.</t>
</list>
</t>
</section>
<section title="Bootstrap Ceremonies">
<t>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.</t>
<section title="Trust by Identification">
<t>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.</t>
</section>
<section title="Preconfigured Trust">
<t>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).</t>
</section>
<section title="Trust on Button Press">
<t>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.</t>
</section>
<section title="Trust on First Use">
<t>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.</t>
</section>
</section>
</section>
</section>
<section title="Other homenet protocols">
<t>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.</t>
<t>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:
<list>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<figure>
<artwork>
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 |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
PSKs for individual protocols are derived from the random PSK through the use of <xref target="RFC6234">HMAC-SHA256</xref>
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:
<list>
<t>"ROUTING": to be used for IGPs. If a Random PSK exists then the derived PSK MUST be used to secure the chosen IGP.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<section title="Revocation of Trust">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA should add HNCP TLV types with the following contents:</t>
<t>20: Trust-Verdict</t>
<t>21: Managed-PSK</t>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc include="reference.I-D.draft-ietf-homenet-hncp-01.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.6347.xml"?>
</references>
<references title="Informative references">
<?rfc include="reference.RFC.6234.xml"?>
<?rfc include="reference.RFC.3315.xml"?>
<?rfc include="reference.RFC.4861.xml"?>
</references>
<section title="Draft source">
<t>As usual, this draft is available at <eref
target="https://github.com/fingon/ietf-drafts/">https://github.com/fingon/ietf-drafts/</eref>
in source format (with nice Makefile too). Feel free to send comments
and/or pull requests if and when you have changes to it! </t>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:46:51 |