heimdal: Vendor import f62e2f278vendor/heimdal/7.8.0-2023-06-10-f62e2f278vendor/heimdal

Heimdal 7.8.0 does not support OpenSSL 3.0. 7.9.0 will but it hasn't
been released yet. We are importing f62e2f278 for its OpenSSL 3.0
support.

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/standardisation/draft-foo3 b/doc/standardisation/draft-foo3
new file mode 100644
index 000000000000..2b8b7bb5775c
--- /dev/null
+++ b/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]
+