diff options
author | markm <markm@FreeBSD.org> | 2000-01-09 20:58:00 +0000 |
---|---|---|
committer | markm <markm@FreeBSD.org> | 2000-01-09 20:58:00 +0000 |
commit | 5f68254a360fdb4f3ebc30f6ad6507556425dd0a (patch) | |
tree | a96b9cd24173c10bba3fd7e2acf5d68e5bb0773e /crypto/heimdal/doc/standardisation/draft-foo3 | |
parent | d88c9767e1793993cc2242ccfb9a8ba002a061c6 (diff) | |
parent | 4ecbd6db44d79348bc815f31096e53104f50838b (diff) | |
download | FreeBSD-src-5f68254a360fdb4f3ebc30f6ad6507556425dd0a.zip FreeBSD-src-5f68254a360fdb4f3ebc30f6ad6507556425dd0a.tar.gz |
This commit was generated by cvs2svn to compensate for changes in r55682,
which included commits to RCS files with non-trunk default branches.
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-foo3')
-rw-r--r-- | crypto/heimdal/doc/standardisation/draft-foo3 | 227 |
1 files changed, 227 insertions, 0 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-foo3 b/crypto/heimdal/doc/standardisation/draft-foo3 new file mode 100644 index 0000000..2b8b7bb --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-foo3 @@ -0,0 +1,227 @@ + + + + + + +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] + |