Internet DRAFT - draft-bonnetain-hncp-security
draft-bonnetain-hncp-security
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
Abstract
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.
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 January 5, 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.
Bonnetain Expires January 5, 2015 [Page 1]
Internet-Draft Homenet Trust July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. HNCP message layout . . . . . . . . . . . . . . . . . . . . . 3
4. Public/private key pair . . . . . . . . . . . . . . . . . . . 4
4.1. Node Key TLV . . . . . . . . . . . . . . . . . . . . . . 4
5. Signature . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Signature TLV . . . . . . . . . . . . . . . . . . . . . . 5
6. Trust relationships . . . . . . . . . . . . . . . . . . . . . 5
6.1. Trusted nodes set . . . . . . . . . . . . . . . . . . . . 5
6.2. Relaying Node Data TLVs . . . . . . . . . . . . . . . . . 6
6.3. Using Node Data TLVs . . . . . . . . . . . . . . . . . . 6
6.4. Trust Link TLV . . . . . . . . . . . . . . . . . . . . . 6
7. Symmetric encryption . . . . . . . . . . . . . . . . . . . . 6
7.1. Encryption functioning . . . . . . . . . . . . . . . . . 6
7.2. Shared key management . . . . . . . . . . . . . . . . . . 7
7.3. Symmetric cipher TLVs . . . . . . . . . . . . . . . . . . 8
7.3.1. Shared key TLV . . . . . . . . . . . . . . . . . . . 8
7.3.2. Private Data TLV . . . . . . . . . . . . . . . . . . 8
8. Trust establishment & revocation . . . . . . . . . . . . . . 9
8.1. Trust relationship establishment . . . . . . . . . . . . 9
8.1.1. Node Information TLV . . . . . . . . . . . . . . . . 10
8.1.2. Simple Trust Establishment . . . . . . . . . . . . . 10
8.2. Trust revocation . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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.
Bonnetain Expires January 5, 2015 [Page 2]
Internet-Draft Homenet Trust July 2014
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.
2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
3. HNCP message layout
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
(Section 7.3.2).
Node Data TLV model:
+ Node Data TLV
|
+--+ Identity & Trust information
|
+--+ Cryptography elements
|
+--+ Other public TLVs
|
+--+ Private Data TLV
| |
| + Encrypted TLVs
|
+--+ Signature
The following TLVs MUST NOT be encrypted:
o Node Key TLV (Section 4.1)
o Trust Link TLVs (Section 6.4)
o Shared Key TLVs (Section 7.3.1)
o Node Information TLV (Section 8.1.1)
o Signature TLV (Section 5.1)
Bonnetain Expires January 5, 2015 [Page 3]
Internet-Draft Homenet Trust July 2014
The Node Data TLV MUST contain a Node Key TLV and a Signature TLV.
4. Public/private key pair
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.
4.1. Node Key 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: 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.
5. Signature
Any Node Data TLV MUST be signed with the originator's private key.
The input of the signature function is the concatenation of:
o The HNCP update sequence number (See [I-D.ietf-homenet-hncp],
section 5.2.4).
o The complete set of TLVs embedded in the Node Data TLV, not
including the Signature TLV itself or the others elements of the
Node Data TLV header.
Bonnetain Expires January 5, 2015 [Page 4]
Internet-Draft Homenet Trust July 2014
The signature is then included in a Signature TLV, as the last Node
Data TLV's sub-TLV.
5.1. Signature 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signature algorithm: The algorithm used for signature (including
padding and hash function). MUST be compatible with the published
public key.
Signature: The raw signature, verifiable with the originator's
public key
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.
6. Trust relationships
The signature process specified previously ensures data integrity and
authenticity. In this document, we propose to enforce authorization
using directed trust relationships.
6.1. Trusted nodes set
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.
Bonnetain Expires January 5, 2015 [Page 5]
Internet-Draft Homenet Trust July 2014
This definition ensures that, given a common view of the trust graph,
all computed Trusted Nodes Sets are either equal or disjoint.
6.2. Relaying Node Data TLVs
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.
6.3. Using Node Data TLVs
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.
6.4. Trust Link 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: TRUST-LINK (70) | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains the hash of the public key of a trusted node.
7. Symmetric encryption
7.1. Encryption functioning
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
Bonnetain Expires January 5, 2015 [Page 6]
Internet-Draft Homenet Trust July 2014
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:
o A router generates a reasonably long secret symmetric key, using
suitable random source, which will be used only in HNCP.
o For each router in the Trusted Nodes Set, the originator creates a
Shared Key TLV (Section 7.3.1), with the secret key encrypted with
the trusted router's public key.
o Each router in the Trusted Nodes Set can decrypt the key using its
private key.
o Secret data is encrypted symmetrically with the Shared Key and put
in the Private Data TLV (Section 7.3.2).
Although a single key is enough, multiple keys may coexist. Keys are
therefore identified by the couple (key identifier, key emitter).
7.2. Shared key management
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:
o One of the nodes in the Trusted Nodes Set already advertises a
Shared Key. The local node MUST wait for the shared key emitter to
encrypt the key for him.
o No shared key is advertised. The node in the Trusted Nodes Set
with the highest Node Identifier Hash MUST generate a key and
advertise it to the Trusted Nodes Set by sending one Shared Key
TLV (Section 7.3.1) per other node in the Trusted Node Set.
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
(Section 8.2)), all keys and all the secrets shared with it MUST be
renewed.
Bonnetain Expires January 5, 2015 [Page 7]
Internet-Draft Homenet Trust July 2014
7.3. Symmetric cipher TLVs
7.3.1. Shared key 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: SHARED-KEY (71) | Length: >= 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(originator's node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Asymmetric algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Symmetric key encrypted with |
| node public key |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key identifier: The identifier of the published key. A router
SHOULD NOT publish a new key if a usable and non-compromised key
can be used instead.
Hash: The identifier of the node that is able to decipher the
encrypted secret key.
Asymmetric algorithm: The algorithm used for encryption
Symmetric key: The raw shared key, encrypted with the target 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
[RFC3447]).
7.3.2. Private Data 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: PRIVATE-DATA (72) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bonnetain Expires January 5, 2015 [Page 8]
Internet-Draft Homenet Trust July 2014
| Key identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Symmetric algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Algorithm-specific data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains the information to choose and use the shared key.
Key identifier: The id of the used key. Matches Shared Key TLV (See
above)
Hash: The node identifier hash of the emitter of the key.
Symmetric algorithm: The encryption algorithm
Algorithm-specific data: Everything needed to decrypt, but the key.
Contains the initialization vector, if any.
Encrypted TLVs: A blob of encrypted data.
8. Trust establishment & revocation
8.1. Trust relationship establishment
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:
o Preinstalled public key files
o Automatic trust of nodes on a particular network interface
Bonnetain Expires January 5, 2015 [Page 9]
Internet-Draft Homenet Trust July 2014
o Public keys fetched by another protocol
o Managed by the user through a web interface, helped with gathered
information
o User action like pressing button that temporarily enables trust
establishment
o Centralized trust bootstrapping as specified in
[I-D.behringer-homenet-trust-bootstrap]
o Trust link management from a remote server
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.
8.1.1. Node Information 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: NODE-INFO (12) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Human-readable string |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains information about the node, (such as a serial
number, a manufacturer, a name...) in a human-readable way, to help a
user to choose between nodes. It can be used to help a user to
identify and choose to-be-trusted nodes. However, this information
on mistrusted nodes can't be verified, is not fully reliable, and can
be the same for different nodes.
8.1.2. Simple Trust Establishment
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
Bonnetain Expires January 5, 2015 [Page 10]
Internet-Draft Homenet Trust July 2014
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.
8.2. Trust revocation
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.
9. Security Considerations
This document provides some level of security to HNCP.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-13 (work in progress), March 2014.
[I-D.ietf-homenet-hncp]
Stenberg, M. and S. Barth, "Home Networking Control
Protocol", draft-ietf-homenet-hncp-00 (work in progress),
April 2014.
Bonnetain Expires January 5, 2015 [Page 11]
Internet-Draft Homenet Trust July 2014
[CCITT.X690.2002]
International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002.
10.2. Informative References
[I-D.behringer-homenet-trust-bootstrap]
Behringer, M., Pritikin, M., and S. Bjarnason,
"Bootstrapping Trust on a Homenet", draft-behringer-
homenet-trust-bootstrap-02 (work in progress), February
2014.
Appendix A. Acknowledgments
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.
Author's Address
Xavier Bonnetain
Cisco Systems
Paris
France
Email: xavier.bonnetain_ietf@polytechnique.org
Bonnetain Expires January 5, 2015 [Page 12]
