| Network Working Group | X. Bonnetain |
| Internet-Draft | Cisco Systems |
| Intended status: Standards Track | July 4, 2014 |
| Expires: January 5, 2015 |
HNCP security based on routers trust
draft-bonnetain-hncp-security-00
This memo describes how to secure HNCP. Based on asymmetric cryptography and trust relationships, it ensures integrity, authenticity and, to a lesser extent, secrecy and non-repudiation. This secrecy can be used to encrypt part of the shared data, or to secure other protocols, like the routing protocol.
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 January 5, 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.
Current home networks, left unsecured, can be subject to various attacks: IP spoofing, Router Advertisement spoofing... Besides, HNCP can extend those threats to the whole network and allow any router to impact any part of it.
Protection against threats affecting a single link is out of the scope of this document. Instead, it intends to prevent these threats from being extended to multiple links. In particular, an attacker connected to an unsecured link shouldn't be able to cause any harm on a secured link.
This memo proposes a distributed approach to establish and use secured relationships between routers.
The rest of this memo is organized as follow. Section 2 defines the usual keywords, Section 3 overviews the data structure changes, Section 4 describes the public/private key pair use, Section 5 shows how signatures are done, Section 6 describes the trust mechanism, Section 7 describes how to encrypt data with trusted peers and Section 8 describes how trust is established or revoked.
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
This memo defines a new layout for the Node Data TLV (defined in [I-D.ietf-homenet-hncp]): all data is signed, and part of it can be encrypted in a dedicated container, the Private Data TLV [pvdtlv].
+ Node Data TLV | +--+ Identity & Trust information | +--+ Cryptography elements | +--+ Other public TLVs | +--+ Private Data TLV | | | + Encrypted TLVs | +--+ Signature
Node Data TLV model:
The following TLVs MUST NOT be encrypted:
The Node Data TLV MUST contain a Node Key TLV and a Signature TLV.
HNCP security is based on asymmetric cryptography. Hence, all HNCP nodes MUST have their own public/private key pair, and they MUST advertise one and only one Node Key TLV containing the public key, included in their Node Data TLV defined in [I-D.ietf-homenet-hncp].
Furthermore, all HNCP nodes MUST use their public key as node identifiers, which implies that the node identifier hash used in HNCP MUST be the MD5 hash of the public key. As MD5 is not collision resistant, other hash functions could be more suitable for that purpose.
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: NODE-KEY (7) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Public key | | (ASN.1 DER format) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Public key: The public key used for node identification and signature verification. It is an ASN.1 SubjectPublicKeyInfo field, as defined in [RFC3280], section 4.1. ASN.1 Distinguished Encoding Rules (DER) are used to encode it to ensure the uniqueness of the hash of the public key. See [CCITT.X690.2002] for details on ASN.1 and DER. This field is the input to generate the node identifier hash.
Any Node Data TLV MUST be signed with the originator's private key. The input of the signature function is the concatenation of:
The signature is then included in a Signature TLV, as the last Node Data TLV's sub-TLV.
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: SIGNATURE (65535) | Length: >= 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Signature of the preceding TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The signature parameters could be a new IANA register or an existing ones. Input from the working group is required to decide which default signature scheme should be used.
The signature process specified previously ensures data integrity and authenticity. In this document, we propose to enforce authorization using directed trust relationships.
Each node MUST maintain a list of trusted nodes identifier (public keys, see Section 4) and advertise the hashes of these identifiers as part of the Node Data TLV using Trust Link TLVs. Sharing this information allows each node to have a local copy of all the trust relationships.
Using this database, each node can create a graph representing the trust network, where trust relationships are oriented edges.
Each node can then compute the Trusted Nodes Set, containing all reachable nodes with a trust path from the local node to them, and vice versa.
This definition ensures that, given a common view of the trust graph, all computed Trusted Nodes Sets are either equal or disjoint.
All HNCP updates with an invalid signature or an invalid node identifier hash MUST be ignored.
All other updates must be relayed, even those from nodes that are not included in the Trusted Nodes Set, but such updates SHOULD be rate and size limited. This way, any node can compute the Trusted Nodes Set based on a complete knowledge of the trust network, which is necessary in some cases.
All Node Data TLVs' authenticity must be verified using the Node Data TLV's update number, the Node Key TLV and the Signature TLV, as specified in Section 5.1.
TLVs contained in Node Data TLVs originated by nodes that are not in the Trusted Node Set must be ignored, except for the TLVs mandatory to establish the trust.
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-LINK (70) | Length: 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | H(node identifier) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains the hash of the public key of a trusted node.
Asymmetric cryptography used in previous sections ensures integrity, but not secrecy. HNCP security is hence done in two steps: asymmetric cryptography is used to encrypt a symmetric shared key, which is then used to encrypt data. Most of the data can be encrypted this way, but it isn't required. For example, to secure the home, the routing protocol (unicast or multicast) must be secured as well, and a dedicated shared secret key can be flooded to the Trusted Nodes Set using this procedure.
Shared secret establishment works as follow:
Although a single key is enough, multiple keys may coexist. Keys are therefore identified by the couple (key identifier, key emitter).
A node with an empty Trusted Node Set doesn't need to share its private data and therefore doesn't have to generate a shared key.
When the local node see some other nodes in its Trusted Nodes Set, two situations can occur:
If more than one key is available for a node, it SHOULD use the key of the emitter with the highest node identifier hash, and other key emitter SHOULD stop advertising their key.
If a key is no longer advertised, nodes MUST stop using it.
If a node quits the Trusted Node Set (in case of trust revocation [rev]), all keys and all the secrets shared with it MUST be renewed.
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: SHARED-KEY (71) | Length: >= 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | H(originator's node identifier) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Asymmetric algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Symmetric key encrypted with | | node public key | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As for signature specification, the algorithm list can be a new IANA registry, and contains various standardized asymmetric encryption algorithms (such as RSAES-OAEP or RSAES-PKCS1-v1.5, defined in
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: PRIVATE-DATA (72) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | H(node identifier) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Symmetric algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Algorithm-specific data | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Using HNCP, a node can obtain the public keys of connected nodes and decide whether to trust them or not. The way trust relationships can be created is implementation specific, and therefore out of the scope of this document. A way to establish trust with a minimal user input is described in Section 8.1.2.
For instance, the following methods may be used:
Such a process should be as user-friendly as possible. Implementations should try to fit to existing security processes like pushing buttons, entering pin codes or relying on certificates in order to provide a satisfactory security level.
Nodes may also look at the trust network to suggest to the user which trust relationship should be established.
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: NODE-INFO (12) | Length: >= 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Human-readable string | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This method allows a router to trust another router with a minimal user involvement. Any action (like pressing a button for a few seconds) can trigger it.
At first, the router trusts all its network neighbors it doesn't already trusts (eventually limited to some interfaces). Then, After a timeout, only the neighbors that trusts the router back remains trusted.
Trusting only the routers that trusts you back limits the number of trusts links advertised, and allow different homenets to be on the same link. This way of creating trust links should not be used on unsecured links by default (e.g unsecured WiFi, or WiFi if you want to ensure some physical protection).
A router may also automatically trust newcomers on some interfaces. However, this should not be the default behavior.
A node advertises all the hashes of the nodes it trusts. A node can revoke a trust link by stopping the advertisement of the according TLV.
This document provides some level of security to HNCP.
| [I-D.behringer-homenet-trust-bootstrap] | Behringer, M., Pritikin, M. and S. Bjarnason, "Bootstrapping Trust on a Homenet", Internet-Draft draft-behringer-homenet-trust-bootstrap-02, February 2014. |
We would like to thank all the people who participated in this document. In particular, we would like to thank Mark Townsley, Pierre Pfister, Markus Stenberg and Steven Barth for interesting advice in this problem space.