idnits 2.17.1 draft-behringer-default-secure-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2014) is 3754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-homenet-arch' is defined on line 319, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-behringer-homenet-trust-bootstrap-01 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Behringer 3 Internet-Draft M. Pritikin 4 Intended status: Informational S. Bjarnason 5 Expires: July 19, 2014 Cisco 6 January 15, 2014 8 Making The Internet Secure By Default 9 draft-behringer-default-secure-00 11 Abstract 13 Pervasive monitoring on the Internet is enabled by the lack of 14 general, fundamental security. In his presentation at the 88th IETF 15 Bruce Schneier called for ubiquitous use of security technologies to 16 make pervasive monitoring too expensive and thus impractical. 17 However, today security is too operationally expensive, and thus only 18 used where strictly required. 20 In this position paper we argue that all network transactions can be 21 secure by default, with minimal or no operator involvement. This 22 requires an autonomic approach where all devices in a domain enrol 23 automatically in a trust domain. Once they share a common trust 24 anchor they can secure communications between themselves, following a 25 domain policy which is by default secure. 27 The focus of this proposal is the network itself, with all protocols 28 between network elements, including control plane protocols (e.g., 29 routing protocols) and management plane protocols (e.g., SSH, 30 netconf, etc). The proposal is evolutionary and allows a smooth 31 migration from today's Internet technology, device by device. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 19, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Autonomic Security . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Overview Of The Proposed Solution . . . . . . . . . . . . 3 70 2.2. Zero-Touch Bootstrapping Domain Certificates . . . . . . 4 71 2.3. Bootstrapping Key Material . . . . . . . . . . . . . . . 5 72 2.4. Backward Compatibility . . . . . . . . . . . . . . . . . 5 73 2.5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.6. Inter-Domain Security . . . . . . . . . . . . . . . . . . 6 75 3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5. Informative References . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Problem Statement 82 The reason that security mechanisms and protocols are not used today 83 is not that they are not available: There are plenty of secure 84 protocols available. Reasons why they are not used are typically: 86 o Lack of operational experience with the secure protocols. 88 o Complexity of the set-up of security mechanisms, including key 89 management. 91 o Ongoing operational cost for key management, trouble-shooting, 92 etc. 94 All of these reasons are operational reasons. The net result is that 95 enabling security on the network today is expensive, and therefore 96 only done when the expense can be justified. Many network operators 97 have tight budgets and will therefore avoid unnecessary operational 98 expenses. Many security measures which are in theory available don't 99 get deployed because of the operational cost involved. 101 2. Autonomic Security 103 The fundamental idea in this paper is to make security a default 104 behavior of a given network, and by extension the Internet as a 105 whole. This is enabled by autonomic concepts 106 [I-D.behringer-autonomic-network-framework], 107 [I-D.irtf-nmrg-autonomic-network-definitions]: Network devices 108 negotiate all required information, including security policies and 109 key materials, without the need of administrator intervention. In an 110 autonomic network, the default behavior is to secure every protocol. 111 A policy can define deviations from this rule if required. The 112 approach is backwards compatible, and allows for a smooth, device by 113 device upgrade. If in a negotiation it turns out that a peer element 114 is not autonomic, it simply keeps using existing mechanisms. Policy 115 controls this process to avoid downgrade attacks. 117 Negotiation of security parameters and keying material is available 118 today in many protocols, for example the IPsec protocol suite, or 119 TLS. However all such protocols act independently, and need to be 120 set up and maintained independently. In a network that runs 121 internally iBGP, OSPF, BFD and PIM for example, each protocol 122 security needs to be set up independently. Here we propose a generic 123 approach, where a node-level domain identity can be used to negotiate 124 parameters for any other protocol. We also demonstrate how this 125 node-level domain identity can be bootstrapped automatically. 127 2.1. Overview Of The Proposed Solution 129 The proposed solution requires some generic autonomic behavior on 130 nodes. "Autonomic" is generally described as "self-management", 131 which contains other "self-*" properties [Kephart]. Fundamentally, 132 an autonomic node acts slightly differently from a traditional node: 134 o It discovers other nodes, and their identities. 136 o It negotiates capabilities and parameters with other nodes or 137 groups of nodes. 139 o When another node belongs to the same domain (or a trusted one), 140 and has the required capabilities, keys are negotiated 141 automatically, and the required security protocol or mechanism is 142 enabled automatically. 144 o A high-level policy, called "intent" can be used to define the 145 default behavior of the network. 147 As mentioned above, all those properties exist today inside specific 148 protocols, but each protocol has to be configured manually, and the 149 key material has to be managed independently for each. Autonomic 150 Networking makes those properties available on a generic basis, to 151 all processes running on a node. This way, the key management 152 problem is solved a single time for all protocols, in an automatic 153 fashion. Security mechanisms along with their parameters and key 154 materials can be bootstrapped completely automatically. 156 With an autonomic approach on network elements, security can 157 therefore be made "automatic", with little to no administrative 158 intervention. This allows networks to run in a default secure mode 159 for all protocols, at little or no additional operational 160 expenditure. 162 2.2. Zero-Touch Bootstrapping Domain Certificates 164 The underlying security principle for Autonomic Networking is the 165 concept of a domain identity. A network operator manages and 166 controls all devices of a domain. A device belonging to a domain by 167 default trusts only devices belonging to the same domain. Each 168 device in the domain receives a domain certificate, which can be 169 cryptographically validated by other devices. 171 The distribution of domain certificates can be completely automated, 172 in a secure way. The document "Bootstrapping Key Infrastructures" 173 [I-D.pritikin-bootstrapping-keyinfrastructures] describes how domain 174 certificates can be securely bootstrapped in a zero-touch way, and is 175 the technical foundation behind this position paper. A practical 176 example on how a user in a homenet can use this mechanism is outlined 177 in the document "Bootstrapping Trust on a Homenet" 178 [I-D.behringer-homenet-trust-bootstrap]. 180 This allows the network operator to add devices to the domain based 181 on existing device credentials (e.g. IEEE 802.1AR vendor certificate) 182 or other any other criteria (location, time). In addition, the new 183 device has the possibility to validate the authenticity of the domain 184 that it is being invited to, by requiring the invite to be signed by 185 the manufacturer. 187 After a device has joined the domain, it can now communicate with any 188 other device in the domain and use the domain certificate as trust 189 anchor for any subsequent operations. 191 2.3. Bootstrapping Key Material 193 When an autonomic device wants to communicate or exchange information 194 with another autonomic device, it establishes and validates the 195 identity of the peer. A device belonging to the same domain is 196 trusted by default; a policy can restrict for which operations the 197 trust is valid. When the identity has been confirmed, the devices 198 negotiate key material and parameters for all subsequent protocols. 200 For example, the domain certificate introduced here helps in case of 201 routing protocols to negotiate a common key to be used for routing 202 protocol authentication as explained in 203 [I-D.polk-saag-rtg-auth-keytable] and draft-ietf-karp-ops-model 204 [I-D.ietf-karp-ops-model]. The actual key negotiation is outside 205 scope of this document. 207 2.4. Backward Compatibility 209 The approach described in this paper is evolutionary and allows for a 210 smooth migration. The enabling feature for this is the intrinsic 211 negotiation capability of an autonomic network. As part of the BGP 212 example above, a node will initially negotiate capabilities with the 213 peer(s). If the peer does not respond to the negotiation, we assume 214 it does not understand autonomic behavior, and fall back to 215 traditional, configured methods. If it does respond to negotiation, 216 the required parameters are negotiated and enabled automatically. 217 This way, a network can be migrated node by node. To detect and 218 possibly avoid downgrade attacks autonomic nodes log and notify such 219 events; once a negotiation with a node has happened, no downgrade is 220 allowed any more. 222 2.5. Policy 224 With the approach described here, nodes become intelligent enough to 225 negotiate the optimum security between themselves. This way, 226 security can be bootstrapped without any involvement of an admin or 227 configuration tool. However, different networks have different 228 requirements. For example, link encryption could be established 229 automatically using this approach. However, what should a node do 230 when for some reason the negotiation of crypto parameters fails? 231 Should it allow the connection unsecured, or should it drop it? 232 Also, in some environments, integrity protection for network 233 protocols is desired, in others all protocols should be encrypted. 235 These are policy questions. One network may want to only do 236 integrity protection, another one also encrypt; on might pursue a 237 "fail-open", another one a "fail-close" policy: When the security 238 operation fails, the communication is allowed in clear, or not 239 allowed. In an autonomic network there is a high level policy called 240 "intent" which defines such default behavior. This policy may also 241 define how to handle connections to other domains. 243 2.6. Inter-Domain Security 245 The security in an autonomic network is primarily based on the domain 246 certificates. This way, devices within a domain can authenticate 247 each other, using the same domain trust anchor. Sub-domains can be 248 used to segment a larger network and introduce different policies. 250 The same concept can be applied toward other domains, but using a 251 common trust anchor, or by cross-signing. A service provider for 252 example could validate the trust anchors of his peer providers once, 253 so that his nodes can also authenticate the nodes of the peers. 254 While such SP-to-SP approaches have failed in the past to reach any 255 significant deployment, here this interaction only has to happen on 256 the root certificate level once for the duration of the certificate 257 lifetime. This may be an acceptable burden. Common trust anchors 258 between all SPs are technically possible, but such approaches have 259 failed in the past, and are not further considered here. 261 Once nodes of another domain are authenticated, the policy in the 262 domain can define their authorization levels. This allows us to 263 define for example a policy like "trust all nodes from SPx for secure 264 eBGP connections". At first, the main BGP configuration can be 265 manual, with only the security being negotiated; at later stages 266 additional aspects of BGP and other protocols can be automated as 267 well. 269 3. Future Work 271 This paper illustrates the first step only in a long journey. The 272 main focus at this moment are network nodes, however, we believe that 273 the concepts of autonomic networking can be applied to end systems 274 and applications as well. This is for future study. 276 At the moment, trust within the domain is coarse grained, and only 277 allows for sub-domains. More fine-grained control inside a domain, 278 as well as inter-domain trust management requires more work. 280 To enable self-management, many components are required in a 281 standardized way, such as negotiation capabilities, a message bus, 282 and discovery mechanisms. Discussions have started in the IRTF on 283 definitions and goals of autonomic networking. Many details still 284 need to be worked out, although it is expected that many available 285 components can be re-used in the framework of Autonomic Networking. 287 4. Summary 289 Today, networks depend on detailed configuration, either from humans, 290 network management systems, or controllers. Configuration of 291 security is always explicit, requiring serious efforts primarily in 292 the operational management. The fundamental weakness today is that 293 there is no universal, secure node identity, so that all components 294 today have to bootstrap their own security model. 296 We believe that a node-level secure domain identity in the form of a 297 certificate, with a zero-touch yet secure bootstrap mechanism is the 298 fundamental cornerstone to making security a default on networks. 299 This approach is incremental and allows network elements to 300 automatically negotiate security with their peers. The model can be 301 extended inter-domain, allowing to also secure connections over 302 multiple domains. Following this model, networks could be secure by 303 default. 305 5. Informative References 307 [I-D.behringer-autonomic-network-framework] 308 Behringer, M., Pritikin, M., Bjarnason, S., and A. Clemm, 309 "A Framework for Autonomic Networking", draft-behringer- 310 autonomic-network-framework-01 (work in progress), October 311 2013. 313 [I-D.behringer-homenet-trust-bootstrap] 314 Behringer, M., Pritikin, M., and S. Bjarnason, 315 "Bootstrapping Trust on a Homenet", draft-behringer- 316 homenet-trust-bootstrap-01 (work in progress), October 317 2013. 319 [I-D.ietf-homenet-arch] 320 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 321 "IPv6 Home Networking Architecture Principles", draft- 322 ietf-homenet-arch-11 (work in progress), October 2013. 324 [I-D.ietf-karp-ops-model] 325 Hartman, S. and D. Zhang, "Operations Model for Router 326 Keying", draft-ietf-karp-ops-model-10 (work in progress), 327 January 2014. 329 [I-D.irtf-nmrg-autonomic-network-definitions] 330 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 331 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 332 Networking - Definitions and Design Goals", draft-irtf- 333 nmrg-autonomic-network-definitions-00 (work in progress), 334 December 2013. 336 [I-D.polk-saag-rtg-auth-keytable] 337 Polk, T. and R. Housley, "Routing Authentication Using A 338 Database of Long-Lived Cryptographic Keys", draft-polk- 339 saag-rtg-auth-keytable-05 (work in progress), November 340 2010. 342 [I-D.pritikin-bootstrapping-keyinfrastructures] 343 Behringer, M., Pritikin, M., and S. Bjarnason, 344 "Bootstrapping Key Infrastructures", January 2014. 346 [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic 347 Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, 348 January 2003. 350 Authors' Addresses 352 Michael H. Behringer 353 Cisco 355 Email: mbehring@cisco.com 357 Max Pritikin 358 Cisco 360 Email: pritikin@cisco.com 362 Steinthor Bjarnason 363 Cisco 365 Email: sbjarnas@cisco.com