[src/netbsd-1-5]: src/crypto/dist Remove pre-generated info files [from trunk].

[thorpej <thorpej%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/8919e7dff081
branches:  netbsd-1-5
changeset: 488190:8919e7dff081
user:      thorpej <thorpej%NetBSD.org@localhost>
date:      Wed Jun 21 04:15:44 2000 +0000

description:
Remove pre-generated info files [from trunk].

diffstat:

 crypto/dist/heimdal/doc/heimdal.info |  1009 ---------------
 crypto/dist/krb4/doc/kth-krb.info    |  2253 ----------------------------------
 2 files changed, 0 insertions(+), 3262 deletions(-)

diffs (truncated from 3270 to 300 lines):

diff -r 30768af13acc -r 8919e7dff081 crypto/dist/heimdal/doc/heimdal.info
--- a/crypto/dist/heimdal/doc/heimdal.info      Wed Jun 21 04:10:08 2000 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,1009 +0,0 @@
-This is heimdal.info, produced by makeinfo version 4.0 from
-heimdal.texi.
-
-INFO-DIR-SECTION Heimdal
-START-INFO-DIR-ENTRY
-* Heimdal: (heimdal).           The Kerberos 5 distribution from KTH
-END-INFO-DIR-ENTRY
-
-
-File: heimdal.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)
-
-Heimdal
-*******
-
-* Menu:
-
-* Introduction::
-* What is Kerberos?::
-* Building and Installing::
-* Setting up a realm::
-* Things in search for a better place::
-* Kerberos 4 issues::
-* Windows 2000 compatability::
-* Acknowledgments::
-
-
-File: heimdal.info,  Node: Introduction,  Next: What is Kerberos?,  Prev: Top,  Up: Top
-
-Introduction
-************
-
-What is Heimdal?
-================
-
-Heimdal is a free implementation of Kerberos 5. The goals are to:
-
-   * have an implementation that can be freely used by anyone
-
-   * be protocol compatible with existing implementations and, if not in
-     conflict, with RFC 1510 (and any future updated RFC)
-
-   * be reasonably compatible with the M.I.T Kerberos V5 API
-
-   * have support for Kerberos V5 over GSS-API (RFC1964)
-
-   * include the most important and useful application programs (rsh,
-     telnet, popper, etc.)
-
-   * include enough backwards compatibility with Kerberos V4
-
-Status
-======
-
-Heimdal has the following features (this does not mean any of this
-works):
-
-   * a stub generator and a library to encode/decode/whatever ASN.1/DER
-     stuff
-
-   * a `libkrb5' library that should be possible to get to work with
-     simple applications
-
-   * a GSS-API library that should have all the important functions for
-     building applications
-
-   * Eric Young's `libdes'
-
-   * `kinit', `klist', `kdestroy'
-
-   * `telnet', `telnetd'
-
-   * `rsh', `rshd'
-
-   * `popper', `push' (a movemail equivalent)
-
-   * `ftp', and `ftpd'
-
-   * a library `libkafs' for authenticating to AFS and a program
-     `afslog' that uses it
-
-   * some simple test programs
-
-   * a KDC that supports most things; optionally, it may also support
-     Kerberos V4 and kaserver,
-
-   * simple programs for distributing databases between a KDC master and
-     slaves
-
-   * a password changing daemon `kpasswdd', library functions for
-     changing passwords and a simple client
-
-   * some kind of administration system
-
-   * Kerberos V4 support in many of the applications.
-
-Bug reports
-===========
-
-If you find bugs in this software, make sure it is a genuine bug and not
-just a part of the code that isn't implemented.
-
-Bug reports should be sent to <heimdal-bugs%pdc.kth.se@localhost>. Please include
-information on what machine and operating system (including version)
-you are running, what you are trying to do, what happens, what you
-think should have happened, an example for us to repeat, the output you
-get when trying the example, and a patch for the problem if you have
-one. Please make any patches with `diff -u' or `diff -c'.
-
-Suggestions, comments and other non bug reports are also welcome.
-
-Mailing list
-============
-
-There are two mailing lists with talk about Heimdal.
-<heimdal-announce%sics.se@localhost> is a low-volume announcement list, while
-<heimdal-discuss%sics.se@localhost> is for general discussion.  Send a message to
-<majordomo%sics.se@localhost> to subscribe.
-
-
-File: heimdal.info,  Node: What is Kerberos?,  Next: Building and Installing,  Prev: Introduction,  Up: Top
-
-What is Kerberos?
-*****************
-
-     Now this Cerberus had three heads of dogs,
-             the tail of a dragon, and on his back the
-             heads of all sorts of snakes.
-             -- Pseudo-Apollodorus Library 2.5.12
-
-Kerberos is a system for authenticating users and services on a network.
-It is built upon the assumption that the network is "unsafe".  For
-example, data sent over the network can be eavesdropped and altered, and
-addresses can also be faked.  Therefore they cannot be used for
-authentication purposes.
-
-Kerberos is a trusted third-party service.  That means that there is a
-third party (the kerberos server) that is trusted by all the entities on
-the network (users and services, usually called "principals").  All
-principals share a secret password (or key) with the kerberos server and
-this enables principals to verify that the messages from the kerberos
-server are authentic.  Thus trusting the kerberos server, users and
-services can authenticate each other.
-
-Basic mechanism
-===============
-
-     *Note:* This discussion is about Kerberos version 4, but version 5
-     works similarly.
-
-In Kerberos, principals use "tickets" to prove that they are who they
-claim to be. In the following example, A is the initiator of the
-authentication exchange, usually a user, and B is the service that A
-wishes to use.
-
-To obtain a ticket for a specific service, A sends a ticket request to
-the kerberos server. The request contains A's and B's names (along with
-some other fields). The kerberos server checks that both A and B are
-valid principals.
-
-Having verified the validity of the principals, it creates a packet
-containing A's and B's names, A's network address (A<ADDR>), the
-current time (T<ISSUE>), the lifetime of the ticket (LIFE), and a
-secret "session key" (K<AB>). This packet is encrypted with B's secret
-key (K<B>).  The actual ticket (T<AB>) looks like this: ({A, B,
-A<ADDR>, T<ISSUE>, LIFE, K<AB>}K<B>).
-
-The reply to A consists of the ticket (T<AB>), B's name, the current
-time, the lifetime of the ticket, and the session key, all encrypted in
-A's secret key ({B, T<ISSUE>, LIFE, K<AB>, T<AB>}K<A>). A decrypts the
-reply and retains it for later use.
-
-
-Before sending a message to B, A creates an authenticator consisting of
-A's name, A's address, the current time, and a "checksum" chosen by A,
-all encrypted with the secret session key ({A, A<ADDR>, T<CURRENT>,
-CHECKSUM}K<AB>). This is sent together with the ticket received from
-the kerberos server to B.  Upon reception, B decrypts the ticket using
-B's secret key.  Since the ticket contains the session key that the
-authenticator was encrypted with, B can now also decrypt the
-authenticator. To verify that A really is A, B now has to compare the
-contents of the ticket with that of the authenticator. If everything
-matches, B now considers A as properly authenticated.
-
-Different attacks
-=================
-
-Impersonating A
----------------
-
-An impostor, C could steal the authenticator and the ticket as it is
-transmitted across the network, and use them to impersonate A. The
-address in the ticket and the authenticator was added to make it more
-difficult to perform this attack.  To succeed C will have to either use
-the same machine as A or fake the source addresses of the packets. By
-including the time stamp in the authenticator, C does not have much
-time in which to mount the attack.
-
-Impersonating B
----------------
-
-C can hijack B's network address, and when A sends her credentials, C
-just pretend to verify them. C can't be sure that she is talking to A.
-
-Defense strategies
-==================
-
-It would be possible to add a "replay cache" to the server side.  The
-idea is to save the authenticators sent during the last few minutes, so
-that B can detect when someone is trying to retransmit an already used
-message. This is somewhat impractical (mostly regarding efficiency),
-and is not part of Kerberos 4; MIT Kerberos 5 contains it.
-
-To authenticate B, A might request that B sends something back that
-proves that B has access to the session key. An example of this is the
-checksum that A sent as part of the authenticator. One typical
-procedure is to add one to the checksum, encrypt it with the session
-key and send it back to A.  This is called "mutual authentication".
-
-The session key can also be used to add cryptographic checksums to the
-messages sent between A and B (known as "message integrity").
-Encryption can also be added ("message confidentiality"). This is
-probably the best approach in all cases.
-
-Further reading
-===============
-
-The original paper on Kerberos from 1988 is `Kerberos: An
-Authentication Service for Open Network Systems', by Jennifer Steiner,
-Clifford Neuman and Jeffrey I. Schiller.
-
-A less technical description can be found in `Designing an
-Authentication System: a Dialogue in Four Scenes' by Bill Bryant, also
-from 1988.
-
-These documents can be found on our web-page at
-<http://www.pdc.kth.se/kth-krb/>.
-
-
-File: heimdal.info,  Node: Building and Installing,  Next: Setting up a realm,  Prev: What is Kerberos?,  Up: Top
-
-Building and Installing
-***********************
-
-Heimdal uses GNU Autoconf to configure for specific hosts, and GNU
-Automake to manage makefiles. If this is new to you, the short
-instruction is to run the `configure' script in the top level
-directory, and when that finishes `make'.
-
-If you want to build the distribution in a different directory from the
-source directory, you will need a make that implements VPATH correctly,
-such as GNU make.
-
-You will need to build the distribution:
-
-   * A compiler that supports a "loose" ANSI C mode, such as `gcc'.
-
-   * lex or flex
-
-   * awk
-
-   * yacc or bison
-
-   * a socket library
-
-   * NDBM or Berkeley DB for building the server side.
-
-When everything is built, you can install by doing `make install'. The
-default location for installation is `/usr/heimdal', but this can be
-changed by running `configure' with `--prefix=/some/other/place'.
-
-If you need to change the default behavior, configure understands the
-following options:
-
-`--without-berkeley-db'
-     DB is preferred before NDBM, but if you for some reason want to
-     use NDBM instead, you can use this option.
-
-`--with-krb4=`dir''
-     Gives the location of Kerberos 4 libraries and headers. This
-     enables Kerberos 4 support in the applications (telnet, rsh,
-     popper, etc) and the KDC. It is automatically check for in
-     `/usr/athena'. If you keep libraries and headers in different
-     places, you can instead give the path to each with the
-     `--with-krb4-lib=`dir'', and `--with-krb4-include=`dir'' options.
-
-     You will need a fairly recent version of our Kerberos 4
-     distribution for `rshd' and `popper' to support version 4 clients.
-
-`--enable-kaserver'
-     Enables experimental kaserver support in the KDC. This is the
-     protocol used by the "KDC" in AFS. Requires Kerberos 4 support.
-
-`--enable-kaserver-db'
-     Enables experimental support for reading kaserver databases in
-     hprop.  This is useful when migrating from a kaserver to a Heimdal
-     KDC.