7
Network Working Group Assar Westerlund
8
<draft-ietf-cat-krb5-firewalls.txt> SICS
9
Internet-Draft Johan Danielsson
10
November, 1997 PDC, KTH
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.
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."
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).
33
Distribution of this memo is unlimited. Please send comments to the
34
<cat-ietf@mit.edu> mailing list.
40
Kerberos[RFC1510] is a protocol for authenticating parties
41
communicating over insecure networks.
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
50
client: the user, process, and host acquiring tickets from the KDC
51
and authenticating itself to the kerberised server.
53
KDC: the Kerberos Key Distribution Center
58
Westerlund, Danielsson [Page 1]
60
Internet Draft Kerberos vs firewalls November, 1997
63
Kerberised server: the server using Kerberos to authenticate the
64
client, for example telnetd.
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.
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
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).
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
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.
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.
109
Here the different scenarios we have considered are described, the
110
problems they introduce and the proposed ways of solving them.
114
Westerlund, Danielsson [Page 2]
116
Internet Draft Kerberos vs firewalls November, 1997
119
Combinations of these can also occur.
121
Client behind firewall
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.
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.
136
The client could also request a ticket with no addresses, but some
137
KDCs and servers might not accept such a ticket.
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.
143
Kerberised server behind firewall
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.
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
156
The same restrictions applies for a KDC as for any other server.
160
Security considerations
162
This memo does not introduce any known security considerations in
163
addition to those mentioned in [RFC1510].
170
Westerlund, Danielsson [Page 3]
172
Internet Draft Kerberos vs firewalls November, 1997
175
[RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
176
RFC 969, October 1985
178
[RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
181
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
182
Authentication Service (V5)", RFC 1510, September 1993.
184
[RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
185
RFC2228, October 1997.
190
Swedish Institute of Computer Science
206
EMail: joda@pdc.kth.se
226
Westerlund, Danielsson [Page 4]
added
removed
doc/standardisation/draft-foo3
