Add heimdal-0.6.3
[dragonfly.git] / crypto / heimdal-0.6.3 / 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