heimdal/doc/standardisation/draft-foo3

Network Working Group                                   Assar Westerlund
<draft-ietf-cat-krb5-firewalls.txt>                                 SICS
Internet-Draft                                          Johan Danielsson
November, 1997                                                  PDC, KTH
Expire in six months

                         Kerberos vs firewalls

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents 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
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.  Please send comments to the
   <cat-ietf@mit.edu> mailing list.

Abstract

Introduction

   Kerberos[RFC1510] is a protocol for authenticating parties
   communicating over insecure networks.

   Firewalling is a technique for achieving an illusion of security by
   putting restrictions on what kinds of packets and how these are sent
   between the internal (so called "secure") network and the global (or
   "insecure") Internet.

Definitions

   client: the user, process, and host acquiring tickets from the KDC
   and authenticating itself to the kerberised server.

   KDC: the Kerberos Key Distribution Center




Westerlund, Danielsson                                          [Page 1]

Internet Draft           Kerberos vs firewalls            November, 1997


   Kerberised server: the server using Kerberos to authenticate the
   client, for example telnetd.

Firewalls

   A firewall is usually placed between the "inside" and the "outside"
   networks, and is supposed to protect the inside from the evils on the
   outside.  There are different kinds of firewalls.  The main
   differences are in the way they forward packets.

   o+  The most straight forward type is the one that just imposes
      restrictions on incoming packets. Such a firewall could be
      described as a router that filters packets that match some
      criteria.

   o+  They may also "hide" some or all addresses on the inside of the
      firewall, replacing the addresses in the outgoing packets with the
      address of the firewall (aka network address translation, or NAT).
      NAT can also be used without any packet filtering, for instance
      when you have more than one host sharing a single address (for
      example, with a dialed-in PPP connection).

   There are also firewalls that does NAT both on the inside and the
   outside (a server on the inside will see this as a connection from
   the firewall).

   o+  A third type is the proxy type firewall, that parses the contents
      of the packets, basically acting as a server to the client, and as
      a client to the server (man-in-the-middle). If Kerberos is to be
      used with this kind of firewall, a protocol module that handles
      KDC requests has to be written.

   This type of firewall might also cause extra trouble when used with
   kerberised versions of protocols that the proxy understands, in
   addition to the ones mentioned below. This is the case with the FTP
   Security Extensions [RFC2228], that adds a new set of commands to the
   FTP protocol [RFC959], for integrity, confidentiality, and privacy
   protecting commands. When transferring data, the FTP protocol uses a
   separate data channel, and an FTP proxy will have to look out for
   commands that start a data transfer. If all commands are encrypted,
   this is impossible. A protocol that doesn't suffer from this is the
   Telnet Authentication Option [RFC1416] that does all authentication
   and encryption in-bound.

Scenarios

   Here the different scenarios we have considered are described, the
   problems they introduce and the proposed ways of solving them.



Westerlund, Danielsson                                          [Page 2]

Internet Draft           Kerberos vs firewalls            November, 1997


   Combinations of these can also occur.

 Client behind firewall

   This is the most typical and common scenario.  First of all the
   client needs some way of communicating with the KDC.  This can be
   done with whatever means and is usually much simpler when the KDC is
   able to communicate over TCP.

   Apart from that, the client needs to be sure that the ticket it will
   acquire from the KDC can be used to authenticate to a server outside
   its firewall.  For this, it needs to add the address(es) of potential
   firewalls between itself and the KDC/server, to the list of its own
   addresses when requesting the ticket.  We are not aware of any
   protocol for determining this set of addresses, thus this will have
   to be manually configured in the client.

   The client could also request a ticket with no addresses, but some
   KDCs and servers might not accept such a ticket.

   With the ticket in possession, communication with the kerberised
   server will not need to be any different from communicating between a
   non-kerberised client and server.

 Kerberised server behind firewall

   The kerberised server does not talk to the KDC at all so nothing
   beyond normal firewall-traversal techniques for reaching the server
   itself needs to be applied.

   The kerberised server needs to be able to retrieve the original
   address (before its firewall) that the request was sent for.  If this
   is done via some out-of-band mechanism or it's directly able to see
   it doesn't matter.

 KDC behind firewall

   The same restrictions applies for a KDC as for any other server.

Specification

Security considerations

   This memo does not introduce any known security considerations in
   addition to those mentioned in [RFC1510].

References




Westerlund, Danielsson                                          [Page 3]

Internet Draft           Kerberos vs firewalls            November, 1997


   [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
   RFC 969, October 1985

   [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
   February 1993.

   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
   Authentication Service (V5)", RFC 1510, September 1993.

   [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
   RFC2228, October 1997.

Authors' Addresses

   Assar Westerlund
   Swedish Institute of Computer Science
   Box 1263
   S-164 29  KISTA
   Sweden

   Phone: +46-8-7521526
   Fax:   +46-8-7517230
   EMail: assar@sics.se

   Johan Danielsson
   PDC, KTH
   S-100 44  STOCKHOLM
   Sweden

   Phone: +46-8-7907885
   Fax:   +46-8-247784
   EMail: joda@pdc.kth.se



















Westerlund, Danielsson                                          [Page 4]