Network Working Group M. Behringer Internet-Draft M. Pritikin Intended status: Informational S. Bjarnason Expires: July 19, 2014 Cisco January 15, 2014 Making The Internet Secure By Default draft-behringer-default-secure-00 Abstract Pervasive monitoring on the Internet is enabled by the lack of general, fundamental security. In his presentation at the 88th IETF Bruce Schneier called for ubiquitous use of security technologies to make pervasive monitoring too expensive and thus impractical. However, today security is too operationally expensive, and thus only used where strictly required. In this position paper we argue that all network transactions can be secure by default, with minimal or no operator involvement. This requires an autonomic approach where all devices in a domain enrol automatically in a trust domain. Once they share a common trust anchor they can secure communications between themselves, following a domain policy which is by default secure. The focus of this proposal is the network itself, with all protocols between network elements, including control plane protocols (e.g., routing protocols) and management plane protocols (e.g., SSH, netconf, etc). The proposal is evolutionary and allows a smooth migration from today's Internet technology, device by device. 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 July 19, 2014. Behringer, et al. Expires July 19, 2014 [Page 1] Internet-Draft Making The Internet Secure By Default January 2014 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. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 2. Autonomic Security . . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview Of The Proposed Solution . . . . . . . . . . . . 3 2.2. Zero-Touch Bootstrapping Domain Certificates . . . . . . 4 2.3. Bootstrapping Key Material . . . . . . . . . . . . . . . 5 2.4. Backward Compatibility . . . . . . . . . . . . . . . . . 5 2.5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6. Inter-Domain Security . . . . . . . . . . . . . . . . . . 6 3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Problem Statement The reason that security mechanisms and protocols are not used today is not that they are not available: There are plenty of secure protocols available. Reasons why they are not used are typically: o Lack of operational experience with the secure protocols. o Complexity of the set-up of security mechanisms, including key management. o Ongoing operational cost for key management, trouble-shooting, etc. All of these reasons are operational reasons. The net result is that enabling security on the network today is expensive, and therefore only done when the expense can be justified. Many network operators have tight budgets and will therefore avoid unnecessary operational Behringer, et al. Expires July 19, 2014 [Page 2] Internet-Draft Making The Internet Secure By Default January 2014 expenses. Many security measures which are in theory available don't get deployed because of the operational cost involved. 2. Autonomic Security The fundamental idea in this paper is to make security a default behavior of a given network, and by extension the Internet as a whole. This is enabled by autonomic concepts [I-D.behringer-autonomic-network-framework], [I-D.irtf-nmrg-autonomic-network-definitions]: Network devices negotiate all required information, including security policies and key materials, without the need of administrator intervention. In an autonomic network, the default behavior is to secure every protocol. A policy can define deviations from this rule if required. The approach is backwards compatible, and allows for a smooth, device by device upgrade. If in a negotiation it turns out that a peer element is not autonomic, it simply keeps using existing mechanisms. Policy controls this process to avoid downgrade attacks. Negotiation of security parameters and keying material is available today in many protocols, for example the IPsec protocol suite, or TLS. However all such protocols act independently, and need to be set up and maintained independently. In a network that runs internally iBGP, OSPF, BFD and PIM for example, each protocol security needs to be set up independently. Here we propose a generic approach, where a node-level domain identity can be used to negotiate parameters for any other protocol. We also demonstrate how this node-level domain identity can be bootstrapped automatically. 2.1. Overview Of The Proposed Solution The proposed solution requires some generic autonomic behavior on nodes. "Autonomic" is generally described as "self-management", which contains other "self-*" properties [Kephart]. Fundamentally, an autonomic node acts slightly differently from a traditional node: o It discovers other nodes, and their identities. o It negotiates capabilities and parameters with other nodes or groups of nodes. o When another node belongs to the same domain (or a trusted one), and has the required capabilities, keys are negotiated automatically, and the required security protocol or mechanism is enabled automatically. o A high-level policy, called "intent" can be used to define the default behavior of the network. Behringer, et al. Expires July 19, 2014 [Page 3] Internet-Draft Making The Internet Secure By Default January 2014 As mentioned above, all those properties exist today inside specific protocols, but each protocol has to be configured manually, and the key material has to be managed independently for each. Autonomic Networking makes those properties available on a generic basis, to all processes running on a node. This way, the key management problem is solved a single time for all protocols, in an automatic fashion. Security mechanisms along with their parameters and key materials can be bootstrapped completely automatically. With an autonomic approach on network elements, security can therefore be made "automatic", with little to no administrative intervention. This allows networks to run in a default secure mode for all protocols, at little or no additional operational expenditure. 2.2. Zero-Touch Bootstrapping Domain Certificates The underlying security principle for Autonomic Networking is the concept of a domain identity. A network operator manages and controls all devices of a domain. A device belonging to a domain by default trusts only devices belonging to the same domain. Each device in the domain receives a domain certificate, which can be cryptographically validated by other devices. The distribution of domain certificates can be completely automated, in a secure way. The document "Bootstrapping Key Infrastructures" [I-D.pritikin-bootstrapping-keyinfrastructures] describes how domain certificates can be securely bootstrapped in a zero-touch way, and is the technical foundation behind this position paper. A practical example on how a user in a homenet can use this mechanism is outlined in the document "Bootstrapping Trust on a Homenet" [I-D.behringer-homenet-trust-bootstrap]. This allows the network operator to add devices to the domain based on existing device credentials (e.g. IEEE 802.1AR vendor certificate) or other any other criteria (location, time). In addition, the new device has the possibility to validate the authenticity of the domain that it is being invited to, by requiring the invite to be signed by the manufacturer. After a device has joined the domain, it can now communicate with any other device in the domain and use the domain certificate as trust anchor for any subsequent operations. Behringer, et al. Expires July 19, 2014 [Page 4] Internet-Draft Making The Internet Secure By Default January 2014 2.3. Bootstrapping Key Material When an autonomic device wants to communicate or exchange information with another autonomic device, it establishes and validates the identity of the peer. A device belonging to the same domain is trusted by default; a policy can restrict for which operations the trust is valid. When the identity has been confirmed, the devices negotiate key material and parameters for all subsequent protocols. For example, the domain certificate introduced here helps in case of routing protocols to negotiate a common key to be used for routing protocol authentication as explained in [I-D.polk-saag-rtg-auth-keytable] and draft-ietf-karp-ops-model [I-D.ietf-karp-ops-model]. The actual key negotiation is outside scope of this document. 2.4. Backward Compatibility The approach described in this paper is evolutionary and allows for a smooth migration. The enabling feature for this is the intrinsic negotiation capability of an autonomic network. As part of the BGP example above, a node will initially negotiate capabilities with the peer(s). If the peer does not respond to the negotiation, we assume it does not understand autonomic behavior, and fall back to traditional, configured methods. If it does respond to negotiation, the required parameters are negotiated and enabled automatically. This way, a network can be migrated node by node. To detect and possibly avoid downgrade attacks autonomic nodes log and notify such events; once a negotiation with a node has happened, no downgrade is allowed any more. 2.5. Policy With the approach described here, nodes become intelligent enough to negotiate the optimum security between themselves. This way, security can be bootstrapped without any involvement of an admin or configuration tool. However, different networks have different requirements. For example, link encryption could be established automatically using this approach. However, what should a node do when for some reason the negotiation of crypto parameters fails? Should it allow the connection unsecured, or should it drop it? Also, in some environments, integrity protection for network protocols is desired, in others all protocols should be encrypted. These are policy questions. One network may want to only do integrity protection, another one also encrypt; on might pursue a "fail-open", another one a "fail-close" policy: When the security operation fails, the communication is allowed in clear, or not Behringer, et al. Expires July 19, 2014 [Page 5] Internet-Draft Making The Internet Secure By Default January 2014 allowed. In an autonomic network there is a high level policy called "intent" which defines such default behavior. This policy may also define how to handle connections to other domains. 2.6. Inter-Domain Security The security in an autonomic network is primarily based on the domain certificates. This way, devices within a domain can authenticate each other, using the same domain trust anchor. Sub-domains can be used to segment a larger network and introduce different policies. The same concept can be applied toward other domains, but using a common trust anchor, or by cross-signing. A service provider for example could validate the trust anchors of his peer providers once, so that his nodes can also authenticate the nodes of the peers. While such SP-to-SP approaches have failed in the past to reach any significant deployment, here this interaction only has to happen on the root certificate level once for the duration of the certificate lifetime. This may be an acceptable burden. Common trust anchors between all SPs are technically possible, but such approaches have failed in the past, and are not further considered here. Once nodes of another domain are authenticated, the policy in the domain can define their authorization levels. This allows us to define for example a policy like "trust all nodes from SPx for secure eBGP connections". At first, the main BGP configuration can be manual, with only the security being negotiated; at later stages additional aspects of BGP and other protocols can be automated as well. 3. Future Work This paper illustrates the first step only in a long journey. The main focus at this moment are network nodes, however, we believe that the concepts of autonomic networking can be applied to end systems and applications as well. This is for future study. At the moment, trust within the domain is coarse grained, and only allows for sub-domains. More fine-grained control inside a domain, as well as inter-domain trust management requires more work. To enable self-management, many components are required in a standardized way, such as negotiation capabilities, a message bus, and discovery mechanisms. Discussions have started in the IRTF on definitions and goals of autonomic networking. Many details still need to be worked out, although it is expected that many available components can be re-used in the framework of Autonomic Networking. Behringer, et al. Expires July 19, 2014 [Page 6] Internet-Draft Making The Internet Secure By Default January 2014 4. Summary Today, networks depend on detailed configuration, either from humans, network management systems, or controllers. Configuration of security is always explicit, requiring serious efforts primarily in the operational management. The fundamental weakness today is that there is no universal, secure node identity, so that all components today have to bootstrap their own security model. We believe that a node-level secure domain identity in the form of a certificate, with a zero-touch yet secure bootstrap mechanism is the fundamental cornerstone to making security a default on networks. This approach is incremental and allows network elements to automatically negotiate security with their peers. The model can be extended inter-domain, allowing to also secure connections over multiple domains. Following this model, networks could be secure by default. 5. Informative References [I-D.behringer-autonomic-network-framework] Behringer, M., Pritikin, M., Bjarnason, S., and A. Clemm, "A Framework for Autonomic Networking", draft-behringer- autonomic-network-framework-01 (work in progress), October 2013. [I-D.behringer-homenet-trust-bootstrap] Behringer, M., Pritikin, M., and S. Bjarnason, "Bootstrapping Trust on a Homenet", draft-behringer- homenet-trust-bootstrap-01 (work in progress), October 2013. [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-11 (work in progress), October 2013. [I-D.ietf-karp-ops-model] Hartman, S. and D. Zhang, "Operations Model for Router Keying", draft-ietf-karp-ops-model-10 (work in progress), January 2014. [I-D.irtf-nmrg-autonomic-network-definitions] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking - Definitions and Design Goals", draft-irtf- nmrg-autonomic-network-definitions-00 (work in progress), December 2013. Behringer, et al. Expires July 19, 2014 [Page 7] Internet-Draft Making The Internet Secure By Default January 2014 [I-D.polk-saag-rtg-auth-keytable] Polk, T. and R. Housley, "Routing Authentication Using A Database of Long-Lived Cryptographic Keys", draft-polk- saag-rtg-auth-keytable-05 (work in progress), November 2010. [I-D.pritikin-bootstrapping-keyinfrastructures] Behringer, M., Pritikin, M., and S. Bjarnason, "Bootstrapping Key Infrastructures", January 2014. [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, January 2003. Authors' Addresses Michael H. Behringer Cisco Email: mbehring@cisco.com Max Pritikin Cisco Email: pritikin@cisco.com Steinthor Bjarnason Cisco Email: sbjarnas@cisco.com Behringer, et al. Expires July 19, 2014 [Page 8]