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]