diff options
author | nectar <nectar@FreeBSD.org> | 2005-02-24 22:14:04 +0000 |
---|---|---|
committer | nectar <nectar@FreeBSD.org> | 2005-02-24 22:14:04 +0000 |
commit | 412870c33635bdaae3fb6a6c2d59a85c65b85b2f (patch) | |
tree | b14fa2308f0b719da9f5477f0b8d446c5572dc9b /crypto/heimdal/doc/standardisation/draft-foo3 | |
parent | bfc5316dea97d244a21b45ed0dce56f39074ba1b (diff) | |
download | FreeBSD-src-412870c33635bdaae3fb6a6c2d59a85c65b85b2f.zip FreeBSD-src-412870c33635bdaae3fb6a6c2d59a85c65b85b2f.tar.gz |
Clean up the Heimdal vendor branch by removing files not included in
any import for several years.
If memory serves, this was
Suggested by: ru
an awfully long time ago-- sorry for the delay!
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-foo3')
-rw-r--r-- | crypto/heimdal/doc/standardisation/draft-foo3 | 227 |
1 files changed, 0 insertions, 227 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-foo3 b/crypto/heimdal/doc/standardisation/draft-foo3 deleted file mode 100644 index 2b8b7bb..0000000 --- a/crypto/heimdal/doc/standardisation/draft-foo3 +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -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] - |