idnits 2.17.1 draft-richardson-ipsec-traversal-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 275: '...inner ESP is NOT REQUIRED to also prov...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 July 1997) is 9780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Michael Richardson 2 INTERNET-DRAFT Kai Martius 3 draft-richardson-ipsec-traversal-01.txt v1.1, 9 July 1997 4 Expires in six months 6 Firewall Traversal authorization system 8 Status of This memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), 24 or ftp.isi.edu (US West Coast). 26 Abstract 28 This document describes a public key certificate mechanism to authorize 29 traversal of multiple security gateways (firewalls). This work is inde- 30 pendant of transport layer in concept, and could apply to IPsec, TLS, or 31 SecSH. It is applied here to IPsec. The SPKI certificate format is used 32 here. 34 Table of Contents 36 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 37 1.1. Definition of terminology . . . . . . . . . . . . . . . . . 2 38 2. Introduction to the problem . . . . . . . . . . . . . . . . . . 3 39 2.1. Key Sharing methods . . . . . . . . . . . . . . . . . . . . 3 40 2.2. Stacked or tunnelled solutions . . . . . . . . . . . . . . . 4 41 2.3. Virtual Circuit solutions . . . . . . . . . . . . . . . . . 5 42 2.4. Issues raised . . . . . . . . . . . . . . . . . . . . . . . 6 43 3. Firewall traversal certificates . . . . . . . . . . . . . . . . 6 44 3.1. The IP-Gateway Certificate . . . . . . . . . . . . . . . . . 7 45 3.2. Definition of certificate . . . . . . . . . . . . . . . . . 7 46 3.3. An example . . . . . . . . . . . . . . . . . . . . . . . . . 8 47 3.4. Completing the certificate loop . . . . . . . . . . . . . . 8 48 4. Security Considerations: . . . . . . . . . . . . . . . . . . . . 9 49 5. References: . . . . . . . . . . . . . . . . . . . . . . . . . . 9 50 5.1. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 51 5.2. Expiration and File Name . . . . . . . . . . . . . . . . . . 10 53 1. Introduction 55 This document is a result of recent discussions in the IETF ipsec, IETF 56 secsh and IETF mobileip working groups about how to trust security 57 gateways (aka firewalls) with end-to-end (host to host) encryption and 58 authentication keys. 60 This document describes the problem, some solutions which have been 61 suggested in the past, and then goes on to describe a system of public 62 key signed certificates that would allow a series of appropriate 63 connections to automatically be setup. 65 Gupta97-1 gives an expanded view of the problems, and other solutions. 66 Unlike Gupta97-1, this document does not limit itself to firewalls that 67 are known apriori, or under the same administrative control. 69 For a solution to be scalable to the entire internet, the policy must 70 either be learnt dynamically from correspondant nodes (e.g. arrived at 71 through negotiation), or must be available in some pre-existing global 72 database such as the domain name system. 74 1.1. Definition of terminology 76 Here is a network of two security gateways, a client node and a server 77 node. 79 C---{G1}---{G2}---S 81 C is the client. 82 G1/G1 are gateways. 83 S is the server. 85 Since there are potentially more than one transport or network layer 86 connection, we define some terms to describe the different end points. 88 C is the transport layer originator. TLO 90 S is the transport layer target. TLT 92 C/G1 93 is a network layer originator/target pair. NLO/NLT/ 95 G1/G2 96 is a network layer originator/target pair. 98 G2/S 99 is a network layer originator/target pair. 101 If discussing application layer protocols (e.g. SSH, TLS) through 102 security gateways, then the transport layer designations above should be 103 replaced with the session layer designations (e.g. URL, hostname), and 104 the network layer designations with transport layer designations (e.g. 105 TCP endpoints, SSH/TLS host keys). 107 The end points of the different types of connections will be denoted 108 with a subscript. So, when C is used in an TLO context, the symbol C_s 109 will be used (s for Server) . When C is used in a NLO context, the 110 symbol C_g1 or C_g2 will be used. 112 2. Introduction to the problem 114 The problem is not as some say, merely a question of allowing security 115 protocols to pass unexamined through a security gateway. Many 116 environments have very strong auditing requirements, and encrypted 117 traffic is by design, intended to thwart attempts for third parties to 118 eavesdrop. 120 Further, this policy relies on the security of target hosts being 121 perfect. Were this the case in practice, for all vendors, for all 122 releases, both new and old, the firewall might not be required at all. 124 2.1. Key Sharing methods 126 It has been suggested by several people XXX that a key sharing protocol 127 will solve the problem. The firewall(s) would be provided with the 128 encryption keys in order to examine the traffic. Alternately, a copy of 129 the authentication keys would allow the firewall to verify the origin of 130 the packets, thus allowing it to apply its access policy. 132 C <------+----------+------> S 133 G1 G2 135 This solution is not appropriate because the problem is more 136 complicated. In general there will be a combination of network address 137 translating firewall, topology hiding firewalls, and particularities of 138 various protocols. 140 A host behind a network address translation may have an address that is 141 not available, or worse: illegal, to its correspondant node. The 142 firewall must therefore be involved during all the key exchange protocol 143 because the firewall (or the address that the TLx is translated to) is 144 the logical end point for the encryption, not the actual TLx. 146 When topology is hidden by a firewall, there must be some mechanism to 147 map the connection to the intended TLT. That is, despite the topology 148 hiding, there is a need to name selected pieces of the internal 149 topology, and communicate that name to the firewall. 151 The difficulty of doing this in general for all protocols in first 152 generation application layer firewalls, even for outbound connections, 153 is what caused the development of protocols like SOCKS. 155 A firewall that supports protocols that use more than a single logical 156 connection also has a requirement to see the contents of the "control" 157 or "nameserver" connection. The typical example is FTP, but CuSeeMe, 158 RealAudio, SunRPC (portmap is the nameserver connection), and most 159 multicast protocols have this problem. 161 Furthermore, sharing of authentication keys leads to the problem that 162 receiver can only verify a group of senders which in fact isn't an 163 authentication anymore. 165 2.2. Stacked or tunnelled solutions 167 A second proposal is to stack algorithms. This is being proposed by 168 Gupta97-2 for the mobileIP group. This is best illustrated by a diagram. 170 C_s <------+----------+------> S_c 171 C_g2 <------+--------> G2_c***> 172 C_g1 <----> G1_c*****> 174 Each arrow represents a secure connection, the upper connections being 175 transported in the lower connections. Stars represent unencrypted (from 176 that layer's point of view) connections. 178 Note: there is n+1 layers when n gateways are involved. Two gateways are 179 typical (one at each location), but should two higher security networks 180 (e.g. research or finance) inside the lower security organizational 181 network need to communicate, this number rises to 4. Future topologies 182 could further increase n. 184 Some systems which have implemented this method include SOCKS: one runs 185 SOCKS inside SOCKS. 187 The most glaring problem, however, is that the data, if encrypted, is 188 opaque to both gateways! The traversal problem has been solved, but the 189 auditing and protocol requirements remain. 191 There is some difficulty with dealing with ICMP messages, since the 192 gateway may not be able to do anything with them. 194 The repeated encapsulation (tunnelling) of one packet inside another 195 increases the overhead, and for packet protocols, decreasing the amount 196 of payload per packet. 198 This has serious efficiency and reliability implications. Node C may 199 have difficulty getting accurate ICMP messages back, and may not be able 200 to set its TCP MSS properly leading to excessive fragmentation. This 201 problem is not unique to this topology. 203 2.3. Virtual Circuit solutions 205 An alternate way to set up the associations is a series of adjacent 206 tunnels rather than a stack of tunnells. This is similar to what happens 207 in ATM networks with virtual circuits are setup. The ATM switches 208 negotiation frame ids between themselves and act as stateful routers. 210 There may still be a need for strong end to end security in this 211 situation, so the tunnels may be used to transport an end to end 212 security association. At most, there are two layers of security 213 associations with this method. 215 End to end C_s <--------+----------+--------> S_c 216 Hop by hop C_g1 <------>G1_c 217 G1_g2<---->G2_g1 218 G2_s<-----> S_g2 220 There are three ways to arrange the two sets of security associations: 222 1. Delegated traversal 223 the gateways may provide sufficient trust in identity that an 224 internal tunnel is not required. In that case, an upper protocol 225 may appear immediately inside the hop-by-hop security header. The 226 hop-by-hop SA's may provide authentication alone, or encryption 227 and integrity. On-the-wire IPsec packets might look like: 229 IP[C_g1->X] AH[C_g1->G1_c TCP/UDP/ICMP] 231 or 233 IP[C_g1->X] ESP[C_g1->G1_c TCP/UDP/ICMP] 235 2. Audited Traversal 236 If the gateways do not permit unexamined (i.e. encrypted) data to 237 pass through, then the end to end (C_s/S_c) SA must be 238 authentication only. The hop-by-hop SA's would have to provide the 239 privacy features. On-the-wire IPsec packets might look like: 241 IP[C_g1->X] ESP[C_g1->G1_c 242 IP[C_s->S_c] AH[C_s->S_c] TCP/UDP/IP/ICMP] 244 3. Authenticated traversal 245 If the gateways do allow encrypted data to pass through, then the 246 end to end SA's can include privacy features. The hop-by-hop SA 247 could be authentication only, or might include additional privacy 248 features to thwart traffic analysis. On-the-wire IPsec packets 249 might look like: 251 IP[C_g1->X] AH[C_g1->G1_c 252 ESP[C_s->S_c] ] 254 or 256 IP[C_g1->X] ESP[C_g1->G1_c 257 ESP[C_s->S_c] ] 259 Some notes on above: 261 1. In the audited case (1) it is possible for the gateways to control 262 what kind of data can flow through by looking at the next protocol 263 header in the AH packet. Thus the gateway can prevent unauthorized 264 tunnels from being formed. The gateway could allow IP without 265 necessarily giving up the ability to audit. This is not true for the 266 authenticated case, because once any ESP is allowed through, the 267 gateway gives up control of what protocols get transmitted through 268 the gateway. 270 2. At all times a single SA's could be used for different streams of 271 traffic (at the same sensitivity), or multiple SA's could be used for 272 a single stream of traffic. 274 3. in case 2, where there is an outer AH or integrity protected ESP, the 275 inner ESP is NOT REQUIRED to also provide integrity protection, but 276 may do so. 278 4. the X above could be either S_c or it could be G1_c. It is not clear 279 which is more appropriate. In the NAT situation, there are reduced 280 choices, in the absense of NAT, either is possible. (ISSUE) 282 2.4. Issues raised 284 The following questions are posed, which this document will attempt to 285 resolve: 287 1. how does the client know that it can trust gateway g1 or g2? 289 2. how does the server know that it can trust gateway g1 or g2? 291 3. how to tell the real server who the real client is? 293 Problems 1 and 2 are related, and are solved by the same mechanism. The 294 information as to the real client is also passed by this proceedure. 296 3. Firewall traversal certificates 298 If one makes an analogy between security perimeters and altitudes, then 299 the end nodes can be thought of as being on plateaus, possibly with 300 several ledges on the way up, with large amounts of plain between 301 plateaus. 302 Virtual private network tunnels are then bridges that span between 303 ledges/plateaus. Prior to building a bridge, some guide wires (symmetric 304 keys) must be established. To establish the guide wires requires sending 305 an ambassador out with appropriate proof of origin. The ambassador meets 306 up with a representative of the distant plateau, and they exchange 307 credentials. The meeting place, which occurs on the plain, at zero 308 altitude will be referred to as "security zone 0". 310 The wide open Internet is a good example of such a zone and it is 311 probably equivalent to sea level. In general, the security zone 0 is 312 just the lowest point on the path between the two security plateaus. 314 The remainder of this document is therefore a description of the 315 credentials that are provided by non-zero security zones to lower 316 altitude security levels. 318 3.1. The IP-Gateway Certificate 320 At each downward hop, a certificate is used to delegate the identity of 321 the TLO node to an lower security level gateway. At security level 0, 322 the ambassador meets with their counterpart. The counterpart also brings 323 a set of certificates. 325 Once proof of identify has been exchanged, the ambassador needs to bring 326 that proof back to the security plateau. The ambassador does this by 327 using the same certificate chain that was issued to it, to delegate the 328 higher identity to the ambassador. 330 The certificates are SPKI format. The issuer of the certificate is 331 ultimately the TLO or TLT node. The subject of the certificate is the 332 node to which authority is being delegated. The authentication being 333 delegated the list of hosts for which the gateway is authorized to speak 334 for. 336 In the simplest case, there is only one certificate issued by the TLx 337 nodes, and it can only delegate authority for itself. A more complicated 338 system would have an organizational CA or ISP based CA signing a 339 certificate that delegated a particular portion of the IP address space 340 to a particular key. 342 3.2. Definition of certificate 344 v4-network 345 this is followed by the v4 network prefix and the length of the 346 prefix. Hosts are indicated by a prefix length of 32. 348 v6-network 349 this is followed by the v6 network prefix and the length of the 350 prefix. Hosts are indicated by a prefix length of 128. 351 host 352 this is followed by a DNS name, or by a SDSI name 354 3.3. An example 356 For example, Somecompany.com used to use the class C subnet: 357 192.1.2.128/26. This is further divided into several 16 address subnet 358 that exist behind a packet filter. Further firewalls inside did network 359 address translation as well. The network topology would look like: 361 X14---fw1----pf1--- 363 where X14 has a private network address, fw1 provides network address 364 translation, and pf1 provides filtering only. Also assume that this 365 organization had a IPv6 prefix of c0:ff:ee:04:ba:be:: 367 Given that, DNSSEC would delegate authority for 192.1.2.128/26 and for 368 somecompany.com to the key SC1, then the following statements might be 369 made: 371 (cert (issuer SC1) 372 (subject pf1) 373 (auth (ip-gateway 374 (v4-network 205.233.54.128 26) 375 (v6-network c0:ff:ee:04:ba:be:: 48)))) 377 (cert (issuer (ref SC1 xterm14.somecompany.com)) 378 (subject fw1) 379 (auth (ip-gateway (host 380 (ref SC1 xterm14.somecompany.com))))) 382 We have to use a host name here because there is no IP address that can 383 be legitimately used. 385 ISSUE: I'm not sure how the (stop-at-key) etc. stuff of SPKI applies 386 here yet, but I KNOW that it does 388 ISSUE: a wildcard for the hostname might also be desirable, but perhaps 389 SDSI groups would also work here 391 3.4. Completing the certificate loop 393 Since all certificates chains must be rooted with a self-signed 394 certificate, the verifier of the ip-gateway chain (for instance, the TLx 395 node) must determine the origin of the TLO's authority to speak for that 396 address/hostname. The origin of its authority would come from either 397 DNSSEC or X.500 servers that it trusts. 399 This initial trust relationship would appear in this node via a 400 preconfigured root CA key, or cross certification of DNSSEC servers... 401 the technology for doing this is not described here. 403 4. Security Considerations: 405 This entire document discussed a security protocol. 407 5. References: 409 RFC-1825 410 R. Atkinson, "Security Architecture for the Internet Protocol", 411 RFC-1825, August 1995. 413 RFC-1826 414 R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. 416 RFC-1828 417 P. Metzger, W. A. Simpson, "IP Authentication using Keyed 418 MD5",RFC-1828, August 1995. 420 KSM-AH 421 New AH draft. 423 Maughan97 424 D. Maughan, M. Schertler, "Internet Security Association and Key 425 Management Protocol (ISAKMP)", version 7, draft-ietf-ipsec- 426 isakmp-07.txt, work in progress: February 21, 1997 428 Harkins97 429 D. Harkins, D. Carrel, "The resolution of ISAKMP with Oakley", 430 draft-ietf-ipsec-isakmp-oakley-03.txt, version 3, work in 431 progress: February 1997 433 Ylo97-1 434 T. Ylonen, "SSH Transport Layer Protocol", draft-ietf-secsh- 435 transport-00.txt, version 0, work in progress: March 22, 1997 437 Ellison97 438 C. Ellison, B. Frantz, B.M. Thomas, "Simple Public Key 439 Certificate", draft-ietf-spki-cert-structure-01.txt, version 1, 440 work in progress: March 25, 1997 442 SDSI 443 R. Rivest, B. Lampson, "SDSI - A Simple Distributed Security 444 Infrastructure SDSI", 445 %lt;URL:http://theory.lcs.mit.edu/ rivest/sdsi11.html>, October 2, 446 1996 448 Monte96 449 G. Montenegro, V. Gupta, "Firewall Support for Mobile IP", draft- 450 montenegro-firewall-mobileip-00.txt, 451 %lt;URL:http://skip.incog.com/drafts/draft-montenegro-firewall- 452 mobileip-00.txt%gt;, work in progress: Sept. 14, 1996 454 Doraswaymy97-1 455 N. Doraswaymy. "Implementation of Virtual Private Networks (VPNs) 456 with IP Security", draft-ietf-ipsec-vpn-00.txt, work in progress: 457 March 12, 1997 459 Gupta97-1 460 V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Goals and 461 Requirements", draft-ietf-mobileip-ft-req-00.txt, work in 462 progress: Jan. 20, 1997 464 Gupta97-2 465 V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Guidelines 466 for Firewalls and Mobile IP entities", draft-ietf-mobileip- 467 firewall-trav-00.txt, work in progress: March 17, 1997 469 5.1. Authors' Addresses 471 Michael C. Richardson 472 Sandelman Software Works Corp. 473 152 Rochester Street 474 Ottawa, ON K1R 7M4 475 Canada 477 Telephone: +1 613 233-6809 478 EMail: mcr@sandelman.ottawa.on.ca 479 http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/ 481 Kai Martius 482 Dresden University of Technology 483 Faculty of Medicine 484 Institute of Medical Informatics and Biometrics 485 Fetscherstr. 74 486 01307 Dresden 487 Germany 489 EMail: kai@imib.med.tu-dresden.de 491 5.2. Expiration and File Name 493 This draft expires January 9, 1998 495 Its file name is draft-richardson-ipsec-traversal-cert-01.txt