1 .\" even if this file is called .ms, it's using the me macros.
2 .\" to format try something like `nroff -me'
8 .\" make sure footnotes produce the right thing with nroff
11 .ds { \v'-0.4m'\x'\\n(0x=0*-0.2m'\s-3
19 .ds * \\*{\\n($f\\*}\k*
21 .fo 'Westerlund, Danielsson''[Page %]'
26 .\" heading indent per level
38 .\" line length 16cm and page length 25cm (~10 inches)
43 Network Working Group Assar Westerlund
44 <draft-ietf-cat-krb5-firewalls.txt> SICS
45 Internet-Draft Johan Danielsson
50 .\" page header, has to be set here so it won't appear on page 1
51 .he 'Internet Draft'Kerberos vs firewalls'\*(RH'
53 .b "Kerberos vs firewalls"
55 .HH 1 "Status of this Memo"
57 This document is an Internet-Draft. Internet-Drafts are working
58 documents of the Internet Engineering Task Force (IETF), its areas,
59 and its working groups. Note that other groups may also distribute
60 working documents as Internet-Drafts.
62 Internet-Drafts are draft documents valid for a maximum of six months
63 and may be updated, replaced, or obsoleted by other documents at any
64 time. It is inappropriate to use Internet- Drafts as reference
65 material or to cite them other than as \*(lqwork in progress.\*(rq
67 To view the entire list of current Internet-Drafts, please check the
68 \*(lq1id-abstracts.txt\*(rq listing contained in the Internet-Drafts
69 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
70 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
71 ftp.isi.edu (US West Coast).
73 Distribution of this memo is unlimited. Please send comments to the
74 <cat-ietf@mit.edu> mailing list.
77 Kerberos and firewalls both deal with security, but doesn't get along
78 very well. This memo discusses ways to use Kerberos in a firewalled
85 Kohl, J. and Neuman, C., \*(lqThe Kerberos Network Authentication
86 Service (V5)\*(rq, RFC 1510, September 1993.
88 is a protocol for authenticating parties communicating over insecure
89 networks. Firewalling is a technique for achieving an illusion of
90 security by putting restrictions on what kinds of packets and how
91 these are sent between the internal (so called \*(lqsecure\*(rq)
92 network and the global (or \*(lqinsecure\*(rq) Internet. The problems
93 with firewalls are many, but to name a few:
95 Firewalls usually doesn't allow people to use UDP. The reason for this
96 is that UDP is (by firewall advocates) considered insecure. This
97 belief is probably based on the fact that many \*(lqinsecure\*(rq
98 protocols (like NFS) use UDP. UDP packets are also considered easy to
101 Firewalls usually doesn't allow people to connect to arbitrary ports,
102 such as the ports used when talking to the KDC.
104 In many non-computer organisations, the computer staff isn't what
105 you'd call \*(lqwizards\*(rq; a typical case is an academic
106 institution, where someone is taking care of the computers part time,
107 and is doing research the rest of the time. Adding a complex device
108 like a firewall to an environment like this, often leads to poorly run
109 systems that is more a hindrance for the legitimate users than to
112 The easiest way to deal with firewalls is to ignore them, however in
113 some cases this just isn't possible. You might have users that are
114 stuck behind a firewall, but also has to access your system, or you
115 might find yourself behind a firewall, for instance when out
118 To make it possible for people to use Kerberos from behind a firewall,
119 there are several things to consider.
122 Add things to do when stuck behind a firewall, like talking about the
123 problem with local staff, making them open some port in the firewall,
124 using some other port, or proxy.
129 A firewall is usually placed between the \*(lqinside\*(rq and the
130 \*(lqoutside\*(rq networks, and is supposed to protect the inside from the
131 evils on the outside. There are different kinds of firewalls. The
132 main differences are in the way they forward (or doesn't) packets.
134 The most straight forward type is the one that just imposes
135 restrictions on incoming packets. Such a firewall could be described
136 as a router that filters packets that match some criteria.
138 They may also \*(lqhide\*(rq some or all addresses on the inside of the
139 firewall, replacing the addresses in the outgoing packets with the
140 address of the firewall (aka network address translation, or NAT). NAT
141 can also be used without any packet filtering, for instance when you
142 have more than one host sharing a single address (e.g with a dialed-in
145 There are also firewalls that does NAT both on the inside and the
146 outside (a server on the inside will see this as a connection from the
149 A third type is the proxy type firewall, that parses the contents of
150 the packets, basically acting as a server to the client, and as a
151 client to the server (man-in-the-middle). If Kerberos is to be used
152 with this kind of firewall, a protocol module that handles KDC
153 requests has to be written\**.
155 \**Instead of writing a new module for Kerberos, it can be possible to
156 hitch a ride on some other protocol, that's already beeing handled by
160 The last type of firewall might also cause extra trouble when used
161 with kerberised versions of protocols that the proxy understands, in
162 addition to the ones mentioned below. This is the case with the FTP
163 Security Extensions [RFC2228],
166 Horowitz, M. and Lunt, S., \*(lqFTP Security Extensions\*(rq, RFC2228,
169 that adds a new set of commands to the FTP protocol [RFC959],
171 [RFC959] Postel, J. and Reynolds, J., \*(lqFile Transfer Protocol
172 (FTP)\*(rq, RFC 969, October 1985
174 for integrity, confidentiality, and privacy protecting commands, and
175 data. When transferring data, the FTP protocol uses a separate data
176 channel, and an FTP proxy will have to look out for commands that
177 start a data transfer. If all commands are encrypted, this is
178 impossible. A protocol that doesn't suffer from this is the Telnet
179 Authentication Option [RFC1416]
182 Borman, D., \*(lqTelnet Authentication Option\*(rq, RFC 1416, February
186 authentication and encryption in-bound.
189 Here the different scenarios we have considered are described, the
190 problems they introduce and the proposed ways of solving them.
191 Combinations of these can also occur.
192 .HH 2 "Client behind firewall"
194 This is the most typical and common scenario. First of all the client
195 needs some way of communicating with the KDC. This can be done with
196 whatever means and is usually much simpler when the KDC is able to
197 communicate over TCP.
199 Apart from that, the client needs to be sure that the ticket it will
200 acquire from the KDC can be used to authenticate to a server outside
201 its firewall. For this, it needs to add the address(es) of potential
202 firewalls between itself and the KDC/server, to the list of its own
203 addresses when requesting the ticket. We are not aware of any
204 protocol for determining this set of addresses, thus this will have to
205 be manually configured in the client.
207 The client could also request a ticket with no addresses. This is not
208 a recommended way to solve this problem. The address was put into the
209 ticket to make it harder to use a stolen ticket. A ticket without
210 addresses will therefore be less \*(lqsecure.\*(rq RFC1510 also says that
211 the KDC may refuse to issue, and the server may refuse to accept an
214 With the ticket in possession, communication with the kerberised
215 server will not need to be any different from communicating between a
216 non-kerberised client and server.
217 .HH 2 "Kerberised server behind firewall"
219 The kerberised server does not talk to the KDC at all, so nothing
220 beyond normal firewall-traversal techniques for reaching the server
221 itself needs to be applied.
223 If the firewall rewrites the clients address, the server will have to
224 use some other (possibly firewall specific) protocol to retrieve the
225 original address. If this is not possible, the address field will have
226 to be ignored. This has the same effect as if there were no addresses
227 in the ticket (see the discussion above).
228 .HH 2 "KDC behind firewall"
230 The KDC is in this respect basically just like any other server.
231 .\" .uh "Specification"
232 .HH 1 "Security considerations"
234 Since the whole network behind a NAT-type firewall looks like one
235 computer from the outside, any security added by the addresses in the
240 .HH 1 "Authors' Addresses"
244 Swedish Institute of Computer Science
253 Center for Parallel Computers
259 EMail: joda@pdc.kth.se
projects / dragonfly.git / blob