1
2
3
4
5
6
7Network Working Group                                   Assar Westerlund
8<draft-ietf-cat-krb5-firewalls.txt>                                 SICS
9Internet-Draft                                          Johan Danielsson
10November, 1997                                                  PDC, KTH
11Expire in six months
12
13                         Kerberos vs firewalls
14
15Status 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
36Abstract
37
38Introduction
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
48Definitions
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
58Westerlund, Danielsson                                          [Page 1]
59
60Internet Draft           Kerberos vs firewalls            November, 1997
61
62
63   Kerberised server: the server using Kerberos to authenticate the
64   client, for example telnetd.
65
66Firewalls
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+  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+  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+  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
107Scenarios
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
114Westerlund, Danielsson                                          [Page 2]
115
116Internet 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
158Specification
159
160Security considerations
161
162   This memo does not introduce any known security considerations in
163   addition to those mentioned in [RFC1510].
164
165References
166
167
168
169
170Westerlund, Danielsson                                          [Page 3]
171
172Internet 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
187Authors' 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
226Westerlund, Danielsson                                          [Page 4]
227
228