Authenticated Firewall Traversal with IPSEC M.C. Richardson INTERNET-DRAFT Milkyway Networks Corporation Expires in six months April 1996 draft-richardson-ipsec-aft-00.txt Authenticated Firewall Traversal with IPsec. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft document 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 mate- rial or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 1. Introduction A number of proposed protocols describe mechanisms whereby end to end authentication or privacy may be negotiated: most notable is the IPSEC working group where these issues are dealt with in a general way. Some relating working groups make use of the IPSEC (and related IPv6 facilities) facilities to provide authentication services (mobileip), while other groups (notably SNMPv2, RSVP, OSPF, BGP, AFT and CAT) provide their own facilities. This documents describes some of the common considerations for all of these protocols when there exists security gateway(s) (aka "fire- walls") between the end nodes that are negotiating security. This document does not enter into the debate about node security ver- sus network security. It is assumed that the need for firewall like facilities will continue to exist for sometime. Whether or not IPSEC and/or IPv6 security services make firewalls obsolete or more common will remain a heated question for sometime. Richardson [Page 1] INTERNET DRAFT April 1996 2. Classification and nomenclature of current firewall technologies Broadly speaking, most observers see two current firewall technolo- gies: packet filtering and application layer gateways. There are sev- eral generations of each type, and a growing number of firewalls that are hybrids. The primary distinction for nodes that wish to traverse firewalls is one of transparency. Packet filters do not generally perform any operations above the network layer, and application layer firewalls do not generally do anything below the transport layer. This has meant, historically, that application layer firewalls required that applications were aware of the presence of the fire- wall. The security features were not transparent. Difficulties may arise when trying to traverse two or more firewalls. These types of firewalls are "first generation" application layer firewalls. Packet filters, on the other hand, have historically been completely invisible to applications. In many cases packet filters do not check every packet (only TCP packets with the SYN and ACK) bits set. They rely on correct behaviour from internal hosts to discard packets that arrive for sessions that are not open. A new breed of firewall provides the transparency of packet filters, but the control of application layer firewalls. Some of these fire- walls are hybrids, some make use of modified protocol stacks. The latter often provide network address translation services as well: often showing the outside world only one address, that of the fire- wall. Both types of firewalls have a lot of difficulty dealing with data- gram protocols. The degree of support for these protocols is not good. New innovations, such as the RealAudio protocol, can become nightmares for security officers. To simplify discussion a common security policy will be outlined. 3. A trial scenario A large organization has a firewall between their internal network and the rest of the internet. A portion of their network (finance, for instance) is considered more sensitive than the rest and is pro- tected by another firewall. Both firewalls are of the transparent variety, and do no address translation. Most current installations of this kind do wish to hide Richardson [Page 2] INTERNET DRAFT April 1996 their internal addresses at the border firewall: this complication will be considered later. The security policy is that no traffic flows through the firewall without some kind of authentication. In particular, this means that outgoing traffic must be authenticated as well as incoming traffic. The policy on outbound traffic may be for accounting reasons, band- width reasons, or because of internal financial reasons (not every department may have bought into the internet connection). It is also assumed that the internal users do not necessarily have access to anything they wish: there might restrictions on destinations (e.g. www.playboy.com), or services (e.g. port 666, DOOM or IRC during the workday). |perimeter /-----\ | A / \ | / B------|bfw |--------R---------| i fw|----C \-------/ +----+ +-----+ | | figure 1 4. IPSEC usage 4.1 Case one Node A (an internal node, figure 1) wants to communicate securely with node B (an external node) using encrypted and authenticated IPSEC, with keys negotiated by Photuris or Oakley. Assume that user to server is desired rather than host to host. Also, assume that the required public keys are properly distributed. This is not a good assumption which will be revisited. A gets a socket and informs the security system about its desire or privacy and authentication. The key managements daemon is informed of the requirements, the user involved. The key management daemon sends a cookie request to node B. The border firewall will see packet. The packet is not addressed to the firewall, but rather to B. It is not surprising that a packet filter would return an ICMP Administratively denied message to node A. A second generation application layer firewall could similarily Richardson [Page 3] INTERNET DRAFT April 1996 return such a message, or might pass the packet to the key management program. A first generation application layer firewall would never see a packet addressed to B on the wire, since node A would have to have made special arrangements with the firewall already. Why isn't the firewall just configured to allow key management pack- ets through? There are two reasons: how does one know that the pack- ets are really key management packets? How can the firewall know that the responses are ligitimate responses? When address translation is added the problem gets even more complicated. The key management program on node A is notified that it will need to provide authentication on the cookie request. The key management pro- gram notifies the kernel of its requirements to authenticate itself to the firewall. The kernel sets up a new security association. To do so, the kernel needs to use the key management program. The key man- ager MUST be reentrant! Once the key manager has negotiated an authentication SPI it can then send a packet out to node B. It puts an AH header on the cookie request. This AH header authenticates node A's key manager to the firewall. The firewall *removes* the AH header from the packet, find- ing an encapsulated IP packet, it sends that packet onwards. The SPI on the border firewall will likely restrict what final destination and port is allowed. Node B now needs to respond. Many firewalls allow outgoing UDP by allowing a response packet. This is one way to manage things, and it may be appropriate for key exchange packets. There is a better way. When node A's key manager negotiates an SPI for sending packets out- wards, it should also provide a certificate permitting node B to send a response. When node B does send a response, it will also receive an ICMP Admin- istratively denied packet. Node B's key manager will have negotiate an SPI to use to send the response. The border firewall is willing to provide this service to node B because of the certificate that it has received from node A. At this point it possible for node A to send key protocol packets to node B, and node B can respond. A significant amount of state has been accumulated on all nodes. This is unfortunate: one of the goals of most key protocols is to keep as little state around until the key has been negotiated. This is to reduce the denial of service attacks that are otherwise possible. This is an important discussion point. Once the key exchange between A and B are done, an SPI can not be provided to the transport layer for the application to use. The Richardson [Page 4] INTERNET DRAFT April 1996 application will send out a packet (with AH and/or ESP headers) to node B. Again, the firewall will deny the packet. An AH header authenticating the authority of the application on node A to send to talk to node B is required. This may require a new key exchange between the fire- wall and node A: the key management SPI may not be reusable. This is another point of discussion. The authorization for node A to send packets to node B must also include a certificate for the firewall to prove that node B can send packets to node A. Pictorially this is (CR == cookie_request, CA=cookie_answer) node A border firewall node B cookie_request -> B <- ICMP admin deny cookie_request -> border firewall <- cookie_answer .... SPI for A->B traffic with firewall ... IP-AH-IP-CR -> B .... IP-CR -> B A <- CA ICMP admin deny -> B border firewall <- CR cookie_answer -> B .... SPI for B->A traffic with firewall ... A <- IP-CR ... border fw <- IP-AH-IP-CA .... SPI for A->B and B->A traffic between B<->A .... data A -> B <- ICMP admin deny ... SPI for data A->B, with certificate for return IP-AH-IP-data-A -> border firewall IP-data-A-> B A <- data B ICMP admin deny -> ... SPI for data B->A Richardson [Page 5] INTERNET DRAFT April 1996 A <- IP-data-B border firewall <- IP-AH-IP-data-B 4.2 Case two Node C wants to have a trusted session with node B. The first part proceeds much like the previous case. The packets goes out, the internal firewall refuses the key management packet, demanding authentication. An SPI is allocated to authenticate key management packets going from node C out. The packets then travel through the internal firewall and arrive at the external firewall. Again, an ICMP administratively denied packet is generated. It is addressed to node C. The internal firewall receives this packet, but there is no authentication headers on this packet. Why should the internal firewall permit the packet past it to node C? One possibility is that the internal firewall remembers the "virtual" circuit that caused the packet to be sent, and realizing what is going on, could permit the packet through. This doesn't present very good security, particularly against denial of service attacks. In this case, node C could engage in a key exchange with the border firewall (requiring case one again in recursion!), and prepend two AH headers: one for each firewall. A second possibility is that the internal firewall, realizing that it needs to create an authenticated session with the border firewall initiates the key management session using its credentials rather than the credentials of the internal host. A third possibility is that the internal firewall has a certificate from node C allowing it to setup a new SPI. This would allow the bor- der firewall to be aware of which internal node is requesting the connection. A fourth possibility is that the key management protocol used to establish the shared secret for an MD5 based AH header could be shared with the border firewall. This requires support for doing this in the key management protocol. While one might be willing to share a key that authenticates data from an internal node with the border gateway, one might be less willing to share this data with the border gateway at the remote site. This would be necessary to allow the packet "in" at the remote site. Richardson [Page 6] INTERNET DRAFT April 1996 5. Application layer versus packet filters In this specific case described, UDP (or IP for Oakley) level packets are being exchanged. Some application layer firewalls are able to relay UDP packets, but most refuse arbitrary IP packets. Even if the key exchanges were carried in UDP datagrams, if they were allowed to pass up to the application layer on the internal firewall, the inner AH header would likely be lost! The encapsulated packet would not in fact, be addressed to the internal firewall. This might not be a problem for many firewall architectures. The SPI would not be relevant to the internal firewall, so there would be no way to process that header. This suggests strongly that at the least, application layer firewalls will have to do some selective forwarding at the network layer based on AH headers. 6. BUGS: There is a lot more to be said 7. Security considerations This entire document addresses security concerns. 8. Author's Address Michael C. Richardson Milkyway Networks Corporation 2650 Queensview Drive, Suite 255 Ottawa, ON CANADA K2B 8H6 +1 613 596-5549 (email preferred) Email: mcr@milkyway.com Richardson [Page 7] INTERNET DRAFT April 1996 Richardson [Page 8]