summaryrefslogtreecommitdiffstats
path: root/crypto/heimdal/doc/standardisation/draft-foo3
diff options
context:
space:
mode:
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-foo3')
-rw-r--r--crypto/heimdal/doc/standardisation/draft-foo3227
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]
-
OpenPOWER on IntegriCloud