idnits 2.17.1 draft-richardson-ipsec-traversal-00.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-19) 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 270: '... ESP need 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 (11 June 1997) is 9809 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 mcr@sandelman.ottawa.on.ca 2 INTERNET-DRAFT SSH Communications Security 3 draft-richardson-ipsec-traversal-00.txt v1.1, 11 June 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 47 3.4. Completing the certificate loop . . . . . . . . . . . . . . 8 48 4. Security Considerations: . . . . . . . . . . . . . . . . . . . . 8 49 5. References: . . . . . . . . . . . . . . . . . . . . . . . . . . 8 50 5.1. Author's Address . . . . . . . . . . . . . . . . . . . . . . 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 ALT/ALO is translated to) 144 is the logical end point for the encryption, not the actual ALT/ALO. 146 When topology is hided by a firewall, there must be some mechanism to 147 map the connection to intended application layer target. That is, 148 despite the topology hiding, there is a need to name selected pieces of 149 the internal 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 2.2. Stacked or tunnelled solutions 163 A second proposal is to stack algorithms. This is being proposed by 164 Gupta97-2 for the mobileIP group. This is best illustrated by a diagram. 166 C_s <------+----------+------> S_c 167 C_g2 <------+--------> G2_c***> 168 C_g1 <----> G1_c*****> 170 Each arrow represents a secure connection, the upper connections being 171 transported in the lower connections. Stars represent unencrypted (from 172 that layer's point of view) connections. 173 Note: there is n+1 layers when n gateways are involved. Two gateways are 174 typical (one at each location), but should two higher security networks 175 (e.g. research or finance) inside the lower security organizational 176 network need to communicate, this number rises to 4. Future topologies 177 could further increase n. 179 Some systems which have implemented this method include SOCKS: one runs 180 SOCKS inside SOCKS. 182 The most glaring problem, however, is that the data, if encrypted, is 183 opaque to both gateways! The traversal problem has been solved, but the 184 auditing and protocol requirements remain. 186 There is some difficulty with dealing with ICMP messages, since the 187 gateway may not be able to do anything with them. 189 The repeated encapsulation (tunnelling) of one packet inside another 190 increases the overhead, and for packet protocols, decreasing the amount 191 of payload per packet. 193 This has serious efficiency and reliability implications. Node C may 194 have difficulty getting accurate ICMP messages back, and may not be able 195 to set its TCP MSS properly leading to excessive fragmentation. This 196 problem is not unique to this topology. 198 2.3. Virtual Circuit solutions 200 An alternate way to set up the associations is a series of adjacent 201 tunnels rather than a stack of tunnells. This is similar to what happens 202 in ATM networks with virtual circuits are setup. The ATM switches 203 negotiation frame ids between themselves and act as stateful routers. 205 There may still be a need for strong end to end security in this 206 situation, so the tunnels may be used to transport an end to end 207 security association. At most, there are two layers of security 208 associations with this method. 210 End to end C_s <--------+----------+--------> S_c 211 Hop by hop C_g1 <------>G1_c 212 G1_g2<---->G2_g1 213 G2_s<-----> S_g2 215 There are three ways to arrange the two sets of security associations: 217 1. Delegated traversal 218 the gateways may provide sufficient trust in identity that an 219 internal tunnel is not required. In that case, an upper protocol 220 may appear immediately inside the hop-by-hop security header. The 221 hop-by-hop SA's may provide authentication alone, or encryption 222 and integrity. On-the-wire IPsec packets might look like: 224 IP[C_g1->X] AH[C_g1->G1_c TCP/UDP/ICMP] 226 or 228 IP[C_g1->X] ESP[C_g1->G1_c TCP/UDP/ICMP] 230 2. Audited Traversal 231 If the gateways do not permit unexamined (i.e. encrypted) data to 232 pass through, then the end to end (C_s/S_c) SA must be 233 authentication only. The hop-by-hop SA's would have to provide the 234 privacy features. On-the-wire IPsec packets might look like: 236 IP[C_g1->X] ESP[C_g1->G1_c 237 IP[C_s->S_c] AH[C_s->S_c] TCP/UDP/IP/ICMP] 239 3. Authenticated traversal 240 If the gateways do allow encrypted data to pass through, then the 241 end to end SA's can include privacy features. The hop-by-hop SA 242 could be authentication only, or might include additional privacy 243 features to thwart traffic analysis. On-the-wire IPsec packets 244 might look like: 246 IP[C_g1->X] AH[C_g1->G1_c 247 ESP[C_s->S_c] ] 249 or 251 IP[C_g1->X] ESP[C_g1->G1_c 252 ESP[C_s->S_c] ] 254 Some notes on above: 256 1. In the audited case (1) it is possible for the gateways to control 257 what kind of data can flow through by looking at the next protocol 258 header in the AH packet. Thus the gateway can prevent authorized 259 tunnels from being formed. The gateway could allow IP without 260 necessarily giving up the ability to audit. This is not the case for 261 the authenticate case, because once any ESP is allowed through, the 262 gateway gives up control of what protocols get transmitted through 263 the gateway. 265 2. At all times a single SA's could be used for different streams of 266 traffic (at the same sensitivity), or multiple SA's could be used for 267 a single stream of traffic. 269 3. in case 2, where there is an outer AH or integrity protected ESP, the 270 inner ESP need is NOT REQUIRED to also provide integrity protection, 271 but may do so. 273 4. the X above could be either S_c or it could be G1_c. It is not clear 274 which is more appropriate. In the NAT situation, there are reduced 275 choices, in the absense of NAT, either is possible. (ISSUE) 277 2.4. Issues raised 279 The following questions are posed, which this document will attempt to 280 resolve: 282 1. how does the client know that it can trust gateway g1 or g2? 284 2. how does the server know that it can trust gateway g1 or g2? 286 3. how to tell the real server who the real client is? 288 Problems #1 and #2 are related, and are solved by the same mechanism. 289 The information as to the real client is also passed by this proceedure. 291 3. Firewall traversal certificates 293 If one makes an analogy between security perimeters and altitudes, then 294 the end nodes can be thought of as being on plateaus, possibly with 295 several ledges on the way up, with large amounts of plain between 296 plateaus. 298 Virtual private network tunnels are then bridges that span between 299 ledges/plateaus. Prior to building a bridge, some guide wires (symmetric 300 keys) must be established. To establish the guide wires requires sending 301 an ambassador out with appropriate proof of origin. The ambassador meets 302 up with a representative of the distant plateau, and they exchange 303 credentials. The meeting place, which occurs on the plain, at zero 304 altitude will be referred to as "security zone 0". 306 The wide open Internet is a good example of such a zone and it is 307 probably equivalent to sea level. In general, the security zone 0 is 308 just the lowest point on the path between the two security plateaus. 310 The remainder of this document is therefore a description of the 311 credentials that are provided by non-zero security zones to lower 312 altitude security levels. 314 3.1. The IP-Gateway Certificate 316 At each downward hop, a certificate is used to delegate the identity of 317 the ALO node to an lower security level gateway. At security level 0, 318 the ambassador meets with their counterpart. The counterpart also has a 319 set of certificates. Once proof of identify has been exchanged, the 320 ambassador needs to bring that proof back up to the security plateau. 321 The ambassador does this by using their own certificates. 323 The certificates are SPKI format. The issuer of the certificate is 324 ultimately the ALO or ALT node. The subject of the certificate is the 325 node to which authority is being delegated. The authentication being 326 delegated the list of hosts for which the gateway is authorized to speak 327 for. 329 In the simplest case, there is only one certificate issued by the 330 ALO/ALT nodes, and it can only delegate authority for itself. A more 331 complicated system would have an organizational CA or ISP based CA 332 signing a certificate that delegated a particular portion of the IP 333 address space to a particular key. 335 3.2. Definition of certificate 337 v4-network 338 this is followed by the v4 network prefix and the length of the 339 prefix. Hosts are indicated by a prefix length of 32. 341 v6-network 342 this is followed by the v6 network prefix and the length of the 343 prefix. Hosts are indicated by a prefix length of 128. 345 host 346 this is followed by a DNS name, or by a SDSI name 348 3.3. An example 350 For example, Somecompany.com used to use the class C subnet: 352 192.1.2.128/26. This is further divided into several 16 address subnet 353 that exist behind a packet filter. Further firewalls inside did network 354 address translation as well. The network topology would look like: 356 X14---fw1----pf1--- 358 where X14 has a private network address, fw1 provides network address 359 translation, and pf1 provides filtering only. Also assume that this 360 organization had a IPv6 prefix of c0:ff:ee:04:ba:be:: 362 Given that, DNSSEC would delegate authority for 192.1.2.128/26 and for 363 somecompany.com to the key SC1, then the following statements might be 364 made: 366 (cert (issuer SC1) 367 (subject pf1) 368 (auth (ip-gateway 369 (v4-network 205.233.54.128 26) 370 (v6-network c0:ff:ee:04:ba:be:: 48)))) 372 (cert (issuer (ref SC1 xterm14.somecompany.com)) 373 (subject fw1) 374 (auth (ip-gateway (host 375 (ref SC1 xterm14.somecompany.com))))) 377 We have to use a host name here because there is no IP address that can 378 be legitimately used. 380 ISSUE: I'm not sure how the (stop-at-key) etc. stuff of SPKI applies 381 here yet, but I KNOW that it does 383 ISSUE: a wildcard for the hostname might also be desirable, but perhaps 384 SDSI groups would also work here 386 3.4. Completing the certificate loop 388 Since all certificates chains must be rooted with a self-signed 389 certificate, the verifier of the ip-gateway chain (for instance, the ALT 390 node) must determine the origin of the ALO's authority to speak for that 391 address/hostname. The origin of its authority would come from either 392 DNSSEC or X.500 servers that it trusts. 394 This initial trust relationship would appear in this node via a 395 preconfigured root CA key, or cross certification of DNSSEC servers... 396 the technology for doing this is not described here. 398 4. Security Considerations: 400 This entire document discussed a security protocol. 402 5. References: 404 RFC-1825 405 R. Atkinson, "Security Architecture for the Internet Protocol", 406 RFC-1825, August 1995. 408 RFC-1826 409 R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. 411 RFC-1828 412 P. Metzger, W. A. Simpson, "IP Authentication using Keyed 413 MD5",RFC-1828, August 1995. 415 KSM-AH 416 New AH draft. 418 Maughan97 419 D. Maughan, M. Schertler, "Internet Security Association and Key 420 Management Protocol (ISAKMP)", version 7, draft-ietf-ipsec- 421 isakmp-07.txt, work in progress: February 21, 1997 423 Harkins97 424 D. Harkins, D. Carrel, "The resolution of ISAKMP with Oakley", 425 draft-ietf-ipsec-isakmp-oakley-03.txt, version 3, work in 426 progress: February 1997 428 Ylo97-1 429 T. Ylonen, "SSH Transport Layer Protocol", draft-ietf-secsh- 430 transport-00.txt, version 0, work in progress: March 22, 1997 432 Ellison97 433 C. Ellison, B. Frantz, B.M. Thomas, "Simple Public Key 434 Certificate", draft-ietf-spki-cert-structure-01.txt, version 1, 435 work in progress: March 25, 1997 437 SDSI 438 R. Rivest, B. Lampson, "SDSI - A Simple Distributed Security 439 Infrastructure SDSI", 440 %lt;URL:http://theory.lcs.mit.edu/ rivest/sdsi11.html>, October 2, 441 1996 443 Monte96 444 G. Montenegro, V. Gupta, "Firewall Support for Mobile IP", draft- 445 montenegro-firewall-mobileip-00.txt, 446 %lt;URL:http://skip.incog.com/drafts/draft-montenegro-firewall- 447 mobileip-00.txt%gt;, work in progress: Sept. 14, 1996 449 Gupta97-1 450 V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Goals and 451 Requirements", draft-ietf-mobileip-ft-req-00.txt, work in 452 progress: Jan. 20, 1997 454 Gupta97-2 455 V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Guidelines 456 for Firewalls and Mobile IP entities", draft-ietf-mobileip- 457 firewall-trav-00.txt, work in progress: March 17, 1997 459 5.1. Author's Address 461 Michael C. Richardson 462 Sandelman Software Works Corp. 463 152 Rochester Street 464 Ottawa, ON K1R 7M4 465 Canada 467 Telephone: +1 613 233-6809 468 EMail: mcr@sandelman.ottawa.on.ca 470 5.2. Expiration and File Name 472 This draft expires December 15, 1997 474 Its file name is draft-richardson-ipsec-traversal-cert-01.txt