doc/standardisation/draft-foo3

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                   Assar Westerlund
   8 <draft-ietf-cat-krb5-firewalls.txt>                                 SICS
   9 Internet-Draft                                          Johan Danielsson
  10 November, 1997                                                  PDC, KTH
  11 Expire in six months
  12
  13                          Kerberos vs firewalls
  14
  15 Status of this Memo
  16
  17    This document is an Internet-Draft.  Internet-Drafts are working
  18    documents of the Internet Engineering Task Force (IETF), its areas,
  19    and its working groups.  Note that other groups may also distribute
  20    working documents as Internet-Drafts.
  21
  22    Internet-Drafts are draft documents valid for a maximum of six months
  23    and may be updated, replaced, or obsoleted by other documents at any
  24    time.  It is inappropriate to use Internet- Drafts as reference
  25    material or to cite them other than as "work in progress."
  26
  27    To view the entire list of current Internet-Drafts, please check the
  28    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  29    Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
  30    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31    ftp.isi.edu (US West Coast).
  32
  33    Distribution of this memo is unlimited.  Please send comments to the
  34    <cat-ietf@mit.edu> mailing list.
  35
  36 Abstract
  37
  38 Introduction
  39
  40    Kerberos[RFC1510] is a protocol for authenticating parties
  41    communicating over insecure networks.
  42
  43    Firewalling is a technique for achieving an illusion of security by
  44    putting restrictions on what kinds of packets and how these are sent
  45    between the internal (so called "secure") network and the global (or
  46    "insecure") Internet.
  47
  48 Definitions
  49
  50    client: the user, process, and host acquiring tickets from the KDC
  51    and authenticating itself to the kerberised server.
  52
  53    KDC: the Kerberos Key Distribution Center
  54
  55
  56
  57
  58 Westerlund, Danielsson                                          [Page 1]
  59 \f
  60 Internet Draft           Kerberos vs firewalls            November, 1997
  61
  62
  63    Kerberised server: the server using Kerberos to authenticate the
  64    client, for example telnetd.
  65
  66 Firewalls
  67
  68    A firewall is usually placed between the "inside" and the "outside"
  69    networks, and is supposed to protect the inside from the evils on the
  70    outside.  There are different kinds of firewalls.  The main
  71    differences are in the way they forward packets.
  72
  73    o\b+  The most straight forward type is the one that just imposes
  74       restrictions on incoming packets. Such a firewall could be
  75       described as a router that filters packets that match some
  76       criteria.
  77
  78    o\b+  They may also "hide" some or all addresses on the inside of the
  79       firewall, replacing the addresses in the outgoing packets with the
  80       address of the firewall (aka network address translation, or NAT).
  81       NAT can also be used without any packet filtering, for instance
  82       when you have more than one host sharing a single address (for
  83       example, with a dialed-in PPP connection).
  84
  85    There are also firewalls that does NAT both on the inside and the
  86    outside (a server on the inside will see this as a connection from
  87    the firewall).
  88
  89    o\b+  A third type is the proxy type firewall, that parses the contents
  90       of the packets, basically acting as a server to the client, and as
  91       a client to the server (man-in-the-middle). If Kerberos is to be
  92       used with this kind of firewall, a protocol module that handles
  93       KDC requests has to be written.
  94
  95    This type of firewall might also cause extra trouble when used with
  96    kerberised versions of protocols that the proxy understands, in
  97    addition to the ones mentioned below. This is the case with the FTP
  98    Security Extensions [RFC2228], that adds a new set of commands to the
  99    FTP protocol [RFC959], for integrity, confidentiality, and privacy
 100    protecting commands. When transferring data, the FTP protocol uses a
 101    separate data channel, and an FTP proxy will have to look out for
 102    commands that start a data transfer. If all commands are encrypted,
 103    this is impossible. A protocol that doesn't suffer from this is the
 104    Telnet Authentication Option [RFC1416] that does all authentication
 105    and encryption in-bound.
 106
 107 Scenarios
 108
 109    Here the different scenarios we have considered are described, the
 110    problems they introduce and the proposed ways of solving them.
 111
 112
 113
 114 Westerlund, Danielsson                                          [Page 2]
 115 \f
 116 Internet Draft           Kerberos vs firewalls            November, 1997
 117
 118
 119    Combinations of these can also occur.
 120
 121  Client behind firewall
 122
 123    This is the most typical and common scenario.  First of all the
 124    client needs some way of communicating with the KDC.  This can be
 125    done with whatever means and is usually much simpler when the KDC is
 126    able to communicate over TCP.
 127
 128    Apart from that, the client needs to be sure that the ticket it will
 129    acquire from the KDC can be used to authenticate to a server outside
 130    its firewall.  For this, it needs to add the address(es) of potential
 131    firewalls between itself and the KDC/server, to the list of its own
 132    addresses when requesting the ticket.  We are not aware of any
 133    protocol for determining this set of addresses, thus this will have
 134    to be manually configured in the client.
 135
 136    The client could also request a ticket with no addresses, but some
 137    KDCs and servers might not accept such a ticket.
 138
 139    With the ticket in possession, communication with the kerberised
 140    server will not need to be any different from communicating between a
 141    non-kerberised client and server.
 142
 143  Kerberised server behind firewall
 144
 145    The kerberised server does not talk to the KDC at all so nothing
 146    beyond normal firewall-traversal techniques for reaching the server
 147    itself needs to be applied.
 148
 149    The kerberised server needs to be able to retrieve the original
 150    address (before its firewall) that the request was sent for.  If this
 151    is done via some out-of-band mechanism or it's directly able to see
 152    it doesn't matter.
 153
 154  KDC behind firewall
 155
 156    The same restrictions applies for a KDC as for any other server.
 157
 158 Specification
 159
 160 Security considerations
 161
 162    This memo does not introduce any known security considerations in
 163    addition to those mentioned in [RFC1510].
 164
 165 References
 166
 167
 168
 169
 170 Westerlund, Danielsson                                          [Page 3]
 171 \f
 172 Internet Draft           Kerberos vs firewalls            November, 1997
 173
 174
 175    [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
 176    RFC 969, October 1985
 177
 178    [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
 179    February 1993.
 180
 181    [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
 182    Authentication Service (V5)", RFC 1510, September 1993.
 183
 184    [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
 185    RFC2228, October 1997.
 186
 187 Authors' Addresses
 188
 189    Assar Westerlund
 190    Swedish Institute of Computer Science
 191    Box 1263
 192    S-164 29  KISTA
 193    Sweden
 194
 195    Phone: +46-8-7521526
 196    Fax:   +46-8-7517230
 197    EMail: assar@sics.se
 198
 199    Johan Danielsson
 200    PDC, KTH
 201    S-100 44  STOCKHOLM
 202    Sweden
 203
 204    Phone: +46-8-7907885
 205    Fax:   +46-8-247784
 206    EMail: joda@pdc.kth.se
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Westerlund, Danielsson                                          [Page 4]
 227 \f