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]