228 lines
7.1 KiB
Plaintext
228 lines
7.1 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group Assar Westerlund
|
||
<draft-ietf-cat-krb5-firewalls.txt> SICS
|
||
Internet-Draft Johan Danielsson
|
||
November, 1997 PDC, KTH
|
||
Expire in six months
|
||
|
||
Kerberos vs firewalls
|
||
|
||
Status of this Memo
|
||
|
||
This document is an Internet-Draft. Internet-Drafts are working
|
||
documents of the Internet Engineering Task Force (IETF), its areas,
|
||
and its working groups. Note that other groups may also distribute
|
||
working documents as Internet-Drafts.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet- Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
To view the entire list of current Internet-Drafts, please check the
|
||
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
|
||
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
|
||
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
|
||
ftp.isi.edu (US West Coast).
|
||
|
||
Distribution of this memo is unlimited. Please send comments to the
|
||
<cat-ietf@mit.edu> mailing list.
|
||
|
||
Abstract
|
||
|
||
Introduction
|
||
|
||
Kerberos[RFC1510] is a protocol for authenticating parties
|
||
communicating over insecure networks.
|
||
|
||
Firewalling is a technique for achieving an illusion of security by
|
||
putting restrictions on what kinds of packets and how these are sent
|
||
between the internal (so called "secure") network and the global (or
|
||
"insecure") Internet.
|
||
|
||
Definitions
|
||
|
||
client: the user, process, and host acquiring tickets from the KDC
|
||
and authenticating itself to the kerberised server.
|
||
|
||
KDC: the Kerberos Key Distribution Center
|
||
|
||
|
||
|
||
|
||
Westerlund, Danielsson [Page 1]
|
||
|
||
Internet Draft Kerberos vs firewalls November, 1997
|
||
|
||
|
||
Kerberised server: the server using Kerberos to authenticate the
|
||
client, for example telnetd.
|
||
|
||
Firewalls
|
||
|
||
A firewall is usually placed between the "inside" and the "outside"
|
||
networks, and is supposed to protect the inside from the evils on the
|
||
outside. There are different kinds of firewalls. The main
|
||
differences are in the way they forward packets.
|
||
|
||
o+ The most straight forward type is the one that just imposes
|
||
restrictions on incoming packets. Such a firewall could be
|
||
described as a router that filters packets that match some
|
||
criteria.
|
||
|
||
o+ They may also "hide" some or all addresses on the inside of the
|
||
firewall, replacing the addresses in the outgoing packets with the
|
||
address of the firewall (aka network address translation, or NAT).
|
||
NAT can also be used without any packet filtering, for instance
|
||
when you have more than one host sharing a single address (for
|
||
example, with a dialed-in PPP connection).
|
||
|
||
There are also firewalls that does NAT both on the inside and the
|
||
outside (a server on the inside will see this as a connection from
|
||
the firewall).
|
||
|
||
o+ A third type is the proxy type firewall, that parses the contents
|
||
of the packets, basically acting as a server to the client, and as
|
||
a client to the server (man-in-the-middle). If Kerberos is to be
|
||
used with this kind of firewall, a protocol module that handles
|
||
KDC requests has to be written.
|
||
|
||
This type of firewall might also cause extra trouble when used with
|
||
kerberised versions of protocols that the proxy understands, in
|
||
addition to the ones mentioned below. This is the case with the FTP
|
||
Security Extensions [RFC2228], that adds a new set of commands to the
|
||
FTP protocol [RFC959], for integrity, confidentiality, and privacy
|
||
protecting commands. When transferring data, the FTP protocol uses a
|
||
separate data channel, and an FTP proxy will have to look out for
|
||
commands that start a data transfer. If all commands are encrypted,
|
||
this is impossible. A protocol that doesn't suffer from this is the
|
||
Telnet Authentication Option [RFC1416] that does all authentication
|
||
and encryption in-bound.
|
||
|
||
Scenarios
|
||
|
||
Here the different scenarios we have considered are described, the
|
||
problems they introduce and the proposed ways of solving them.
|
||
|
||
|
||
|
||
Westerlund, Danielsson [Page 2]
|
||
|
||
Internet Draft Kerberos vs firewalls November, 1997
|
||
|
||
|
||
Combinations of these can also occur.
|
||
|
||
Client behind firewall
|
||
|
||
This is the most typical and common scenario. First of all the
|
||
client needs some way of communicating with the KDC. This can be
|
||
done with whatever means and is usually much simpler when the KDC is
|
||
able to communicate over TCP.
|
||
|
||
Apart from that, the client needs to be sure that the ticket it will
|
||
acquire from the KDC can be used to authenticate to a server outside
|
||
its firewall. For this, it needs to add the address(es) of potential
|
||
firewalls between itself and the KDC/server, to the list of its own
|
||
addresses when requesting the ticket. We are not aware of any
|
||
protocol for determining this set of addresses, thus this will have
|
||
to be manually configured in the client.
|
||
|
||
The client could also request a ticket with no addresses, but some
|
||
KDCs and servers might not accept such a ticket.
|
||
|
||
With the ticket in possession, communication with the kerberised
|
||
server will not need to be any different from communicating between a
|
||
non-kerberised client and server.
|
||
|
||
Kerberised server behind firewall
|
||
|
||
The kerberised server does not talk to the KDC at all so nothing
|
||
beyond normal firewall-traversal techniques for reaching the server
|
||
itself needs to be applied.
|
||
|
||
The kerberised server needs to be able to retrieve the original
|
||
address (before its firewall) that the request was sent for. If this
|
||
is done via some out-of-band mechanism or it's directly able to see
|
||
it doesn't matter.
|
||
|
||
KDC behind firewall
|
||
|
||
The same restrictions applies for a KDC as for any other server.
|
||
|
||
Specification
|
||
|
||
Security considerations
|
||
|
||
This memo does not introduce any known security considerations in
|
||
addition to those mentioned in [RFC1510].
|
||
|
||
References
|
||
|
||
|
||
|
||
|
||
Westerlund, Danielsson [Page 3]
|
||
|
||
Internet Draft Kerberos vs firewalls November, 1997
|
||
|
||
|
||
[RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
|
||
RFC 969, October 1985
|
||
|
||
[RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
|
||
February 1993.
|
||
|
||
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
|
||
Authentication Service (V5)", RFC 1510, September 1993.
|
||
|
||
[RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
|
||
RFC2228, October 1997.
|
||
|
||
Authors' Addresses
|
||
|
||
Assar Westerlund
|
||
Swedish Institute of Computer Science
|
||
Box 1263
|
||
S-164 29 KISTA
|
||
Sweden
|
||
|
||
Phone: +46-8-7521526
|
||
Fax: +46-8-7517230
|
||
EMail: assar@sics.se
|
||
|
||
Johan Danielsson
|
||
PDC, KTH
|
||
S-100 44 STOCKHOLM
|
||
Sweden
|
||
|
||
Phone: +46-8-7907885
|
||
Fax: +46-8-247784
|
||
EMail: joda@pdc.kth.se
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Westerlund, Danielsson [Page 4]
|
||
|