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--<internet \ +----+ / +-----+
\ >----|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]