This commit was manufactured by cvs2svn to create tagvendor/heimdal/cvs-20020217

'heimdal-vendor-crypto-cvs_20020217'.

66 files changed, 0 insertions, 15263 deletions

diff --git a/crypto/heimdal/admin/ktutil.cat8 b/crypto/heimdal/admin/ktutil.cat8
deleted file mode 100644
index f349f610f052..000000000000
--- a/crypto/heimdal/admin/ktutil.cat8
+++ /dev/null
@@ -1,71 +0,0 @@
-
-KTUTIL(8)                UNIX System Manager's Manual                KTUTIL(8)
-
-NNAAMMEE
-     kkttuuttiill - manage Kerberos keytabs
-
-SSYYNNOOPPSSIISS
-     kkttuuttiill [--kk _k_e_y_t_a_b | ----kkeeyyttaabb==_k_e_y_t_a_b] [--vv | ----vveerrbboossee] [----vveerrssiioonn] [--hh |
-     ----hheellpp] _c_o_m_m_a_n_d [_a_r_g_s]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkttuuttiill is a program for managing keytabs.  _c_o_m_m_a_n_d can be one of the fol-
-     lowing:
-
-     add [--pp _p_r_i_n_c_i_p_a_l] [----pprriinncciippaall==_p_r_i_n_c_i_p_a_l] [--VV _k_v_n_o] [----kkvvnnoo==_k_v_n_o] [--ee
-             _e_n_c_y_p_e] [----eennccttyyppee==_e_n_c_t_y_p_e] [--ww _p_a_s_s_w_o_r_d] [----ppaasssswwoorrdd==_p_a_s_s_w_o_r_d]
-             [--rr] [----rraannddoomm] [--ss] [----nnoo--ssaalltt]
-             Adds a key to the keytab. Options that are not specified will be
-             prompted for.
-
-     change [--rr _r_e_a_l_m] [----rreeaallmm==_r_e_a_l_m] [----aa _h_o_s_t] [----aaddmmiinn--sseerrvveerr==_h_o_s_t] [----ss
-             _p_o_r_t] [----sseerrvveerr--ppoorrtt==_p_o_r_t]
-             Update one or several keys to new versions.  By default, use the
-             admin server for the realm of an keytab entry.  Otherwise it will
-             use the values specified by the options.
-
-             If no principals are given, all the ones in the keytab are updat-
-             ed.
-
-     copy _k_e_y_t_a_b_-_s_r_c _k_e_y_t_a_b_-_d_e_s_t
-             Copies all the entries from _k_e_y_t_a_b_-_s_r_c to _k_e_y_t_a_b_-_d_e_s_t.
-
-     get [--pp _a_d_m_i_n _p_r_i_n_c_i_p_a_l] [----pprriinncciippaall==_a_d_m_i_n _p_r_i_n_c_i_p_a_l] [--ee _e_n_c_t_y_p_e |
-             ----eennccttyyppeess==_e_n_c_t_y_p_e
-             sseerrvveerr==_a_d_m_i_n _s_e_r_v_e_r] [--ss _s_e_r_v_e_r _p_o_r_t] [----sseerrvveerr--ppoorrtt==_s_e_r_v_e_r _p_o_r_t]
-             _p_r_i_n_c_i_p_a_l ][--rr   _r_e_a_l_m]   [----rreeaallmm==_r_e_a_l_m]   [--aa   _a_d_m_i_n   _s_e_r_v_e_r]
-             [----aaddmmiinn-- Get a key for pprriinncciippaall and store it in a keytab.
-
-     list [----kkeeyyss] [----ttiimmeessttaammpp]
-             List the keys stored in the keytab.
-
-     remove [--pp _p_r_i_n_c_i_p_a_l] [----pprriinncciippaall==_p_r_i_n_c_i_p_a_l] [--VV --kkvvnnoo] [----kkvvnnoo==_k_v_n_o]
-             [--ee --eennccttyyppee] [----eennccttyyppee==_e_n_c_t_y_p_e]
-             Removes the specified key or keys. Not specifying a _k_v_n_o removes
-             keys with any version number. Not specifying a _e_n_c_t_y_p_e removes
-             keys of any type.
-
-     purge [----aaggee==_a_g_e]
-             Removes all old entries (for which there is a newer version) that
-             are older than _a_g_e (default one week).
-
-     srvconvert
-
-     srv2keytab [--ss _s_r_v_t_a_b] [----ssrrvvttaabb==_s_r_v_t_a_b]
-             Converts the version 4 srvtab in _s_r_v_t_a_b to a version 5 keytab and
-             stores it in _k_e_y_t_a_b. Identical to:
-
-                   ktutil copy krb4:_s_r_v_t_a_b _k_e_y_t_a_b
-
-     srvcreate
-
-     key2srvtab [--ss _s_r_v_t_a_b] [----ssrrvvttaabb==_s_r_v_t_a_b]
-             Converts the version 5 keytab in _k_e_y_t_a_b to a version 4 srvtab and
-             stores it in _s_r_v_t_a_b. Identical to:
-
-                   ktutil copy _k_e_y_t_a_b krb4:_s_r_v_t_a_b
-
-SSEEEE AALLSSOO
-     kadmin(8)
-
- HEIMDAL                       December 16, 2000                             2
diff --git a/crypto/heimdal/admin/srvconvert.c b/crypto/heimdal/admin/srvconvert.c
deleted file mode 100644
index e4a2b1104204..000000000000
--- a/crypto/heimdal/admin/srvconvert.c
+++ /dev/null
@@ -1,181 +0,0 @@
-/*
- * Copyright (c) 1997, 1998, 1999 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-#include "ktutil_locl.h"
-
-RCSID("$Id: srvconvert.c,v 1.11 2000/01/02 03:56:21 assar Exp $");
-
-/* convert a version 4 srvtab to a version 5 keytab */
-
-#ifndef KEYFILE
-#define KEYFILE "/etc/srvtab"
-#endif
-
-static char *srvtab = KEYFILE;
-static int help_flag;
-static int verbose;
-
-static struct getargs args[] = {
-    { "srvtab", 's', arg_string, &srvtab, "srvtab to convert", "file" },
-    { "help", 'h', arg_flag, &help_flag },
-    { "verbose", 'v', arg_flag, &verbose },
-};
-
-static int num_args = sizeof(args) / sizeof(args[0]);
-
-int
-srvconv(int argc, char **argv)
-{
-    krb5_error_code ret;
-    int optind = 0;
-    int fd;
-    krb5_storage *sp;
-
-    if(getarg(args, num_args, argc, argv, &optind)){
-	arg_printusage(args, num_args, "ktutil srvconvert", "");
-	return 1;
-    }
-    if(help_flag){
-	arg_printusage(args, num_args, "ktutil srvconvert", "");
-	return 0;
-    }
-
-    argc -= optind;
-    argv += optind;
-
-    if (argc != 0) {
-	arg_printusage(args, num_args, "ktutil srvconvert", "");
-	return 1;
-    }
-
-    fd = open(srvtab, O_RDONLY);
-    if(fd < 0){
-	krb5_warn(context, errno, "%s", srvtab);
-	return 1;
-    }
-    sp = krb5_storage_from_fd(fd);
-    if(sp == NULL){
-	close(fd);
-	return 1;
-    }
-    while(1){
-	char *service, *instance, *realm;
-	int8_t kvno;
-	des_cblock key;
-	krb5_keytab_entry entry;
-	
-	ret = krb5_ret_stringz(sp, &service);
-	if(ret == KRB5_CC_END) {
-	    ret = 0;
-	    break;
-	}
-	if(ret) {
-	    krb5_warn(context, ret, "reading service");
-	    break;
-	}
-	ret = krb5_ret_stringz(sp, &instance);
-	if(ret) {
-	    krb5_warn(context, ret, "reading instance");
-	    free(service);
-	    break;
-	}
-	ret = krb5_ret_stringz(sp, &realm);
-	if(ret) {
-	    krb5_warn(context, ret, "reading realm");
-	    free(service);
-	    free(instance);
-	    break;
-	}
-	ret = krb5_425_conv_principal(context, service, instance, realm,
-				      &entry.principal);
-	free(service);
-	free(instance);
-	free(realm);
-	if (ret) {
-	    krb5_warn(context, ret, "krb5_425_conv_principal (%s.%s@%s)",
-		      service, instance, realm);
-	    break;
-	}
-	
-	ret = krb5_ret_int8(sp, &kvno);
-	if(ret) {
-	    krb5_warn(context, ret, "reading kvno");
-	    krb5_free_principal(context, entry.principal);
-	    break;
-	}
-	ret = sp->fetch(sp, key, 8);
-	if(ret < 0){
-	    krb5_warn(context, errno, "reading key");
-	    krb5_free_principal(context, entry.principal);
-	    break;
-	}
-	if(ret < 8) {
-	    krb5_warn(context, errno, "end of file while reading key");
-	    krb5_free_principal(context, entry.principal);
-	    break;
-	}
-	
-	entry.vno = kvno;
-	entry.timestamp = time (NULL);
-	entry.keyblock.keyvalue.data = key;
-	entry.keyblock.keyvalue.length = 8;
-	
-	if(verbose){
-	    char *p;
-	    ret = krb5_unparse_name(context, entry.principal, &p);
-	    if(ret){
-		krb5_warn(context, ret, "krb5_unparse_name");
-		krb5_free_principal(context, entry.principal);
-		break;
-	    } else{
-		fprintf(stderr, "Storing keytab for %s\n", p);
-		free(p);
-	    }
-				    
-	}
-	entry.keyblock.keytype = ETYPE_DES_CBC_MD5;
-	ret = krb5_kt_add_entry(context, keytab, &entry);
-	entry.keyblock.keytype = ETYPE_DES_CBC_MD4;
-	ret = krb5_kt_add_entry(context, keytab, &entry);
-	entry.keyblock.keytype = ETYPE_DES_CBC_CRC;
-	ret = krb5_kt_add_entry(context, keytab, &entry);
-	krb5_free_principal(context, entry.principal);
-	if(ret) {
-	    krb5_warn(context, ret, "krb5_kt_add_entry");
-	    break;
-	}
-    }
-    krb5_storage_free(sp);
-    close(fd);
-    return ret;
-}
diff --git a/crypto/heimdal/admin/srvcreate.c b/crypto/heimdal/admin/srvcreate.c
deleted file mode 100644
index bc86bc89aa3b..000000000000
--- a/crypto/heimdal/admin/srvcreate.c
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- * Copyright (c) 1997, 1998, 1999 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-#include "ktutil_locl.h"
-
-RCSID("$Id: srvcreate.c,v 1.3 1999/12/02 17:04:53 joda Exp $");
-
-/* convert a version 5 keytab to a version 4 srvtab */
-
-#ifndef KEYFILE
-#define KEYFILE "/etc/srvtab"
-#endif
-
-static char *srvtab = KEYFILE;
-static int help_flag;
-static int verbose;
-
-static struct getargs args[] = {
-    { "srvtab", 's', arg_string, &srvtab, "srvtab to create", "file" },
-    { "help", 'h', arg_flag, &help_flag },
-    { "verbose", 'v', arg_flag, &verbose },
-};
-
-static int num_args = sizeof(args) / sizeof(args[0]);
-
-int
-srvcreate(int argc, char **argv)
-{
-    krb5_error_code ret;
-    int optind = 0;
-    int fd;
-    krb5_kt_cursor cursor;
-    krb5_keytab_entry entry;
-    char service[100], instance[100], realm[100];
-    int8_t kvno;
-
-    if(getarg(args, num_args, argc, argv, &optind)){
-	arg_printusage(args, num_args, "ktutil srvcreate", "");
-	return 1;
-    }
-    if(help_flag){
-	arg_printusage(args, num_args, "ktutil srvcreate", "");
-	return 0;
-    }
-
-    argc -= optind;
-    argv += optind;
-
-    if (argc != 0) {
-	arg_printusage(args, num_args, "ktutil srvcreate", "");
-	return 1;
-    }
-
-    ret = krb5_kt_start_seq_get(context, keytab, &cursor);
-    if(ret){
-        krb5_warn(context, ret, "krb5_kt_start_seq_get");
-        return 1;
-    }
-
-    fd = open(srvtab, O_WRONLY |O_APPEND |O_CREAT, 0600);
-    if(fd < 0){
-	krb5_warn(context, errno, "%s", srvtab);
-	return 1;
-    }
-
-    while((ret = krb5_kt_next_entry(context, keytab, &entry, &cursor)) == 0){
-      ret = krb5_524_conv_principal(context, entry.principal,
-				    service, instance, realm);
-      if(ret) {
-        krb5_warn(context, ret, "krb5_524_conv_principal");
-        close(fd);
-        return 1;
-      }
-      if ( (entry.keyblock.keyvalue.length == 8) && 
-           (entry.keyblock.keytype == ETYPE_DES_CBC_MD5) ) {
-	  if (verbose) {
-	      printf ("%s.%s@%s vno %d\n", service, instance, realm,
-		      entry.vno);
-	  }
-
-	  write(fd, service, strlen(service)+1);
-          write(fd, instance, strlen(instance)+1);
-          write(fd, realm, strlen(realm)+1);
-          kvno = entry.vno;
-          write(fd, &kvno, sizeof(kvno));
-          write(fd, entry.keyblock. keyvalue.data, 8);
-      }
-      krb5_kt_free_entry(context, &entry);
-    }
-
-    close(fd);
-    ret = krb5_kt_end_seq_get(context, keytab, &cursor);
-    return ret;
-}
diff --git a/crypto/heimdal/appl/dceutils/compile b/crypto/heimdal/appl/dceutils/compile
deleted file mode 100755
index d4a34aa0ef97..000000000000
--- a/crypto/heimdal/appl/dceutils/compile
+++ /dev/null
@@ -1,82 +0,0 @@
-#! /bin/sh
-
-# Wrapper for compilers which do not understand `-c -o'.
-
-# Copyright 1999, 2000 Free Software Foundation, Inc.
-# Written by Tom Tromey <tromey@cygnus.com>.
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-
-# Usage:
-# compile PROGRAM [ARGS]...
-# `-o FOO.o' is removed from the args passed to the actual compile.
-
-prog=$1
-shift
-
-ofile=
-cfile=
-args=
-while test $# -gt 0; do
-   case "$1" in
-    -o)
-       ofile=$2
-       shift
-       ;;
-    *.c)
-       cfile=$1
-       args="$args $1"
-       ;;
-    *)
-       args="$args $1"
-       ;;
-   esac
-   shift
-done
-
-test -z "$ofile" && {
-   echo "compile: no \`-o' option seen" 1>&2
-   exit 1
-}
-
-test -z "$cfile" && {
-   echo "compile: no \`.c' file seen" 1>&2
-   exit 1
-}
-
-# Name of file we expect compiler to create.
-cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'`
-
-# Create the lock directory.
-lockdir=`echo $ofile | sed -e 's|/|_|g'`
-while true; do
-   if mkdir $lockdir > /dev/null 2>&1; then
-      break
-   fi
-   sleep 1
-done
-# FIXME: race condition here if user kills between mkdir and trap.
-trap "rmdir $lockdir; exit 1" 1 2 15
-
-# Run the compile.
-"$prog" $args
-status=$?
-
-if test -f "$cofile"; then
-   mv "$cofile" "$ofile"
-fi
-
-rmdir $lockdir
-exit $status
diff --git a/crypto/heimdal/appl/ftp/ftp/ftp.cat1 b/crypto/heimdal/appl/ftp/ftp/ftp.cat1
deleted file mode 100644
index 66262de9dfac..000000000000
--- a/crypto/heimdal/appl/ftp/ftp/ftp.cat1
+++ /dev/null
@@ -1,650 +0,0 @@
-
-FTP(1)                       UNIX Reference Manual                      FTP(1)
-
-NNAAMMEE
-     ffttpp - ARPANET file transfer program
-
-SSYYNNOOPPSSIISS
-     ffttpp [--tt] [--vv] [--dd] [--ii] [--nn] [--gg] [--pp] [--ll] [_h_o_s_t]
-
-DDEESSCCRRIIPPTTIIOONN
-     FFttpp is the user interface to the ARPANET standard File Transfer Protocol.
-     The program allows a user to transfer files to and from a remote network
-     site.
-
-     Modifications has been made so that it almost follows the ftpsec Internet
-     draft.
-
-     Options may be specified at the command line, or to the command inter-
-     preter.
-
-     --tt    Enables packet tracing.
-
-     --vv    Verbose option forces ffttpp to show all responses from the remote
-           server, as well as report on data transfer statistics.
-
-     --nn    Restrains ffttpp from attempting ``auto-login'' upon initial connec-
-           tion.  If auto-login is enabled, ffttpp will check the _._n_e_t_r_c (see be-
-           low) file in the user's home directory for an entry describing an
-           account on the remote machine.  If no entry exists, ffttpp will prompt
-           for the remote machine login name (default is the user identity on
-           the local machine), and, if necessary, prompt for a password and an
-           account with which to login.
-
-     --ii    Turns off interactive prompting during multiple file transfers.
-
-     --pp    Turn on passive mode.
-
-     --dd    Enables debugging.
-
-     --gg    Disables file name globbing.
-
-     --ll    Disables command line editing.
-
-     The client host with which ffttpp is to communicate may be specified on the
-     command line.  If this is done, ffttpp will immediately attempt to establish
-     a connection to an FTP server on that host; otherwise, ffttpp will enter its
-     command interpreter and await instructions from the user.  When ffttpp is
-     awaiting commands from the user the prompt `ftp>' is provided to the us-
-     er.  The following commands are recognized by ffttpp:
-
-     !! [_c_o_m_m_a_n_d [_a_r_g_s]]
-                 Invoke an interactive shell on the local machine.  If there
-                 are arguments, the first is taken to be a command to execute
-                 directly, with the rest of the arguments as its arguments.
-
-     $$ _m_a_c_r_o_-_n_a_m_e [_a_r_g_s]
-                 Execute the macro _m_a_c_r_o_-_n_a_m_e that was defined with the mmaaccddeeff
-                 command.  Arguments are passed to the macro unglobbed.
-
-     aaccccoouunntt [_p_a_s_s_w_d]
-                 Supply a supplemental password required by a remote system
-                 for access to resources once a login has been successfully
-                 completed.  If no argument is included, the user will be
-
-
-                 prompted for an account password in a non-echoing input mode.
-
-     aappppeenndd _l_o_c_a_l_-_f_i_l_e [_r_e_m_o_t_e_-_f_i_l_e]
-                 Append a local file to a file on the remote machine.  If
-                 _r_e_m_o_t_e_-_f_i_l_e is left unspecified, the local file name is used
-                 in naming the remote file after being altered by any nnttrraannss
-                 or nnmmaapp setting.  File transfer uses the current settings for
-                 ttyyppee, ffoorrmmaatt, mmooddee, and ssttrruuccttuurree.
-
-     aasscciiii       Set the file transfer ttyyppee to network ASCII. This is the de-
-                 fault type.
-
-     bbeellll        Arrange that a bell be sounded after each file transfer com-
-                 mand is completed.
-
-     bbiinnaarryy      Set the file transfer ttyyppee to support binary image transfer.
-
-     bbyyee         Terminate the FTP session with the remote server and exit
-                 ffttpp. An end of file will also terminate the session and exit.
-
-     ccaassee        Toggle remote computer file name case mapping during mmggeett
-                 commands.  When ccaassee is on (default is off), remote computer
-                 file names with all letters in upper case are written in the
-                 local directory with the letters mapped to lower case.
-
-     ccdd _r_e_m_o_t_e_-_d_i_r_e_c_t_o_r_y
-                 Change the working directory on the remote machine to _r_e_m_o_t_e_-
-                 _d_i_r_e_c_t_o_r_y.
-
-     ccdduupp        Change the remote machine working directory to the parent of
-                 the current remote machine working directory.
-
-     cchhmmoodd _m_o_d_e _f_i_l_e_-_n_a_m_e
-                 Change the permission modes of the file _f_i_l_e_-_n_a_m_e on the re-
-                 mote sytem to _m_o_d_e.
-
-     cclloossee       Terminate the FTP session with the remote server, and return
-                 to the command interpreter.  Any defined macros are erased.
-
-     ccrr          Toggle carriage return stripping during ascii type file re-
-                 trieval.  Records are denoted by a carriage return/linefeed
-                 sequence during ascii type file transfer.  When ccrr is on (the
-                 default), carriage returns are stripped from this sequence to
-                 conform with the UNIX single linefeed record delimiter.
-                 Records on non-UNIX remote systems may contain single line-
-                 feeds; when an ascii type transfer is made, these linefeeds
-                 may be distinguished from a record delimiter only when ccrr is
-                 off.
-
-     ddeelleettee _r_e_m_o_t_e_-_f_i_l_e
-                 Delete the file _r_e_m_o_t_e_-_f_i_l_e on the remote machine.
-
-     ddeebbuugg [_d_e_b_u_g_-_v_a_l_u_e]
-                 Toggle debugging mode.  If an optional _d_e_b_u_g_-_v_a_l_u_e is speci-
-                 fied it is used to set the debugging level.  When debugging
-                 is on, ffttpp prints each command sent to the remote machine,
-                 preceded by the string `-->'
-
-     ddiirr [_r_e_m_o_t_e_-_d_i_r_e_c_t_o_r_y] [_l_o_c_a_l_-_f_i_l_e]
-                 Print a listing of the directory contents in the directory,
-                 _r_e_m_o_t_e_-_d_i_r_e_c_t_o_r_y, and, optionally, placing the output in
-                 _l_o_c_a_l_-_f_i_l_e. If interactive prompting is on, ffttpp will prompt
-                 the user to verify that the last argument is indeed the tar-
-                 get local file for receiving ddiirr output.  If no directory is
-                 specified, the current working directory on the remote ma-
-                 chine is used.  If no local file is specified, or _l_o_c_a_l_-_f_i_l_e
-
-                 is --, output comes to the terminal.
-
-     ddiissccoonnnneecctt  A synonym for _c_l_o_s_e.
-
-     ffoorrmm _f_o_r_m_a_t
-                 Set the file transfer ffoorrmm to _f_o_r_m_a_t. The default format is
-                 ``file''.
-
-     ggeett _r_e_m_o_t_e_-_f_i_l_e [_l_o_c_a_l_-_f_i_l_e]
-                 Retrieve the _r_e_m_o_t_e_-_f_i_l_e and store it on the local machine.
-                 If the local file name is not specified, it is given the same
-                 name it has on the remote machine, subject to alteration by
-                 the current ccaassee, nnttrraannss, and nnmmaapp settings.  The current
-                 settings for ttyyppee, ffoorrmm, mmooddee, and ssttrruuccttuurree are used while
-                 transferring the file.
-
-     gglloobb        Toggle filename expansion for mmddeelleettee, mmggeett and mmppuutt. If
-                 globbing is turned off with gglloobb, the file name arguments are
-                 taken literally and not expanded.  Globbing for mmppuutt is done
-                 as in csh(1).  For mmddeelleettee and mmggeett, each remote file name is
-                 expanded separately on the remote machine and the lists are
-                 not merged.  Expansion of a directory name is likely to be
-                 different from expansion of the name of an ordinary file: the
-                 exact result depends on the foreign operating system and ftp
-                 server, and can be previewed by doing `mls remote-files -'.
-                 As a security measure, remotely globbed files that starts
-                 with `/' or contains `../', will not be automatically re-
-                 ceived. If you have interactive prompting turned off, these
-                 filenames will be ignored.  Note: mmggeett and mmppuutt are not meant
-                 to transfer entire directory subtrees of files.  That can be
-                 done by transferring a tar(1) archive of the subtree (in bi-
-                 nary mode).
-
-     hhaasshh        Toggle hash-sign (``#'') printing for each data block trans-
-                 ferred.  The size of a data block is 1024 bytes.
-
-     hheellpp [_c_o_m_m_a_n_d]
-                 Print an informative message about the meaning of _c_o_m_m_a_n_d. If
-                 no argument is given, ffttpp prints a list of the known com-
-                 mands.
-
-     iiddllee [_s_e_c_o_n_d_s]
-                 Set the inactivity timer on the remote server to _s_e_c_o_n_d_s sec-
-                 onds.  If _s_e_c_o_n_d_s is omitted, the current inactivity timer is
-                 printed.
-
-     llccdd [_d_i_r_e_c_t_o_r_y]
-                 Change the working directory on the local machine.  If no
-                 _d_i_r_e_c_t_o_r_y is specified, the user's home directory is used.
-
-     llss [_r_e_m_o_t_e_-_d_i_r_e_c_t_o_r_y] [_l_o_c_a_l_-_f_i_l_e]
-                 Print a listing of the contents of a directory on the remote
-                 machine.  The listing includes any system-dependent informa-
-                 tion that the server chooses to include; for example, most
-                 UNIX systems will produce output from the command `ls -l'.
-                 (See also nnlliisstt.) If _r_e_m_o_t_e_-_d_i_r_e_c_t_o_r_y is left unspecified,
-                 the current working directory is used.  If interactive
-                 prompting is on, ffttpp will prompt the user to verify that the
-                 last argument is indeed the target local file for receiving
-                 llss output.  If no local file is specified, or if _l_o_c_a_l_-_f_i_l_e
-                 is `--', the output is sent to the terminal.
-
-     mmaaccddeeff _m_a_c_r_o_-_n_a_m_e
-                 Define a macro.  Subsequent lines are stored as the macro
-                 _m_a_c_r_o_-_n_a_m_e; a null line (consecutive newline characters in a
-                 file or carriage returns from the terminal) terminates macro
-                 input mode.  There is a limit of 16 macros and 4096 total
-                 characters in all defined macros.  Macros remain defined un-
-                 til a cclloossee command is executed.  The macro processor inter-
-                 prets `$' and `\' as special characters.  A `$' followed by a
-                 number (or numbers) is replaced by the corresponding argument
-                 on the macro invocation command line.  A `$' followed by an
-                 `i' signals that macro processor that the executing macro is
-                 to be looped.  On the first pass `$i' is replaced by the
-                 first argument on the macro invocation command line, on the
-                 second pass it is replaced by the second argument, and so on.
-                 A `\' followed by any character is replaced by that charac-
-                 ter.  Use the `\' to prevent special treatment of the `$'.
-
-     mmddeelleettee [_r_e_m_o_t_e_-_f_i_l_e_s]
-                 Delete the _r_e_m_o_t_e_-_f_i_l_e_s on the remote machine.
-
-     mmddiirr _r_e_m_o_t_e_-_f_i_l_e_s _l_o_c_a_l_-_f_i_l_e
-                 Like ddiirr, except multiple remote files may be specified.  If
-                 interactive prompting is on, ffttpp will prompt the user to ver-
-                 ify that the last argument is indeed the target local file
-                 for receiving mmddiirr output.
-
-     mmggeett _r_e_m_o_t_e_-_f_i_l_e_s
-                 Expand the _r_e_m_o_t_e_-_f_i_l_e_s on the remote machine and do a ggeett
-                 for each file name thus produced.  See gglloobb for details on
-                 the filename expansion.  Resulting file names will then be
-                 processed according to ccaassee, nnttrraannss, and nnmmaapp settings.
-                 Files are transferred into the local working directory, which
-                 can be changed with `lcd directory'; new local directories
-                 can be created with `! mkdir directory'.
-
-     mmkkddiirr _d_i_r_e_c_t_o_r_y_-_n_a_m_e
-                 Make a directory on the remote machine.
-
-     mmllss _r_e_m_o_t_e_-_f_i_l_e_s _l_o_c_a_l_-_f_i_l_e
-                 Like nnlliisstt, except multiple remote files may be specified,
-                 and the _l_o_c_a_l_-_f_i_l_e must be specified.  If interactive prompt-
-                 ing is on, ffttpp will prompt the user to verify that the last
-                 argument is indeed the target local file for receiving mmllss
-                 output.
-
-     mmooddee [_m_o_d_e_-_n_a_m_e]
-                 Set the file transfer mmooddee to _m_o_d_e_-_n_a_m_e. The default mode is
-                 ``stream'' mode.
-
-     mmooddttiimmee _f_i_l_e_-_n_a_m_e
-                 Show the last modification time of the file on the remote ma-
-                 chine.
-
-     mmppuutt _l_o_c_a_l_-_f_i_l_e_s
-                 Expand wild cards in the list of local files given as argu-
-                 ments and do a ppuutt for each file in the resulting list.  See
-                 gglloobb for details of filename expansion.  Resulting file names
-                 will then be processed according to nnttrraannss and nnmmaapp settings.
-
-     nneewweerr _f_i_l_e_-_n_a_m_e
-                 Get the file only if the modification time of the remote file
-                 is more recent that the file on the current system.  If the
-                 file does not exist on the current system, the remote file is
-                 considered nneewweerr. Otherwise, this command is identical to
-                 _g_e_t.
-
-     nnlliisstt [_r_e_m_o_t_e_-_d_i_r_e_c_t_o_r_y] [_l_o_c_a_l_-_f_i_l_e]
-                 Print a  list of the files in a directory on the remote ma-
-                 chine.  If _r_e_m_o_t_e_-_d_i_r_e_c_t_o_r_y is left unspecified, the current
-                 working directory is used.  If interactive prompting is on,
-                 ffttpp will prompt the user to verify that the last argument is
-                 indeed the target local file for receiving nnlliisstt output.  If
-                 no local file is specified, or if _l_o_c_a_l_-_f_i_l_e is --, the output
-                 is sent to the terminal.
-
-     nnmmaapp [_i_n_p_a_t_t_e_r_n _o_u_t_p_a_t_t_e_r_n]
-                 Set or unset the filename mapping mechanism.  If no arguments
-                 are specified, the filename mapping mechanism is unset.  If
-                 arguments are specified, remote filenames are mapped during
-                 mmppuutt commands and ppuutt commands issued without a specified re-
-                 mote target filename.  If arguments are specified, local
-                 filenames are mapped during mmggeett commands and ggeett commands
-                 issued without a specified local target filename.  This com-
-                 mand is useful when connecting to a non-UNIX remote computer
-                 with different file naming conventions or practices.  The
-                 mapping follows the pattern set by _i_n_p_a_t_t_e_r_n and _o_u_t_p_a_t_t_e_r_n.
-                 [_I_n_p_a_t_t_e_r_n] is a template for incoming filenames (which may
-                 have already been processed according to the nnttrraannss and ccaassee
-                 settings).  Variable templating is accomplished by including
-                 the sequences `$1', `$2', ..., `$9' in _i_n_p_a_t_t_e_r_n. Use `\' to
-                 prevent this special treatment of the `$' character.  All
-                 other characters are treated literally, and are used to de-
-                 termine the nnmmaapp [_i_n_p_a_t_t_e_r_n] variable values.  For example,
-                 given _i_n_p_a_t_t_e_r_n $1.$2 and the remote file name "mydata.data",
-                 $1 would have the value "mydata", and $2 would have the value
-                 "data".  The _o_u_t_p_a_t_t_e_r_n determines the resulting mapped file-
-                 name.  The sequences `$1', `$2', ...., `$9' are replaced by
-                 any value resulting from the _i_n_p_a_t_t_e_r_n template.  The se-
-                 quence `$0' is replace by the original filename.  Additional-
-                 ly, the sequence `[_s_e_q_1, _s_e_q_2]' is replaced by [_s_e_q_1] if _s_e_q_1
-                 is not a null string; otherwise it is replaced by _s_e_q_2. For
-                 example, the command
-
-                       nmap $1.$2.$3 [$1,$2].[$2,file]
-
-                 would yield the output filename "myfile.data" for input file-
-                 names "myfile.data" and "myfile.data.old", "myfile.file" for
-                 the input filename "myfile", and "myfile.myfile" for the in-
-                 put filename ".myfile".  Spaces may be included in
-                 _o_u_t_p_a_t_t_e_r_n, as in the example: `nmap $1 sed "s/  *$//" > $1'
-                 .  Use the `\' character to prevent special treatment of the
-                 `$','[','[', and `,' characters.
-
-     nnttrraannss [_i_n_c_h_a_r_s [_o_u_t_c_h_a_r_s]]
-                 Set or unset the filename character translation mechanism.
-                 If no arguments are specified, the filename character trans-
-                 lation mechanism is unset.  If arguments are specified, char-
-                 acters in remote filenames are translated during mmppuutt com-
-                 mands and ppuutt commands issued without a specified remote tar-
-                 get filename.  If arguments are specified, characters in lo-
-                 cal filenames are translated during mmggeett commands and ggeett
-                 commands issued without a specified local target filename.
-                 This command is useful when connecting to a non-UNIX remote
-                 computer with different file naming conventions or practices.
-                 Characters in a filename matching a character in _i_n_c_h_a_r_s are
-                 replaced with the corresponding character in _o_u_t_c_h_a_r_s. If the
-                 character's position in _i_n_c_h_a_r_s is longer than the length of
-                 _o_u_t_c_h_a_r_s, the character is deleted from the file name.
-
-     ooppeenn _h_o_s_t [_p_o_r_t]
-                 Establish a connection to the specified _h_o_s_t FTP server.  An
-                 optional port number may be supplied, in which case, ffttpp will
-                 attempt to contact an FTP server at that port.  If the aauuttoo--
-                 llooggiinn option is on (default), ffttpp will also attempt to auto-
-
-                 matically log the user in to the FTP server (see below).
-
-     ppaassssiivvee     Toggle passive mode.  If passive mode is turned on (default
-                 is off), the ftp client will send a PASV command for all data
-                 connections instead of the usual PORT command.  The PASV com-
-                 mand requests that the remote server open a port for the data
-                 connection and return the address of that port.  The remote
-                 server listens on that port and the client connects to it.
-                 When using the more traditional PORT command, the client lis-
-                 tens on a port and sends that address to the remote server,
-                 who connects back to it.  Passive mode is useful when using
-                 ffttpp through a gateway router or host that controls the direc-
-                 tionality of traffic.  (Note that though ftp servers are re-
-                 quired to support the PASV command by RFC 1123, some do not.)
-
-     pprroommpptt      Toggle interactive prompting.  Interactive prompting occurs
-                 during multiple file transfers to allow the user to selec-
-                 tively retrieve or store files.  If prompting is turned off
-                 (default is on), any mmggeett or mmppuutt will transfer all files,
-                 and any mmddeelleettee will delete all files.
-
-     pprrooxxyy _f_t_p_-_c_o_m_m_a_n_d
-                 Execute an ftp command on a secondary control connection.
-                 This command allows simultaneous connection to two remote ftp
-                 servers for transferring files between the two servers.  The
-                 first pprrooxxyy command should be an ooppeenn, to establish the sec-
-                 ondary control connection.  Enter the command "proxy ?" to
-                 see other ftp commands executable on the secondary connec-
-                 tion.  The following commands behave differently when pref-
-                 aced by pprrooxxyy: ooppeenn will not define new macros during the au-
-                 to-login process, cclloossee will not erase existing macro defini-
-                 tions, ggeett and mmggeett transfer files from the host on the pri-
-                 mary control connection to the host on the secondary control
-                 connection, and ppuutt, mmppuutt, and aappppeenndd transfer files from the
-                 host on the secondary control connection to the host on the
-                 primary control connection.  Third party file transfers de-
-                 pend upon support of the ftp protocol PASV command by the
-                 server on the secondary control connection.
-
-     ppuutt _l_o_c_a_l_-_f_i_l_e [_r_e_m_o_t_e_-_f_i_l_e]
-                 Store a local file on the remote machine.  If _r_e_m_o_t_e_-_f_i_l_e is
-                 left unspecified, the local file name is used after process-
-                 ing according to any nnttrraannss or nnmmaapp settings in naming the
-                 remote file.  File transfer uses the current settings for
-                 ttyyppee, ffoorrmmaatt, mmooddee, and ssttrruuccttuurree.
-
-     ppwwdd         Print the name of the current working directory on the remote
-                 machine.
-
-     qquuiitt        A synonym for bbyyee.
-
-     qquuoottee _a_r_g_1 _a_r_g_2 _._._.
-                 The arguments specified are sent, verbatim, to the remote FTP
-                 server.
-
-     rreeccvv _r_e_m_o_t_e_-_f_i_l_e [_l_o_c_a_l_-_f_i_l_e]
-                 A synonym for get.
-
-     rreeggeett _r_e_m_o_t_e_-_f_i_l_e [_l_o_c_a_l_-_f_i_l_e]
-                 Reget acts like get, except that if _l_o_c_a_l_-_f_i_l_e exists and is
-                 smaller than _r_e_m_o_t_e_-_f_i_l_e, _l_o_c_a_l_-_f_i_l_e is presumed to be a par-
-                 tially transferred copy of _r_e_m_o_t_e_-_f_i_l_e and the transfer is
-                 continued from the apparent point of failure.  This command
-                 is useful when transferring very large files over networks
-
-
-                 that are prone to dropping connections.
-
-     rreemmootteehheellpp [_c_o_m_m_a_n_d_-_n_a_m_e]
-                 Request help from the remote FTP server.  If a _c_o_m_m_a_n_d_-_n_a_m_e
-                 is specified it is supplied to the server as well.
-
-     rreemmootteessttaattuuss [_f_i_l_e_-_n_a_m_e]
-                 With no arguments, show status of remote machine.  If _f_i_l_e_-
-                 _n_a_m_e is specified, show status of _f_i_l_e_-_n_a_m_e on remote ma-
-                 chine.
-
-     rreennaammee [_f_r_o_m] [_t_o]
-                 Rename the file _f_r_o_m on the remote machine, to the file _t_o.
-
-     rreesseett       Clear reply queue.  This command re-synchronizes command/re-
-                 ply sequencing with the remote ftp server.  Resynchronization
-                 may be necessary following a violation of the ftp protocol by
-                 the remote server.
-
-     rreessttaarrtt _m_a_r_k_e_r
-                 Restart the immediately following ggeett or ppuutt at the indicated
-                 _m_a_r_k_e_r. On UNIX systems, marker is usually a byte offset into
-                 the file.
-
-     rrmmddiirr _d_i_r_e_c_t_o_r_y_-_n_a_m_e
-                 Delete a directory on the remote machine.
-
-     rruunniiqquuee     Toggle storing of files on the local system with unique file-
-                 names.  If a file already exists with a name equal to the
-                 target local filename for a ggeett or mmggeett command, a ".1" is
-                 appended to the name.  If the resulting name matches another
-                 existing file, a ".2" is appended to the original name.  If
-                 this process continues up to ".99", an error message is
-                 printed, and the transfer does not take place.  The generated
-                 unique filename will be reported.  Note that rruunniiqquuee will not
-                 affect local files generated from a shell command (see be-
-                 low).  The default value is off.
-
-     sseenndd _l_o_c_a_l_-_f_i_l_e [_r_e_m_o_t_e_-_f_i_l_e]
-                 A synonym for put.
-
-     sseennddppoorrtt    Toggle the use of PORT commands.  By default, ffttpp will at-
-                 tempt to use a PORT command when establishing a connection
-                 for each data transfer.  The use of PORT commands can prevent
-                 delays when performing multiple file transfers.  If the PORT
-                 command fails, ffttpp will use the default data port.  When the
-                 use of PORT commands is disabled, no attempt will be made to
-                 use PORT commands for each data transfer.  This is useful for
-                 certain FTP implementations which do ignore PORT commands
-                 but, incorrectly, indicate they've been accepted.
-
-     ssiittee _a_r_g_1 _a_r_g_2 _._._.
-                 The arguments specified are sent, verbatim, to the remote FTP
-                 server as a SITE command.
-
-     ssiizzee _f_i_l_e_-_n_a_m_e
-                 Return size of _f_i_l_e_-_n_a_m_e on remote machine.
-
-     ssttaattuuss      Show the current status of ffttpp.
-
-     ssttrruucctt [_s_t_r_u_c_t_-_n_a_m_e]
-                 Set the file transfer _s_t_r_u_c_t_u_r_e to _s_t_r_u_c_t_-_n_a_m_e. By default
-                 ``stream'' structure is used.
-
-     ssuunniiqquuee     Toggle storing of files on remote machine under unique file
-                 names.  Remote ftp server must support ftp protocol STOU com-
-                 mand for successful completion.  The remote server will re-
-                 port unique name.  Default value is off.
-
-     ssyysstteemm      Show the type of operating system running on the remote ma-
-                 chine.
-
-     tteenneexx       Set the file transfer type to that needed to talk to TENEX
-                 machines.
-
-     ttrraaccee       Toggle packet tracing.
-
-     ttyyppee [_t_y_p_e_-_n_a_m_e]
-                 Set the file transfer ttyyppee to _t_y_p_e_-_n_a_m_e. If no type is speci-
-                 fied, the current type is printed.  The default type is net-
-                 work ASCII.
-
-     uummaasskk [_n_e_w_m_a_s_k]
-                 Set the default umask on the remote server to _n_e_w_m_a_s_k. If
-                 _n_e_w_m_a_s_k is omitted, the current umask is printed.
-
-     uusseerr _u_s_e_r_-_n_a_m_e [_p_a_s_s_w_o_r_d] [_a_c_c_o_u_n_t]
-                 Identify yourself to the remote FTP server.  If the _p_a_s_s_w_o_r_d
-                 is not specified and the server requires it, ffttpp will prompt
-                 the user for it (after disabling local echo).  If an _a_c_c_o_u_n_t
-                 field is not specified, and the FTP server requires it, the
-                 user will be prompted for it.  If an _a_c_c_o_u_n_t field is speci-
-                 fied, an account command will be relayed to the remote server
-                 after the login sequence is completed if the remote server
-                 did not require it for logging in.  Unless ffttpp is invoked
-                 with ``auto-login'' disabled, this process is done automati-
-                 cally on initial connection to the FTP server.
-
-     vveerrbboossee     Toggle verbose mode.  In verbose mode, all responses from the
-                 FTP server are displayed to the user.  In addition, if ver-
-                 bose is on, when a file transfer completes, statistics re-
-                 garding the efficiency of the transfer are reported.  By de-
-                 fault, verbose is on.
-
-     ?? [_c_o_m_m_a_n_d]
-                 A synonym for help.
-
-     The following command can be used with ftpsec-aware servers.
-
-     pprroott _c_l_e_a_r | _s_a_f_e | _c_o_n_f_i_d_e_n_t_i_a_l | _p_r_i_v_a_t_e
-                 Set the data protection level to the requested level.
-
-     The following command can be used with ftp servers that has implemented
-     the KAUTH site command.
-
-     kkaauutthh [_p_r_i_n_c_i_p_a_l]
-                 Obtain remote tickets.
-
-     Command arguments which have embedded spaces may be quoted with quote `"'
-     marks.
-
-AABBOORRTTIINNGG AA FFIILLEE TTRRAANNSSFFEERR
-     To abort a file transfer, use the terminal interrupt key (usually Ctrl-
-     C).  Sending transfers will be immediately halted.  Receiving transfers
-     will be halted by sending a ftp protocol ABOR command to the remote serv-
-     er, and discarding any further data received.  The speed at which this is
-     accomplished depends upon the remote server's support for ABOR process-
-     ing.  If the remote server does not support the ABOR command, an `ftp>'
-     prompt will not appear until the remote server has completed sending the
-     requested file.
-
-
-     The terminal interrupt key sequence will be ignored when ffttpp has complet-
-     ed any local processing and is awaiting a reply from the remote server.
-     A long delay in this mode may result from the ABOR processing described
-     above, or from unexpected behavior by the remote server, including viola-
-     tions of the ftp protocol.  If the delay results from unexpected remote
-     server behavior, the local ffttpp program must be killed by hand.
-
-FFIILLEE NNAAMMIINNGG CCOONNVVEENNTTIIOONNSS
-     Files specified as arguments to ffttpp commands are processed according to
-     the following rules.
-
-     1.   If the file name `--' is specified, the _s_t_d_i_n (for reading) or _s_t_d_o_u_t
-          (for writing) is used.
-
-     2.   If the first character of the file name is `|', the remainder of the
-          argument is interpreted as a shell command.  FFttpp then forks a shell,
-          using popen(3) with the argument supplied, and reads (writes) from
-          the stdout (stdin).  If the shell command includes spaces, the argu-
-          ment must be quoted; e.g.  ``" ls -lt"''.  A particularly useful ex-
-          ample of this mechanism is: ``dir more''.
-
-     3.   Failing the above checks, if ``globbing'' is enabled, local file
-          names are expanded according to the rules used in the csh(1);  c.f.
-          the gglloobb command.  If the ffttpp command expects a single local file
-          (.e.g.  ppuutt), only the first filename generated by the "globbing"
-          operation is used.
-
-     4.   For mmggeett commands and ggeett commands with unspecified local file
-          names, the local filename is the remote filename, which may be al-
-          tered by a ccaassee, nnttrraannss, or nnmmaapp setting.  The resulting filename
-          may then be altered if rruunniiqquuee is on.
-
-     5.   For mmppuutt commands and ppuutt commands with unspecified remote file
-          names, the remote filename is the local filename, which may be al-
-          tered by a nnttrraannss or nnmmaapp setting.  The resulting filename may then
-          be altered by the remote server if ssuunniiqquuee is on.
-
-FFIILLEE TTRRAANNSSFFEERR PPAARRAAMMEETTEERRSS
-     The FTP specification specifies many parameters which may affect a file
-     transfer.  The ttyyppee may be one of ``ascii'', ``image'' (binary),
-     ``ebcdic'', and ``local byte size'' (for PDP-10's and PDP-20's mostly).
-     FFttpp supports the ascii and image types of file transfer, plus local byte
-     size 8 for tteenneexx mode transfers.
-
-     FFttpp supports only the default values for the remaining file transfer pa-
-     rameters: mmooddee, ffoorrmm, and ssttrruucctt.
-
-TTHHEE ..nneettrrcc FFIILLEE
-     The _._n_e_t_r_c file contains login and initialization information used by the
-     auto-login process.  It resides in the user's home directory.  The fol-
-     lowing tokens are recognized; they may be separated by spaces, tabs, or
-     new-lines:
-
-     mmaacchhiinnee _n_a_m_e
-               Identify a remote machine _n_a_m_e. The auto-login process searches
-               the _._n_e_t_r_c file for a mmaacchhiinnee token that matches the remote ma-
-               chine specified on the ffttpp command line or as an ooppeenn command
-               argument.  Once a match is made, the subsequent _._n_e_t_r_c tokens
-               are processed, stopping when the end of file is reached or an-
-               other mmaacchhiinnee or a ddeeffaauulltt token is encountered.
-
-     ddeeffaauulltt   This is the same as mmaacchhiinnee _n_a_m_e except that ddeeffaauulltt matches
-               any name.  There can be only one ddeeffaauulltt token, and it must be
-               after all mmaacchhiinnee tokens.  This is normally used as:
-
-
-                     default login anonymous password user@site
-
-               thereby giving the user _a_u_t_o_m_a_t_i_c anonymous ftp login to ma-
-               chines not specified in _._n_e_t_r_c. This can be overridden by using
-               the --nn flag to disable auto-login.
-
-     llooggiinn _n_a_m_e
-               Identify a user on the remote machine.  If this token is pre-
-               sent, the auto-login process will initiate a login using the
-               specified _n_a_m_e.
-
-     ppaasssswwoorrdd _s_t_r_i_n_g
-               Supply a password.  If this token is present, the auto-login
-               process will supply the specified string if the remote server
-               requires a password as part of the login process.  Note that if
-               this token is present in the _._n_e_t_r_c file for any user other
-               than _a_n_o_n_y_m_o_u_s, ffttpp will abort the auto-login process if the
-               _._n_e_t_r_c is readable by anyone besides the user.
-
-     aaccccoouunntt _s_t_r_i_n_g
-               Supply an additional account password.  If this token is pre-
-               sent, the auto-login process will supply the specified string
-               if the remote server requires an additional account password,
-               or the auto-login process will initiate an ACCT command if it
-               does not.
-
-     mmaaccddeeff _n_a_m_e
-               Define a macro.  This token functions like the ffttpp mmaaccddeeff com-
-               mand functions.  A macro is defined with the specified name;
-               its contents begin with the next _._n_e_t_r_c line and continue until
-               a null line (consecutive new-line characters) is encountered.
-               If a macro named iinniitt is defined, it is automatically executed
-               as the last step in the auto-login process.
-
-EENNVVIIRROONNMMEENNTT
-     FFttpp utilizes the following environment variables.
-
-     HOME        For default location of a _._n_e_t_r_c file, if one exists.
-
-     SHELL       For default shell.
-
-SSEEEE AALLSSOO
-     ftpd(8),  _R_F_C_2_2_2_8
-
-HHIISSTTOORRYY
-     The ffttpp command appeared in 4.2BSD.
-
-BBUUGGSS
-     Correct execution of many commands depends upon proper behavior by the
-     remote server.
-
-     An error in the treatment of carriage returns in the 4.2BSD ascii-mode
-     transfer code has been corrected.  This correction may result in incor-
-     rect transfers of binary files to and from 4.2BSD servers using the ascii
-     type.  Avoid this problem by using the binary image type.
-
-4.2 Berkeley Distribution       April 27, 1996                              10
diff --git a/crypto/heimdal/appl/ftp/ftpd/ftpd.cat8 b/crypto/heimdal/appl/ftp/ftpd/ftpd.cat8
deleted file mode 100644
index d4af02e71cc1..000000000000
--- a/crypto/heimdal/appl/ftp/ftpd/ftpd.cat8
+++ /dev/null
@@ -1,296 +0,0 @@
-
-FTPD(8)                  UNIX System Manager's Manual                  FTPD(8)
-
-NNAAMMEE
-     ffttppdd - Internet File Transfer Protocol server
-
-SSYYNNOOPPSSIISS
-     ffttppdd [--aa _a_u_t_h_m_o_d_e] [--ddiillvv] [--gg _u_m_a_s_k] [--pp _p_o_r_t] [--TT _m_a_x_t_i_m_e_o_u_t] [--tt
-     _t_i_m_e_o_u_t] [--uu _d_e_f_a_u_l_t _u_m_a_s_k] [--BB | ----bbuuiillttiinn--llss] [----ggoooodd--cchhaarrss==_s_t_r_i_n_g]
-
-DDEESSCCRRIIPPTTIIOONN
-     FFttppdd is the Internet File Transfer Protocol server process.  The server
-     uses the TCP protocol and listens at the port specified in the ``ftp''
-     service specification; see services(5).
-
-     Available options:
-
-     --aa      Select the level of authentication required.  Kerberised login
-             can not be turned off. The default is to only allow kerberised
-             login.  Other possibilities can be turned on by giving a string
-             of comma separated flags as argument to --aa. Recognised flags are:
-
-             _p_l_a_i_n  Allow logging in with plaintext password. The password can
-                    be a(n) OTP or an ordinary password.
-
-             _o_t_p    Same as _p_l_a_i_n, but only OTP is allowed.
-
-             _f_t_p    Allow anonymous login.
-
-             The following combination modes exists for backwards compatibili-
-             ty:
-
-             _n_o_n_e   Same as _p_l_a_i_n_,_f_t_p.
-
-             _s_a_f_e   Same as _f_t_p.
-
-             _u_s_e_r   Ignored.
-
-     --dd      Debugging information is written to the syslog using LOG_FTP.
-
-     --gg      Anonymous users will get a umask of _u_m_a_s_k.
-
-     --ii      Open a socket and wait for a connection. This is mainly used for
-             debugging when ftpd isn't started by inetd.
-
-     --ll      Each successful and failed ftp(1) session is logged using syslog
-             with a facility of LOG_FTP.  If this option is specified twice,
-             the retrieve (get), store (put), append, delete, make directory,
-             remove directory and rename operations and their filename argu-
-             ments are also logged.
-
-     --pp      Use _p_o_r_t (a service name or number) instead of the default
-             _f_t_p_/_t_c_p.
-
-     --TT      A client may also request a different timeout period; the maximum
-             period allowed may be set to _t_i_m_e_o_u_t seconds with the --TT option.
-             The default limit is 2 hours.
-
-     --tt      The inactivity timeout period is set to _t_i_m_e_o_u_t seconds (the de-
-             fault is 15 minutes).
-
-     --uu      Set the initial umask to something else than the default 027.
-
-
-
-     --vv      Verbose mode.
-
-     --BB, ----bbuuiillttiinn--llss
-             use built-in ls to list files
-
-     ----ggoooodd--cchhaarrss==_s_t_r_i_n_g
-             allowed anonymous upload filename chars
-
-     The file _/_e_t_c_/_n_o_l_o_g_i_n can be used to disable ftp access.  If the file ex-
-     ists, ffttppdd displays it and exits.  If the file _/_e_t_c_/_f_t_p_w_e_l_c_o_m_e exists,
-     ffttppdd prints it before issuing the ``ready'' message.  If the file
-     _/_e_t_c_/_m_o_t_d exists, ffttppdd prints it after a successful login.
-
-     The ftp server currently supports the following ftp requests.  The case
-     of the requests is ignored.
-
-           Request    Description
-           ABOR       abort previous command
-           ACCT       specify account (ignored)
-           ALLO       allocate storage (vacuously)
-           APPE       append to a file
-           CDUP       change to parent of current working directory
-           CWD        change working directory
-           DELE       delete a file
-           HELP       give help information
-           LIST       give list files in a directory (``ls -lgA'')
-           MKD        make a directory
-           MDTM       show last modification time of file
-           MODE       specify data transfer _m_o_d_e
-           NLST       give name list of files in directory
-           NOOP       do nothing
-           PASS       specify password
-           PASV       prepare for server-to-server transfer
-           PORT       specify data connection port
-           PWD        print the current working directory
-           QUIT       terminate session
-           REST       restart incomplete transfer
-           RETR       retrieve a file
-           RMD        remove a directory
-           RNFR       specify rename-from file name
-           RNTO       specify rename-to file name
-           SITE       non-standard commands (see next section)
-           SIZE       return size of file
-           STAT       return status of server
-           STOR       store a file
-           STOU       store a file with a unique name
-           STRU       specify data transfer _s_t_r_u_c_t_u_r_e
-           SYST       show operating system type of server system
-           TYPE       specify data transfer _t_y_p_e
-           USER       specify user name
-           XCUP       change to parent of current working directory
-                      (deprecated)
-           XCWD       change working directory (deprecated)
-           XMKD       make a directory (deprecated)
-           XPWD       print the current working directory (deprecated)
-           XRMD       remove a directory (deprecated)
-
-     The following commands are specified by RFC2228.
-
-           AUTH       authentication/security mechanism
-           ADAT       authentication/security data
-           PROT       data channel protection level
-           PBSZ       protection buffer size
-           MIC        integrity protected command
-
-
-           CONF       confidentiality protected command
-           ENC        privacy protected command
-           CCC        clear command channel
-
-     The following non-standard or UNIX specific commands are supported by the
-     SITE request.
-
-           UMASK      change umask, (e.g. SSIITTEE UUMMAASSKK 000022)
-           IDLE       set idle-timer, (e.g. SSIITTEE IIDDLLEE 6600)
-           CHMOD      change mode of a file (e.g. SSIITTEE CCHHMMOODD 775555 ffiilleennaammee)
-           FIND       quickly find a specific file with GNU locate(1).
-           HELP       give help information.
-
-     The following Kerberos related site commands are understood.
-
-           KAUTH      obtain remote tickets.
-           KLIST      show remote tickets
-
-     The remaining ftp requests specified in Internet RFC 959 are recognized,
-     but not implemented.  MDTM and SIZE are not specified in RFC 959, but
-     will appear in the next updated FTP RFC.
-
-     The ftp server will abort an active file transfer only when the ABOR com-
-     mand is preceded by a Telnet "Interrupt Process" (IP) signal and a Telnet
-     "Synch" signal in the command Telnet stream, as described in Internet RFC
-     959.  If a STAT command is received during a data transfer, preceded by a
-     Telnet IP and Synch, transfer status will be returned.
-
-     FFttppdd interprets file names according to the ``globbing'' conventions used
-     by csh(1).  This allows users to utilize the metacharacters ``*?[]{}~''.
-
-     FFttppdd authenticates users according to these rules.
-
-           1.   If Kerberos authentication is used, the user must pass valid
-                tickets and the principal must be allowed to login as the re-
-                mote user.
-
-           2.   The login name must be in the password data base, and not have
-                a null password (if kerberos is used the password field is not
-                checked).  In this case a password must be provided by the
-                client before any file operations may be performed.  If the
-                user has an OTP key, the response from a successful USER com-
-                mand will include an OTP challenge. The client may choose to
-                respond with a PASS command giving either a standard password
-                or an OTP one-time password. The server will automatically de-
-                termine which type of password it has been given and attempt
-                to authenticate accordingly. See otp(1) for more information
-                on OTP authentication.
-
-           3.   The login name must not appear in the file _/_e_t_c_/_f_t_p_u_s_e_r_s.
-
-           4.   The user must have a standard shell returned by
-                getusershell(3).
-
-           5.   If the user name appears in the file _/_e_t_c_/_f_t_p_c_h_r_o_o_t the ses-
-                sion's root will be changed to the user's login directory by
-                chroot(2) as for an ``anonymous'' or ``ftp'' account (see next
-                item).  However, the user must still supply a password.  This
-                feature is intended as a compromise between a fully anonymous
-                account and a fully privileged account.  The account should
-                also be set up as for an anonymous account.
-
-           6.   If the user name is ``anonymous'' or ``ftp'', an anonymous ftp
-                account must be present in the password file (user ``ftp'').
-                In this case the user is allowed to log in by specifying any
-                password (by convention an email address for the user should
-                be used as the password).
-
-     In the last case, ffttppdd takes special measures to restrict the client's
-     access privileges.  The server performs a chroot(2) to the home directory
-     of the ``ftp'' user.  In order that system security is not breached, it
-     is recommended that the ``ftp'' subtree be constructed with care, consid-
-     er following these guidelines for anonymous ftp.
-
-     In general all files should be owned by ``root'', and have non-write per-
-     missions (644 or 755 depending on the kind of file). No files should be
-     owned or writable by ``ftp'' (possibly with exception for the
-     _~_f_t_p_/_i_n_c_o_m_i_n_g, as specified below).
-
-           _~_f_t_p      The ``ftp'' homedirectory should be owned by root.
-
-           _~_f_t_p_/_b_i_n  The directory for external programs (such as ls(1)).
-                     These programs must either be statically linked, or you
-                     must setup an environment for dynamic linking when run-
-                     ning chrooted.  These programs will be used if present:
-
-                           ls      Used when listing files.
-
-                           compress
-                                   When retrieving a filename that ends in _._Z,
-                                   and that file isn't present, ffttppdd will try
-                                   to find the filename without _._Z and com-
-                                   press it on the fly.
-
-                           gzip    Same as compress, just with files ending in
-                                   _._g_z.
-
-                           gtar    Enables retrieval of whole directories as
-                                   files ending in _._t_a_r. Can also be combined
-                                   with compression. You must use GNU Tar (or
-                                   some other that supports the --zz and --ZZ
-                                   flags).
-
-                           locate  Will enable ``fast find'' with the SSIITTEE
-                                   FFIINNDD command. You must also create a
-                                   _l_o_c_a_t_e_d_b file in _~_f_t_p_/_e_t_c.
-
-           _~_f_t_p_/_e_t_c  If you put copies of the passwd(5) and group(5) files
-                     here, ls will be able to produce owner names rather than
-                     numbers. Remember to remove any passwords from these
-                     files.
-
-                     The file _m_o_t_d, if present, will be printed after a suc-
-                     cessful login.
-
-           _~_f_t_p_/_d_e_v  Put a copy of /dev/null(7) here.
-
-           _~_f_t_p_/_p_u_b  Traditional place to put whatever you want to make pub-
-                     lic.
-
-     If you want guests to be able to upload files, create a _~_f_t_p_/_i_n_c_o_m_i_n_g di-
-     rectory owned by ``root'', and group ``ftp'' with mode 730 (make sure
-     ``ftp'' is member of group ``ftp''). The following restrictions apply to
-     anonymous users:
-
-     ++oo   Directories created will have mode 700.
-
-     ++oo   Uploaded files will be created with an umask of 777, if not changed
-         with the --gg option.
-
-     ++oo   These command are not accessible: DDEELLEE, RRMMDD, RRNNTTOO, RRNNFFRR, SSIITTEE UUMMAASSKK,
-
-         and SSIITTEE CCHHMMOODD.
-
-     ++oo   Filenames must start with an alpha-numeric character, and consist of
-         alpha-numeric characters or any of the following: + (plus), - (mi-
-         nus), = (equal), _ (underscore), . (period), and , (comma).
-
-FFIILLEESS
-     /etc/ftpusers    Access list for users.
-     /etc/ftpchroot   List of normal users who should be chroot'd.
-     /etc/ftpwelcome  Welcome notice.
-     /etc/motd        Welcome notice after login.
-     /etc/nologin     Displayed and access refused.
-     ~/.klogin        Login access for Kerberos.
-
-SSEEEE AALLSSOO
-     ftp(1),  otp(1),  getusershell(3),  ftpusers(5),  syslogd(8),
-
-SSTTAANNDDAARRDDSS
-     RRFFCC 995599   FTP PROTOCOL SPECIFICATION
-     RRFFCC 11993388  OTP Specification
-     RRFFCC 22222288  FTP Security Extensions.
-
-BBUUGGSS
-     The server must run as the super-user to create sockets with privileged
-     port numbers.  It maintains an effective user id of the logged in user,
-     reverting to the super-user only when binding addresses to sockets.  The
-     possible security holes have been extensively scrutinized, but are possi-
-     bly incomplete.
-
-HHIISSTTOORRYY
-     The ffttppdd command appeared in 4.2BSD.
-
-4.2 Berkeley Distribution       April 19, 1997                               5
diff --git a/crypto/heimdal/appl/ftp/ftpd/ftpusers.cat5 b/crypto/heimdal/appl/ftp/ftpd/ftpusers.cat5
deleted file mode 100644
index d2ee3d3c3af6..000000000000
--- a/crypto/heimdal/appl/ftp/ftpd/ftpusers.cat5
+++ /dev/null
@@ -1,27 +0,0 @@
-
-FTPUSERS(5)                UNIX Programmer's Manual                FTPUSERS(5)
-
-NNAAMMEE
-     _/_e_t_c_/_f_t_p_u_s_e_r_s - FTP access list file
-
-DDEESSCCRRIIPPTTIIOONN
-     _/_e_t_c_/_f_t_p_u_s_e_r_s contains a list of users that should be allowed or denied
-     FTP access. Each line contains a user, optionally followed by ``allow''
-     (anything but ``allow'' is ignored).  The semi-user ``*'' matches any us-
-     er.  Users that has an explicit ``allow'', or that does not match any
-     line, are allowed access. Anyone else is denied access.
-
-     Note that this is compatible with the old format, where this file con-
-     tained a list of users that should be denied access.
-
-EEXXAAMMPPLLEESS
-     This will deny anyone but ``foo'' and ``bar'' to use FTP:
-
-     foo allow
-     bar allow
-     *
-
-SSEEEE AALLSSOO
-     ftpd(8)
-
- KTH-KRB                          May 7, 1997                                1
diff --git a/crypto/heimdal/appl/kauth/ChangeLog b/crypto/heimdal/appl/kauth/ChangeLog
deleted file mode 100644
index ac0491fb1766..000000000000
--- a/crypto/heimdal/appl/kauth/ChangeLog
+++ /dev/null
@@ -1,39 +0,0 @@
-1999-12-06  Assar Westerlund  <assar@sics.se>
-
-	* rkinit.c (doit_host): NAT work-around
-	* kauthd.c (doit): type correctness
-
-1999-12-05  Assar Westerlund  <assar@sics.se>
-
-	* kauthd.c: use getnameinfo instead of inaddr2str and inet_ntoa
-
-1999-08-31  Johan Danielsson  <joda@pdc.kth.se>
-
-	* kauth.c: cleanup usage string; handle `kauth -h' gracefully
-	(print usage); add `-a' flag to get the ticket address (useful for
-	firewall configurations)
-
-Thu Apr 15 15:05:33 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
-
-	* kauth.c: add `-v'
-
-Thu Mar 18 11:17:14 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
-
-	* Makefile.am: include Makefile.am.common
-
-Sun Nov 22 10:30:47 1998  Assar Westerlund  <assar@sics.se>
-
-	* Makefile.in (WFLAGS): set
-
-Tue May 26 17:41:47 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
-
-	* kauth.c: use krb_enable_debug
-
-Fri May  1 07:15:18 1998  Assar Westerlund  <assar@sics.se>
-
-	* rkinit.c: unifdef -DHAVE_H_ERRNO
-
-Thu Mar 19 16:07:18 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
-
-	* kauth.c: Check for negative return value from krb_afslog().
-
diff --git a/crypto/heimdal/appl/kauth/Makefile.am b/crypto/heimdal/appl/kauth/Makefile.am
deleted file mode 100644
index a5bf0fdacac6..000000000000
--- a/crypto/heimdal/appl/kauth/Makefile.am
+++ /dev/null
@@ -1,42 +0,0 @@
-# $Id: Makefile.am,v 1.7 1999/04/09 18:22:45 assar Exp $
-
-include $(top_srcdir)/Makefile.am.common
-
-INCLUDES += $(INCLUDE_krb4)
-
-bin_PROGRAMS = kauth
-bin_SCRIPTS = ksrvtgt
-libexec_PROGRAMS = kauthd
-
-EXTRA_DIST = zrefresh ksrvtgt.in
-
-kauth_SOURCES = \
-	kauth.c \
-	kauth.h \
-	rkinit.c \
-	marshall.c \
-	encdata.c
-
-kauthd_SOURCES = \
-	kauthd.c \
-	kauth.h \
-	marshall.c \
-	encdata.c
-
-ksrvtgt: ksrvtgt.in
-	sed -e "s!%bindir%!$(bindir)!" $(srcdir)/ksrvtgt.in > $@
-	chmod +x $@
-
-install-exec-local:
-	if test -f $(bindir)/zrefresh -o -r  $(bindir)/zrefresh; then \
-	  true; \
-	else \
-	  $(INSTALL_PROGRAM) $(srcdir)/zrefresh $(bindir)/`echo zrefresh | sed '$(transform)'`; \
-	fi
-
-LDADD = \
-	$(LIB_kafs)				\
-	$(LIB_krb5)				\
-	$(LIB_krb4)				\
-	$(top_builddir)/lib/des/libdes.la	\
-	$(LIB_roken)
diff --git a/crypto/heimdal/appl/kauth/Makefile.in b/crypto/heimdal/appl/kauth/Makefile.in
deleted file mode 100644
index f9c005f68f34..000000000000
--- a/crypto/heimdal/appl/kauth/Makefile.in
+++ /dev/null
@@ -1,739 +0,0 @@
-# Makefile.in generated automatically by automake 1.4 from Makefile.am
-
-# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
-# This Makefile.in is free software; the Free Software Foundation
-# gives unlimited permission to copy and/or distribute it,
-# with or without modifications, as long as this notice is preserved.
-
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
-# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
-# PARTICULAR PURPOSE.
-
-# $Id: Makefile.am,v 1.7 1999/04/09 18:22:45 assar Exp $
-
-
-# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $
-
-
-# $Id: Makefile.am.common,v 1.13 1999/11/01 03:19:58 assar Exp $
-
-
-SHELL = @SHELL@
-
-srcdir = @srcdir@
-top_srcdir = @top_srcdir@
-VPATH = @srcdir@
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-
-bindir = @bindir@
-sbindir = @sbindir@
-libexecdir = @libexecdir@
-datadir = @datadir@
-sysconfdir = @sysconfdir@
-sharedstatedir = @sharedstatedir@
-localstatedir = @localstatedir@
-libdir = @libdir@
-infodir = @infodir@
-mandir = @mandir@
-includedir = @includedir@
-oldincludedir = /usr/include
-
-DESTDIR =
-
-pkgdatadir = $(datadir)/@PACKAGE@
-pkglibdir = $(libdir)/@PACKAGE@
-pkgincludedir = $(includedir)/@PACKAGE@
-
-top_builddir = ../..
-
-ACLOCAL = @ACLOCAL@
-AUTOCONF = @AUTOCONF@
-AUTOMAKE = @AUTOMAKE@
-AUTOHEADER = @AUTOHEADER@
-
-INSTALL = @INSTALL@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@ $(AM_INSTALL_PROGRAM_FLAGS)
-INSTALL_DATA = @INSTALL_DATA@
-INSTALL_SCRIPT = @INSTALL_SCRIPT@
-transform = @program_transform_name@
-
-NORMAL_INSTALL = :
-PRE_INSTALL = :
-POST_INSTALL = :
-NORMAL_UNINSTALL = :
-PRE_UNINSTALL = :
-POST_UNINSTALL = :
-host_alias = @host_alias@
-host_triplet = @host@
-AFS_EXTRA_LD = @AFS_EXTRA_LD@
-AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
-AWK = @AWK@
-CANONICAL_HOST = @CANONICAL_HOST@
-CATMAN = @CATMAN@
-CATMANEXT = @CATMANEXT@
-CC = @CC@
-DBLIB = @DBLIB@
-EXEEXT = @EXEEXT@
-EXTRA_LIB45 = @EXTRA_LIB45@
-GROFF = @GROFF@
-INCLUDE_ = @INCLUDE_@
-LD = @LD@
-LEX = @LEX@
-LIBOBJS = @LIBOBJS@
-LIBTOOL = @LIBTOOL@
-LIB_ = @LIB_@
-LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
-LIB_kdb = @LIB_kdb@
-LIB_otp = @LIB_otp@
-LIB_roken = @LIB_roken@
-LIB_security = @LIB_security@
-LN_S = @LN_S@
-LTLIBOBJS = @LTLIBOBJS@
-MAKEINFO = @MAKEINFO@
-MAKE_X_PROGS_BIN_PROGS = @MAKE_X_PROGS_BIN_PROGS@
-MAKE_X_PROGS_BIN_SCRPTS = @MAKE_X_PROGS_BIN_SCRPTS@
-MAKE_X_PROGS_LIBEXEC_PROGS = @MAKE_X_PROGS_LIBEXEC_PROGS@
-NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@
-NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@
-NM = @NM@
-NROFF = @NROFF@
-OBJEXT = @OBJEXT@
-PACKAGE = @PACKAGE@
-RANLIB = @RANLIB@
-VERSION = @VERSION@
-VOID_RETSIGTYPE = @VOID_RETSIGTYPE@
-WFLAGS = @WFLAGS@
-WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
-WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
-YACC = @YACC@
-
-AUTOMAKE_OPTIONS = foreign no-dependencies
-
-SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x
-
-INCLUDES = -I$(top_builddir)/include $(INCLUDE_krb4)
-
-AM_CFLAGS =  $(WFLAGS)
-
-COMPILE_ET = $(top_builddir)/lib/com_err/compile_et
-
-buildinclude = $(top_builddir)/include
-
-LIB_XauReadAuth = @LIB_XauReadAuth@
-LIB_crypt = @LIB_crypt@
-LIB_dbm_firstkey = @LIB_dbm_firstkey@
-LIB_dbopen = @LIB_dbopen@
-LIB_dlopen = @LIB_dlopen@
-LIB_dn_expand = @LIB_dn_expand@
-LIB_el_init = @LIB_el_init@
-LIB_getattr = @LIB_getattr@
-LIB_gethostbyname = @LIB_gethostbyname@
-LIB_getpwent_r = @LIB_getpwent_r@
-LIB_getpwnam_r = @LIB_getpwnam_r@
-LIB_getsockopt = @LIB_getsockopt@
-LIB_logout = @LIB_logout@
-LIB_logwtmp = @LIB_logwtmp@
-LIB_odm_initialize = @LIB_odm_initialize@
-LIB_readline = @LIB_readline@
-LIB_res_search = @LIB_res_search@
-LIB_setpcred = @LIB_setpcred@
-LIB_setsockopt = @LIB_setsockopt@
-LIB_socket = @LIB_socket@
-LIB_syslog = @LIB_syslog@
-LIB_tgetent = @LIB_tgetent@
-
-HESIODLIB = @HESIODLIB@
-HESIODINCLUDE = @HESIODINCLUDE@
-INCLUDE_hesiod = @INCLUDE_hesiod@
-LIB_hesiod = @LIB_hesiod@
-
-INCLUDE_krb4 = @INCLUDE_krb4@
-LIB_krb4 = @LIB_krb4@
-
-INCLUDE_readline = @INCLUDE_readline@
-
-LEXLIB = @LEXLIB@
-
-cat1dir = $(mandir)/cat1
-cat3dir = $(mandir)/cat3
-cat5dir = $(mandir)/cat5
-cat8dir = $(mandir)/cat8
-
-MANRX = \(.*\)\.\([0-9]\)
-CATSUFFIX = @CATSUFFIX@
-
-NROFF_MAN = groff -mandoc -Tascii
-
-@KRB4_TRUE@LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
-
-@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la 	$(top_builddir)/lib/asn1/libasn1.la
-@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
-
-CHECK_LOCAL = $(PROGRAMS)
-
-bin_PROGRAMS = kauth
-bin_SCRIPTS = ksrvtgt
-libexec_PROGRAMS = kauthd
-
-EXTRA_DIST = zrefresh ksrvtgt.in
-
-kauth_SOURCES =  	kauth.c 	kauth.h 	rkinit.c 	marshall.c 	encdata.c
-
-
-kauthd_SOURCES =  	kauthd.c 	kauth.h 	marshall.c 	encdata.c
-
-
-LDADD =  	$(LIB_kafs)					$(LIB_krb5)					$(LIB_krb4)					$(top_builddir)/lib/des/libdes.la		$(LIB_roken)
-
-mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
-CONFIG_HEADER = ../../include/config.h
-CONFIG_CLEAN_FILES = 
-bin_PROGRAMS =  kauth$(EXEEXT)
-libexec_PROGRAMS =  kauthd$(EXEEXT)
-PROGRAMS =  $(bin_PROGRAMS) $(libexec_PROGRAMS)
-
-
-DEFS = @DEFS@ -I. -I$(srcdir) -I../../include
-CPPFLAGS = @CPPFLAGS@
-LDFLAGS = @LDFLAGS@
-LIBS = @LIBS@
-X_CFLAGS = @X_CFLAGS@
-X_LIBS = @X_LIBS@
-X_EXTRA_LIBS = @X_EXTRA_LIBS@
-X_PRE_LIBS = @X_PRE_LIBS@
-kauth_OBJECTS =  kauth.$(OBJEXT) rkinit.$(OBJEXT) marshall.$(OBJEXT) \
-encdata.$(OBJEXT)
-kauth_LDADD = $(LDADD)
-@KRB4_TRUE@@KRB5_FALSE@kauth_DEPENDENCIES =  \
-@KRB4_TRUE@@KRB5_FALSE@$(top_builddir)/lib/kafs/libkafs.la \
-@KRB4_TRUE@@KRB5_FALSE@$(top_builddir)/lib/des/libdes.la
-@KRB4_FALSE@@KRB5_TRUE@kauth_DEPENDENCIES =  \
-@KRB4_FALSE@@KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
-@KRB4_FALSE@@KRB5_TRUE@$(top_builddir)/lib/asn1/libasn1.la \
-@KRB4_FALSE@@KRB5_TRUE@$(top_builddir)/lib/des/libdes.la
-@KRB4_FALSE@@KRB5_FALSE@kauth_DEPENDENCIES =  \
-@KRB4_FALSE@@KRB5_FALSE@$(top_builddir)/lib/des/libdes.la
-@KRB4_TRUE@@KRB5_TRUE@kauth_DEPENDENCIES =  \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/kafs/libkafs.la \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/asn1/libasn1.la \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/des/libdes.la
-kauth_LDFLAGS = 
-kauthd_OBJECTS =  kauthd.$(OBJEXT) marshall.$(OBJEXT) encdata.$(OBJEXT)
-kauthd_LDADD = $(LDADD)
-@KRB4_TRUE@@KRB5_FALSE@kauthd_DEPENDENCIES =  \
-@KRB4_TRUE@@KRB5_FALSE@$(top_builddir)/lib/kafs/libkafs.la \
-@KRB4_TRUE@@KRB5_FALSE@$(top_builddir)/lib/des/libdes.la
-@KRB4_FALSE@@KRB5_TRUE@kauthd_DEPENDENCIES =  \
-@KRB4_FALSE@@KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
-@KRB4_FALSE@@KRB5_TRUE@$(top_builddir)/lib/asn1/libasn1.la \
-@KRB4_FALSE@@KRB5_TRUE@$(top_builddir)/lib/des/libdes.la
-@KRB4_FALSE@@KRB5_FALSE@kauthd_DEPENDENCIES =  \
-@KRB4_FALSE@@KRB5_FALSE@$(top_builddir)/lib/des/libdes.la
-@KRB4_TRUE@@KRB5_TRUE@kauthd_DEPENDENCIES =  \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/kafs/libkafs.la \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/asn1/libasn1.la \
-@KRB4_TRUE@@KRB5_TRUE@$(top_builddir)/lib/des/libdes.la
-kauthd_LDFLAGS = 
-SCRIPTS =  $(bin_SCRIPTS)
-
-CFLAGS = @CFLAGS@
-COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
-LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
-CCLD = $(CC)
-LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@
-DIST_COMMON =  ChangeLog Makefile.am Makefile.in
-
-
-DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
-
-TAR = tar
-GZIP_ENV = --best
-SOURCES = $(kauth_SOURCES) $(kauthd_SOURCES)
-OBJECTS = $(kauth_OBJECTS) $(kauthd_OBJECTS)
-
-all: all-redirect
-.SUFFIXES:
-.SUFFIXES: .1 .3 .5 .8 .S .c .cat1 .cat3 .cat5 .cat8 .et .h .lo .o .obj .s .x
-$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common
-	cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/kauth/Makefile
-
-Makefile: $(srcdir)/Makefile.in  $(top_builddir)/config.status
-	cd $(top_builddir) \
-	  && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
-
-
-mostlyclean-binPROGRAMS:
-
-clean-binPROGRAMS:
-	-test -z "$(bin_PROGRAMS)" || rm -f $(bin_PROGRAMS)
-
-distclean-binPROGRAMS:
-
-maintainer-clean-binPROGRAMS:
-
-install-binPROGRAMS: $(bin_PROGRAMS)
-	@$(NORMAL_INSTALL)
-	$(mkinstalldirs) $(DESTDIR)$(bindir)
-	@list='$(bin_PROGRAMS)'; for p in $$list; do \
-	  if test -f $$p; then \
-	    echo " $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $$p $(DESTDIR)$(bindir)/`echo $$p|sed 's/$(EXEEXT)$$//'|sed '$(transform)'|sed 's/$$/$(EXEEXT)/'`"; \
-	    $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $$p $(DESTDIR)$(bindir)/`echo $$p|sed 's/$(EXEEXT)$$//'|sed '$(transform)'|sed 's/$$/$(EXEEXT)/'`; \
-	  else :; fi; \
-	done
-
-uninstall-binPROGRAMS:
-	@$(NORMAL_UNINSTALL)
-	list='$(bin_PROGRAMS)'; for p in $$list; do \
-	  rm -f $(DESTDIR)$(bindir)/`echo $$p|sed 's/$(EXEEXT)$$//'|sed '$(transform)'|sed 's/$$/$(EXEEXT)/'`; \
-	done
-
-mostlyclean-libexecPROGRAMS:
-
-clean-libexecPROGRAMS:
-	-test -z "$(libexec_PROGRAMS)" || rm -f $(libexec_PROGRAMS)
-
-distclean-libexecPROGRAMS:
-
-maintainer-clean-libexecPROGRAMS:
-
-install-libexecPROGRAMS: $(libexec_PROGRAMS)
-	@$(NORMAL_INSTALL)
-	$(mkinstalldirs) $(DESTDIR)$(libexecdir)
-	@list='$(libexec_PROGRAMS)'; for p in $$list; do \
-	  if test -f $$p; then \
-	    echo " $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $$p $(DESTDIR)$(libexecdir)/`echo $$p|sed 's/$(EXEEXT)$$//'|sed '$(transform)'|sed 's/$$/$(EXEEXT)/'`"; \
-	    $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $$p $(DESTDIR)$(libexecdir)/`echo $$p|sed 's/$(EXEEXT)$$//'|sed '$(transform)'|sed 's/$$/$(EXEEXT)/'`; \
-	  else :; fi; \
-	done
-
-uninstall-libexecPROGRAMS:
-	@$(NORMAL_UNINSTALL)
-	list='$(libexec_PROGRAMS)'; for p in $$list; do \
-	  rm -f $(DESTDIR)$(libexecdir)/`echo $$p|sed 's/$(EXEEXT)$$//'|sed '$(transform)'|sed 's/$$/$(EXEEXT)/'`; \
-	done
-
-.c.o:
-	$(COMPILE) -c $<
-
-# FIXME: We should only use cygpath when building on Windows,
-# and only if it is available.
-.c.obj:
-	$(COMPILE) -c `cygpath -w $<`
-
-.s.o:
-	$(COMPILE) -c $<
-
-.S.o:
-	$(COMPILE) -c $<
-
-mostlyclean-compile:
-	-rm -f *.o core *.core
-	-rm -f *.$(OBJEXT)
-
-clean-compile:
-
-distclean-compile:
-	-rm -f *.tab.c
-
-maintainer-clean-compile:
-
-.c.lo:
-	$(LIBTOOL) --mode=compile $(COMPILE) -c $<
-
-.s.lo:
-	$(LIBTOOL) --mode=compile $(COMPILE) -c $<
-
-.S.lo:
-	$(LIBTOOL) --mode=compile $(COMPILE) -c $<
-
-mostlyclean-libtool:
-	-rm -f *.lo
-
-clean-libtool:
-	-rm -rf .libs _libs
-
-distclean-libtool:
-
-maintainer-clean-libtool:
-
-kauth$(EXEEXT): $(kauth_OBJECTS) $(kauth_DEPENDENCIES)
-	@rm -f kauth$(EXEEXT)
-	$(LINK) $(kauth_LDFLAGS) $(kauth_OBJECTS) $(kauth_LDADD) $(LIBS)
-
-kauthd$(EXEEXT): $(kauthd_OBJECTS) $(kauthd_DEPENDENCIES)
-	@rm -f kauthd$(EXEEXT)
-	$(LINK) $(kauthd_LDFLAGS) $(kauthd_OBJECTS) $(kauthd_LDADD) $(LIBS)
-
-install-binSCRIPTS: $(bin_SCRIPTS)
-	@$(NORMAL_INSTALL)
-	$(mkinstalldirs) $(DESTDIR)$(bindir)
-	@list='$(bin_SCRIPTS)'; for p in $$list; do \
-	  if test -f $$p; then \
-	    echo " $(INSTALL_SCRIPT) $$p $(DESTDIR)$(bindir)/`echo $$p|sed '$(transform)'`"; \
-	    $(INSTALL_SCRIPT) $$p $(DESTDIR)$(bindir)/`echo $$p|sed '$(transform)'`; \
-	  else if test -f $(srcdir)/$$p; then \
-	    echo " $(INSTALL_SCRIPT) $(srcdir)/$$p $(DESTDIR)$(bindir)/`echo $$p|sed '$(transform)'`"; \
-	    $(INSTALL_SCRIPT) $(srcdir)/$$p $(DESTDIR)$(bindir)/`echo $$p|sed '$(transform)'`; \
-	  else :; fi; fi; \
-	done
-
-uninstall-binSCRIPTS:
-	@$(NORMAL_UNINSTALL)
-	list='$(bin_SCRIPTS)'; for p in $$list; do \
-	  rm -f $(DESTDIR)$(bindir)/`echo $$p|sed '$(transform)'`; \
-	done
-
-tags: TAGS
-
-ID: $(HEADERS) $(SOURCES) $(LISP)
-	list='$(SOURCES) $(HEADERS)'; \
-	unique=`for i in $$list; do echo $$i; done | \
-	  awk '    { files[$$0] = 1; } \
-	       END { for (i in files) print i; }'`; \
-	here=`pwd` && cd $(srcdir) \
-	  && mkid -f$$here/ID $$unique $(LISP)
-
-TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) $(LISP)
-	tags=; \
-	here=`pwd`; \
-	list='$(SOURCES) $(HEADERS)'; \
-	unique=`for i in $$list; do echo $$i; done | \
-	  awk '    { files[$$0] = 1; } \
-	       END { for (i in files) print i; }'`; \
-	test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
-	  || (cd $(srcdir) && etags $(ETAGS_ARGS) $$tags  $$unique $(LISP) -o $$here/TAGS)
-
-mostlyclean-tags:
-
-clean-tags:
-
-distclean-tags:
-	-rm -f TAGS ID
-
-maintainer-clean-tags:
-
-distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
-
-subdir = appl/kauth
-
-distdir: $(DISTFILES)
-	@for file in $(DISTFILES); do \
-	  d=$(srcdir); \
-	  if test -d $$d/$$file; then \
-	    cp -pr $$/$$file $(distdir)/$$file; \
-	  else \
-	    test -f $(distdir)/$$file \
-	    || ln $$d/$$file $(distdir)/$$file 2> /dev/null \
-	    || cp -p $$d/$$file $(distdir)/$$file || :; \
-	  fi; \
-	done
-	$(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-hook
-info-am:
-info: info-am
-dvi-am:
-dvi: dvi-am
-check-am: all-am
-	$(MAKE) $(AM_MAKEFLAGS) check-local
-check: check-am
-installcheck-am:
-installcheck: installcheck-am
-install-exec-am: install-binPROGRAMS install-libexecPROGRAMS \
-		install-binSCRIPTS install-exec-local
-	@$(NORMAL_INSTALL)
-	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
-install-exec: install-exec-am
-
-install-data-am: install-data-local
-install-data: install-data-am
-
-install-am: all-am
-	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
-install: install-am
-uninstall-am: uninstall-binPROGRAMS uninstall-libexecPROGRAMS \
-		uninstall-binSCRIPTS
-uninstall: uninstall-am
-all-am: Makefile $(PROGRAMS) $(SCRIPTS) all-local
-all-redirect: all-am
-install-strip:
-	$(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
-installdirs:
-	$(mkinstalldirs)  $(DESTDIR)$(bindir) $(DESTDIR)$(libexecdir) \
-		$(DESTDIR)$(bindir)
-
-
-mostlyclean-generic:
-
-clean-generic:
-
-distclean-generic:
-	-rm -f Makefile $(CONFIG_CLEAN_FILES)
-	-rm -f config.cache config.log stamp-h stamp-h[0-9]*
-
-maintainer-clean-generic:
-mostlyclean-am:  mostlyclean-binPROGRAMS mostlyclean-libexecPROGRAMS \
-		mostlyclean-compile mostlyclean-libtool \
-		mostlyclean-tags mostlyclean-generic
-
-mostlyclean: mostlyclean-am
-
-clean-am:  clean-binPROGRAMS clean-libexecPROGRAMS clean-compile \
-		clean-libtool clean-tags clean-generic mostlyclean-am
-
-clean: clean-am
-
-distclean-am:  distclean-binPROGRAMS distclean-libexecPROGRAMS \
-		distclean-compile distclean-libtool distclean-tags \
-		distclean-generic clean-am
-	-rm -f libtool
-
-distclean: distclean-am
-
-maintainer-clean-am:  maintainer-clean-binPROGRAMS \
-		maintainer-clean-libexecPROGRAMS \
-		maintainer-clean-compile maintainer-clean-libtool \
-		maintainer-clean-tags maintainer-clean-generic \
-		distclean-am
-	@echo "This command is intended for maintainers to use;"
-	@echo "it deletes files that may require special tools to rebuild."
-
-maintainer-clean: maintainer-clean-am
-
-.PHONY: mostlyclean-binPROGRAMS distclean-binPROGRAMS clean-binPROGRAMS \
-maintainer-clean-binPROGRAMS uninstall-binPROGRAMS install-binPROGRAMS \
-mostlyclean-libexecPROGRAMS distclean-libexecPROGRAMS \
-clean-libexecPROGRAMS maintainer-clean-libexecPROGRAMS \
-uninstall-libexecPROGRAMS install-libexecPROGRAMS mostlyclean-compile \
-distclean-compile clean-compile maintainer-clean-compile \
-mostlyclean-libtool distclean-libtool clean-libtool \
-maintainer-clean-libtool uninstall-binSCRIPTS install-binSCRIPTS tags \
-mostlyclean-tags distclean-tags clean-tags maintainer-clean-tags \
-distdir info-am info dvi-am dvi check-local check check-am \
-installcheck-am installcheck install-exec-local install-exec-am \
-install-exec install-data-local install-data-am install-data install-am \
-install uninstall-am uninstall all-local all-redirect all-am all \
-installdirs mostlyclean-generic distclean-generic clean-generic \
-maintainer-clean-generic clean mostlyclean distclean maintainer-clean
-
-
-install-suid-programs:
-	@foo='$(bin_SUIDS)'; \
-	for file in $$foo; do \
-	x=$(DESTDIR)$(bindir)/$$file; \
-	if chown 0:0 $$x && chmod u+s $$x; then :; else \
-	chmod 0 $$x; fi; done
-
-install-exec-hook: install-suid-programs
-
-install-build-headers:: $(include_HEADERS) $(build_HEADERZ)
-	@foo='$(include_HEADERS) $(build_HEADERZ)'; \
-	for f in $$foo; do \
-		f=`basename $$f`; \
-		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
-		else file="$$f"; fi; \
-		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
-		: ; else \
-			echo " cp $$file $(buildinclude)/$$f"; \
-			cp $$file $(buildinclude)/$$f; \
-		fi ; \
-	done
-
-all-local: install-build-headers
-#NROFF_MAN = nroff -man
-.1.cat1:
-	$(NROFF_MAN) $< > $@
-.3.cat3:
-	$(NROFF_MAN) $< > $@
-.5.cat5:
-	$(NROFF_MAN) $< > $@
-.8.cat8:
-	$(NROFF_MAN) $< > $@
-
-dist-cat1-mans:
-	@foo='$(man1_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.1) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-cat3-mans:
-	@foo='$(man3_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.3) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-cat5-mans:
-	@foo='$(man5_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.5) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-cat8-mans:
-	@foo='$(man8_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.8) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
-
-install-cat1-mans:
-	@ext=1;\
-	foo='$(man1_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.1) foo="$$foo $$i";; \
-	esac; done; \
-	if test "$$foo"; then \
-		$(mkinstalldirs) $(DESTDIR)$(cat1dir); \
-		for x in $$foo; do \
-			f=`echo $$x | sed 's/\.[^.]*$$/.cat1/'`; \
-			if test -f "$(srcdir)/$$f"; then \
-				b=`echo $$x | sed 's!$(MANRX)!\1!'`; \
-				echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat1dir)/$$b.$(CATSUFFIX)";\
-				$(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat1dir)/$$b.$(CATSUFFIX);\
-			 fi; \
-		done ;\
-	fi
-
-install-cat3-mans:
-	@ext=3;\
-	foo='$(man3_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.3) foo="$$foo $$i";; \
-	esac; done; \
-	if test "$$foo"; then \
-		$(mkinstalldirs) $(DESTDIR)$(cat3dir); \
-		for x in $$foo; do \
-			f=`echo $$x | sed 's/\.[^.]*$$/.cat3/'`; \
-			if test -f "$(srcdir)/$$f"; then \
-				b=`echo $$x | sed 's!$(MANRX)!\1!'`; \
-				echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat3dir)/$$b.$(CATSUFFIX)";\
-				$(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat3dir)/$$b.$(CATSUFFIX);\
-			 fi; \
-		done ;\
-	fi
-
-install-cat5-mans:
-	@ext=5;\
-	foo='$(man5_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.5) foo="$$foo $$i";; \
-	esac; done; \
-	if test "$$foo"; then \
-		$(mkinstalldirs) $(DESTDIR)$(cat5dir); \
-		for x in $$foo; do \
-			f=`echo $$x | sed 's/\.[^.]*$$/.cat5/'`; \
-			if test -f "$(srcdir)/$$f"; then \
-				b=`echo $$x | sed 's!$(MANRX)!\1!'`; \
-				echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat5dir)/$$b.$(CATSUFFIX)";\
-				$(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat5dir)/$$b.$(CATSUFFIX);\
-			 fi; \
-		done ;\
-	fi
-
-install-cat8-mans:
-	@ext=8;\
-	foo='$(man8_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.8) foo="$$foo $$i";; \
-	esac; done; \
-	if test "$$foo"; then \
-		$(mkinstalldirs) $(DESTDIR)$(cat8dir); \
-		for x in $$foo; do \
-			f=`echo $$x | sed 's/\.[^.]*$$/.cat8/'`; \
-			if test -f "$(srcdir)/$$f"; then \
-				b=`echo $$x | sed 's!$(MANRX)!\1!'`; \
-				echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat8dir)/$$b.$(CATSUFFIX)";\
-				$(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat8dir)/$$b.$(CATSUFFIX);\
-			 fi; \
-		done ;\
-	fi
-
-install-cat-mans: install-cat1-mans install-cat3-mans install-cat5-mans install-cat8-mans
-
-install-data-local: install-cat-mans
-
-.et.h:
-	$(COMPILE_ET) $<
-.et.c:
-	$(COMPILE_ET) $<
-
-.x.c:
-	@cmp -s $< $@ 2> /dev/null || cp $< $@
-
-check-local::
-	@foo='$(CHECK_LOCAL)'; \
-	  if test "$$foo"; then \
-	  failed=0; all=0; \
-	  for i in $$foo; do \
-	    all=`expr $$all + 1`; \
-	    if ./$$i --version > /dev/null 2>&1; then \
-	      echo "PASS: $$i"; \
-	    else \
-	      echo "FAIL: $$i"; \
-	      failed=`expr $$failed + 1`; \
-	    fi; \
-	  done; \
-	  if test "$$failed" -eq 0; then \
-	    banner="All $$all tests passed"; \
-	  else \
-	    banner="$$failed of $$all tests failed"; \
-	  fi; \
-	  dashes=`echo "$$banner" | sed s/./=/g`; \
-	  echo "$$dashes"; \
-	  echo "$$banner"; \
-	  echo "$$dashes"; \
-	  test "$$failed" -eq 0; \
-	fi
-
-ksrvtgt: ksrvtgt.in
-	sed -e "s!%bindir%!$(bindir)!" $(srcdir)/ksrvtgt.in > $@
-	chmod +x $@
-
-install-exec-local:
-	if test -f $(bindir)/zrefresh -o -r  $(bindir)/zrefresh; then \
-	  true; \
-	else \
-	  $(INSTALL_PROGRAM) $(srcdir)/zrefresh $(bindir)/`echo zrefresh | sed '$(transform)'`; \
-	fi
-
-# Tell versions [3.59,3.63) of GNU make to not export all variables.
-# Otherwise a system limit (for SysV at least) may be exceeded.
-.NOEXPORT:
diff --git a/crypto/heimdal/appl/kauth/encdata.c b/crypto/heimdal/appl/kauth/encdata.c
deleted file mode 100644
index 886f5490bad8..000000000000
--- a/crypto/heimdal/appl/kauth/encdata.c
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden).
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 
- * 3. Neither the name of the Institute nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "kauth.h"
-
-RCSID("$Id: encdata.c,v 1.10 1999/12/02 16:58:31 joda Exp $");
-
-int
-write_encrypted (int fd, void *buf, size_t len, des_key_schedule schedule,
-		 des_cblock *session, struct sockaddr_in *me,
-		 struct sockaddr_in *him)
-{
-     void *outbuf;
-     int32_t outlen, l;
-     int i;
-     unsigned char tmp[4];
-
-     outbuf = malloc(len + 30);
-     if (outbuf == NULL)
-	  return -1;
-     outlen = krb_mk_priv (buf, outbuf, len, schedule, session, me, him);
-     if (outlen < 0) {
-	  free(outbuf);
-	  return -1;
-     }
-     l = outlen;
-     for(i = 3; i >= 0; i--, l = l >> 8)
-	 tmp[i] = l & 0xff;
-     if (krb_net_write (fd, tmp, 4) != 4 ||
-	 krb_net_write (fd, outbuf, outlen) != outlen) {
-	  free(outbuf);
-	  return -1;
-     }
-     
-     free(outbuf);
-     return 0;
-}
-
-
-int
-read_encrypted (int fd, void *buf, size_t len, void **ret,
-		des_key_schedule schedule, des_cblock *session,
-		struct sockaddr_in *him, struct sockaddr_in *me)
-{
-     int status;
-     int32_t l;
-     MSG_DAT msg;
-     unsigned char tmp[4];
-
-     l = krb_net_read (fd, tmp, 4);
-     if (l != 4)
-	 return l;
-     l = (tmp[0] << 24) | (tmp[1] << 16) | (tmp[2] << 8) | tmp[3];
-     if (l > len)
-	  return -1;
-     if (krb_net_read (fd, buf, l) != l)
-	  return -1;
-     status = krb_rd_priv (buf, l, schedule, session, him, me, &msg);
-     if (status != RD_AP_OK) {
-	  fprintf (stderr, "read_encrypted: %s\n",
-		   krb_get_err_text(status));
-	  return -1;
-     }
-     *ret  = msg.app_data;
-     return  msg.app_length;
-}
diff --git a/crypto/heimdal/appl/kauth/kauth.c b/crypto/heimdal/appl/kauth/kauth.c
deleted file mode 100644
index 13448a040dda..000000000000
--- a/crypto/heimdal/appl/kauth/kauth.c
+++ /dev/null
@@ -1,385 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997, 1998, 1999 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden).
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 
- * 3. Neither the name of the Institute nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Little program that reads an srvtab or password and
- * creates a suitable ticketfile and associated AFS tokens.
- *
- * If an optional command is given the command is executed in a
- * new PAG and when the command exits the tickets are destroyed.
- */
-
-#include "kauth.h"
-
-RCSID("$Id: kauth.c,v 1.97 1999/12/02 16:58:31 joda Exp $");
-
-krb_principal princ;
-static char srvtab[MaxPathLen];
-static int lifetime = DEFAULT_TKT_LIFE;
-static char remote_tktfile[MaxPathLen];
-static char remoteuser[100];
-static char *cell = 0;
-
-static void
-usage(void)
-{
-    fprintf(stderr,
-	    "Usage:\n"
-	    "  %s [name]\n"
-	    "or\n"
-	    "  %s [-ad] [-n name] [-r remoteuser] [-t remote ticketfile]\n"
-	    "        [-l lifetime (in minutes) ] [-f srvtab ] [-c AFS cell name ]\n"
-	    "        [-h hosts... [--]] [command ... ]\n\n",
-	    __progname, __progname);
-    fprintf(stderr, 
-	    "A fully qualified name can be given: user[.instance][@realm]\n"
-	    "Realm is converted to uppercase!\n");
-    exit(1);
-}
-
-#define EX_NOEXEC	126
-#define EX_NOTFOUND	127
-
-static int
-doexec(int argc, char **argv)
-{
-    int ret = simple_execvp(argv[0], argv);
-    if(ret == -2)
-	warn ("fork");
-    if(ret == -3)
-	warn("waitpid");
-    if(ret < 0)
-	return EX_NOEXEC;
-    if(ret == EX_NOEXEC || ret == EX_NOTFOUND)
-	warnx("Can't exec program ``%s''", argv[0]);
-	
-    return ret;
-}
-
-static RETSIGTYPE
-renew(int sig)
-{
-    int code;
-
-    signal(SIGALRM, renew);
-
-    code = krb_get_svc_in_tkt(princ.name, princ.instance, princ.realm,
-			      KRB_TICKET_GRANTING_TICKET,
-			      princ.realm, lifetime, srvtab);
-    if (code)
-	warnx ("%s", krb_get_err_text(code));
-    else if (k_hasafs())
-	{
-	    if ((code = krb_afslog(cell, NULL)) != 0 && code != KDC_PR_UNKNOWN) {
-		warnx ("%s", krb_get_err_text(code));
-	    }
-	}
-
-    alarm(krb_life_to_time(0, lifetime)/2 - 60);
-    SIGRETURN(0);
-}
-
-static int
-zrefresh(void)
-{
-    switch (fork()) {
-    case -1:
-	err (1, "Warning: Failed to fork zrefresh");
-	return -1;
-    case 0:
-	/* Child */
-	execlp("zrefresh", "zrefresh", 0);
-	execl(BINDIR "/zrefresh", "zrefresh", 0);
-	exit(1);
-    default:
-	/* Parent */
-	break;
-    }
-    return 0;
-}
-
-static int
-key_to_key(const char *user,
-	   char *instance,
-	   const char *realm,
-	   const void *arg,
-	   des_cblock *key)
-{
-    memcpy(key, arg, sizeof(des_cblock));
-    return 0;
-}
-
-static int
-get_ticket_address(krb_principal *princ, des_cblock *key)
-{
-    int code;
-    unsigned char flags;
-    krb_principal service;
-    u_int32_t addr;
-    struct in_addr addr2;
-    des_cblock session;
-    int life;
-    u_int32_t time_sec;
-    des_key_schedule schedule;
-    CREDENTIALS c;
-	
-    code = get_ad_tkt(princ->name, princ->instance, princ->realm, 0);
-    if(code) {
-	warnx("get_ad_tkt: %s\n", krb_get_err_text(code));
-	return code;
-    }
-    code = krb_get_cred(princ->name, princ->instance, princ->realm, &c);
-    if(code) {
-	warnx("krb_get_cred: %s\n", krb_get_err_text(code));
-	return code;
-    }
-
-    des_set_key(key, schedule);
-    code = decomp_ticket(&c.ticket_st, 
-			 &flags,
-			 princ->name,
-			 princ->instance,
-			 princ->realm,
-			 &addr,
-			 session,
-			 &life,
-			 &time_sec,
-			 service.name,
-			 service.instance,
-			 key,
-			 schedule);
-    if(code) {
-	warnx("decomp_ticket: %s\n", krb_get_err_text(code));
-	return code;
-    }
-    memset(&session, 0, sizeof(session));
-    memset(schedule, 0, sizeof(schedule));
-    addr2.s_addr = addr;
-    fprintf(stdout, "ticket address = %s\n", inet_ntoa(addr2));
-} 
-
-
-int
-main(int argc, char **argv)
-{
-    int code, more_args;
-    int ret;
-    int c;
-    char *file;
-    int pflag = 0;
-    int aflag = 0;
-    int version_flag = 0;
-    char passwd[100];
-    des_cblock key;
-    char **host;
-    int nhost;
-    char tf[MaxPathLen];
-
-    set_progname (argv[0]);
-
-    if ((file =  getenv("KRBTKFILE")) == 0)
-	file = TKT_FILE;  
-
-    memset(&princ, 0, sizeof(princ));
-    memset(srvtab, 0, sizeof(srvtab));
-    *remoteuser = '\0';
-    nhost = 0;
-    host = NULL;
-  
-    /* Look for kerberos name */
-    if (argc > 1 &&
-	argv[1][0] != '-' &&
-	krb_parse_name(argv[1], &princ) == 0)
-      {
-	argc--; argv++;
-	strupr(princ.realm);
-      }
-
-    while ((c = getopt(argc, argv, "ar:t:f:hdl:n:c:v")) != -1)
-	switch (c) {
-	case 'a':
-	    aflag++;
-	    break;
-	case 'd':
-	    krb_enable_debug();
-	    _kafs_debug = 1;
-	    aflag++;
-	    break;
-	case 'f':
-	    strlcpy(srvtab, optarg, sizeof(srvtab));
-	    break;
-	case 't':
-	    strlcpy(remote_tktfile, optarg, sizeof(remote_tktfile));
-	    break;
-	case 'r':
-	    strlcpy(remoteuser, optarg, sizeof(remoteuser));
-	    break;
-	case 'l':
-	    lifetime = atoi(optarg);
-	    if (lifetime == -1)
-		lifetime = 255;
-	    else if (lifetime < 5)
-		lifetime = 1;
-	    else
-		lifetime = krb_time_to_life(0, lifetime*60);
-	    if (lifetime > 255)
-		lifetime = 255;
-	    break;
-	case 'n':
-	    if ((code = krb_parse_name(optarg, &princ)) != 0) {
-		warnx ("%s", krb_get_err_text(code));
-		usage();
-	    }
-	    strupr(princ.realm);
-	    pflag = 1;
-	    break;
-	case 'c':
-	    cell = optarg;
-	    break;
-	case 'h':
-	    host = argv + optind;
-	    for(nhost = 0; optind < argc && *argv[optind] != '-'; ++optind)
-		++nhost;
-	    if(nhost == 0)
-		usage();
-	    break;
-	case 'v':
-	    version_flag++;
-	    print_version(NULL);
-	    break;
-	case '?':
-	default:
-	    usage();
-	    break;
-	}
-  
-    if(version_flag) {
-	print_version(NULL);
-	exit(0);
-    }
-    if (princ.name[0] == '\0' && krb_get_default_principal (princ.name, 
-							    princ.instance, 
-							    princ.realm) < 0)
-	errx (1, "Could not get default principal");
-  
-    /* With root tickets assume remote user is root */
-    if (*remoteuser == '\0') {
-      if (strcmp(princ.instance, "root") == 0)
-	strlcpy(remoteuser, princ.instance, sizeof(remoteuser));
-      else
-	strlcpy(remoteuser, princ.name, sizeof(remoteuser));
-    }
-
-    more_args = argc - optind;
-  
-    if (princ.realm[0] == '\0')
-	if (krb_get_lrealm(princ.realm, 1) != KSUCCESS)
-	    strlcpy(princ.realm, KRB_REALM, REALM_SZ);
-  
-    if (more_args) {
-	int f;
-      
-	do{
-	    snprintf(tf, sizeof(tf), "%s%u_%u", TKT_ROOT, (unsigned)getuid(),
-		     (unsigned)(getpid()*time(0)));
-	    f = open(tf, O_CREAT|O_EXCL|O_RDWR);
-	}while(f < 0);
-	close(f);
-	unlink(tf);
-	setenv("KRBTKFILE", tf, 1);
-	krb_set_tkt_string (tf);
-    }
-    
-    if (srvtab[0])
-	{
-	    signal(SIGALRM, renew);
-
-	    code = read_service_key (princ.name, princ.instance, princ.realm, 0, 
-				     srvtab, (char *)&key);
-	    if (code == KSUCCESS)
-		code = krb_get_in_tkt(princ.name, princ.instance, princ.realm,
-				      KRB_TICKET_GRANTING_TICKET,
-				      princ.realm, lifetime,
-				      key_to_key, NULL, key);
-	    alarm(krb_life_to_time(0, lifetime)/2 - 60);
-	}
-    else {
-	char prompt[128];
-	  
-	snprintf(prompt, sizeof(prompt), "%s's Password: ", krb_unparse_name(&princ));
-	if (des_read_pw_string(passwd, sizeof(passwd)-1, prompt, 0)){
-	    memset(passwd, 0, sizeof(passwd));
-	    exit(1);
-	}
-	code = krb_get_pw_in_tkt2(princ.name, princ.instance, princ.realm, 
-				  KRB_TICKET_GRANTING_TICKET, princ.realm, 
-				  lifetime, passwd, &key);
-	
-	memset(passwd, 0, sizeof(passwd));
-    }
-    if (code) {
-	memset (key, 0, sizeof(key));
-	errx (1, "%s", krb_get_err_text(code));
-    }
-
-    if(aflag)
-	get_ticket_address(&princ, &key);
-
-    if (k_hasafs()) {
-	if (more_args)
-	    k_setpag();
-	if ((code = krb_afslog(cell, NULL)) != 0 && code != KDC_PR_UNKNOWN) {
-	    if(code > 0)
-		warnx ("%s", krb_get_err_text(code));
-	    else
-		warnx ("failed to store AFS token");
-	}
-    }
-
-    for(ret = 0; nhost-- > 0; host++)
-	ret += rkinit(&princ, lifetime, remoteuser, remote_tktfile, &key, *host);
-  
-    if (ret)
-	return ret;
-
-    if (more_args) {
-	ret = doexec(more_args, &argv[optind]);
-	dest_tkt();
-	if (k_hasafs())
-	    k_unlog();	 
-    }
-    else
-	zrefresh();
-  
-    return ret;
-}
diff --git a/crypto/heimdal/appl/kauth/kauth.h b/crypto/heimdal/appl/kauth/kauth.h
deleted file mode 100644
index 32243c7d4333..000000000000
--- a/crypto/heimdal/appl/kauth/kauth.h
+++ /dev/null
@@ -1,116 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden).
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 
- * 3. Neither the name of the Institute nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/* $Id: kauth.h,v 1.21 1999/12/02 16:58:31 joda Exp $ */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif /* HAVE_CONFIG_H */
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <ctype.h>
-#include <string.h>
-#include <signal.h>
-#ifdef HAVE_FCNTL_H
-#include <fcntl.h>
-#endif
-#include <errno.h>
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
-#endif
-#ifdef HAVE_PWD_H
-#include <pwd.h>
-#endif
-#ifdef HAVE_GRP_H
-#include <grp.h>
-#endif
-
-#ifdef TIME_WITH_SYS_TIME
-#include <sys/time.h>
-#include <time.h>
-#elif defined(HAVE_SYS_TIME_H)
-#include <sys/time.h>
-#else
-#include <time.h>
-#endif
-#ifdef HAVE_SYS_RESOURCE_H
-#include <sys/resource.h>
-#endif /* HAVE_SYS_RESOURCE_H */
-#ifdef HAVE_SYS_WAIT_H
-#include <sys/wait.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#endif
-#ifdef HAVE_NETINET_IN_H
-#include <netinet/in.h>
-#endif
-#ifdef HAVE_ARPA_INET_H
-#include <arpa/inet.h>
-#endif
-#ifdef HAVE_NETDB_H
-#include <netdb.h>
-#endif
-#ifdef SOCKS
-#include <socks.h>
-/* This doesn't belong here. */
-struct tm *localtime(const time_t *);
-struct hostent  *gethostbyname(const char *);
-#endif
-
-#include <err.h>
-
-#include <krb.h>
-#include <kafs.h>
-
-#include <roken.h>
-
-#define KAUTH_PORT 2120
-
-#define KAUTH_VERSION "RKINIT.0"
-
-int rkinit (krb_principal*, int, char*, char*, des_cblock*, char*);
-
-int write_encrypted (int, void*, size_t, des_key_schedule,
-		     des_cblock*, struct sockaddr_in*, struct sockaddr_in*);
-
-int read_encrypted (int, void*, size_t, void **, des_key_schedule,
-		    des_cblock*, struct sockaddr_in*, struct sockaddr_in*);
-
-int pack_args (char *, size_t, krb_principal*, int, const char*, const char*);
-
-int unpack_args (const char*, krb_principal*, int*, char*, char*);
diff --git a/crypto/heimdal/appl/kauth/kauthd.c b/crypto/heimdal/appl/kauth/kauthd.c
deleted file mode 100644
index fe0ceb2da855..000000000000
--- a/crypto/heimdal/appl/kauth/kauthd.c
+++ /dev/null
@@ -1,207 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997, 1998 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden).
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 
- * 3. Neither the name of the Institute nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "kauth.h"
-
-RCSID("$Id: kauthd.c,v 1.27 1999/12/06 16:46:05 assar Exp $");
-
-krb_principal princ;
-static char locuser[SNAME_SZ];
-static int  lifetime;
-static char tktfile[MaxPathLen];
-
-struct remote_args {
-     int sock;
-     des_key_schedule *schedule;
-     des_cblock *session;
-     struct sockaddr_in *me, *her;
-};
-
-static int
-decrypt_remote_tkt (const char *user,
-		    const char *inst,
-		    const char *realm,
-		    const void *varg,
-		    key_proc_t key_proc,
-		    KTEXT *cipp)
-{
-     char buf[BUFSIZ];
-     void *ptr;
-     int len;
-     KTEXT cip  = *cipp;
-     struct remote_args *args = (struct remote_args *)varg;
-
-     write_encrypted (args->sock, cip->dat, cip->length,
-		      *args->schedule, args->session, args->me,
-		      args->her);
-     len = read_encrypted (args->sock, buf, sizeof(buf), &ptr, *args->schedule,
-			   args->session, args->her, args->me);
-     memcpy(cip->dat, ptr, cip->length);
-	  
-     return 0;
-}
-
-static int
-doit(int sock)
-{
-     int status;
-     KTEXT_ST ticket;
-     AUTH_DAT auth;
-     char instance[INST_SZ];
-     des_key_schedule schedule;
-     struct sockaddr_in thisaddr, thataddr;
-     int addrlen;
-     int len;
-     char buf[BUFSIZ];
-     void *data;
-     struct passwd *passwd;
-     char version[KRB_SENDAUTH_VLEN + 1];
-     char remotehost[MaxHostNameLen];
-
-     addrlen = sizeof(thisaddr);
-     if (getsockname (sock, (struct sockaddr *)&thisaddr, &addrlen) < 0 ||
-	 addrlen != sizeof(thisaddr)) {
-	  return 1;
-     }
-     addrlen = sizeof(thataddr);
-     if (getpeername (sock, (struct sockaddr *)&thataddr, &addrlen) < 0 ||
-	 addrlen != sizeof(thataddr)) {
-	  return 1;
-     }
-
-     getnameinfo_verified ((struct sockaddr *)&thataddr, sizeof(thataddr),
-			   remotehost, sizeof(remotehost),
-			   NULL, 0, 0);
-
-     k_getsockinst (sock, instance, sizeof(instance));
-     status = krb_recvauth (KOPT_DO_MUTUAL, sock, &ticket, "rcmd", instance,
-			    &thataddr, &thisaddr, &auth, "", schedule,
-			    version);
-     if (status != KSUCCESS ||
-	 strncmp(version, KAUTH_VERSION, KRB_SENDAUTH_VLEN) != 0) {
-	  return 1;
-     }
-     len = read_encrypted (sock, buf, sizeof(buf), &data, schedule,
-			   &auth.session, &thataddr, &thisaddr);
-     if (len < 0) {
-	  write_encrypted (sock, "read_enc failed",
-			   sizeof("read_enc failed") - 1, schedule,
-			   &auth.session, &thisaddr, &thataddr);
-	  return 1;
-     }
-     if (unpack_args(data, &princ, &lifetime, locuser,
-		     tktfile)) {
-	  write_encrypted (sock, "unpack_args failed",
-			   sizeof("unpack_args failed") - 1, schedule,
-			   &auth.session, &thisaddr, &thataddr);
-	  return 1;
-     }
-
-     if( kuserok(&auth, locuser) != 0) {
-	 snprintf(buf, sizeof(buf), "%s cannot get tickets for %s",
-		  locuser, krb_unparse_name(&princ));
-	 syslog (LOG_ERR, "%s", buf);
-	 write_encrypted (sock, buf, strlen(buf), schedule,
-			  &auth.session, &thisaddr, &thataddr);
-	 return 1;
-     }
-     passwd = k_getpwnam (locuser);
-     if (passwd == NULL) {
-	  snprintf (buf, sizeof(buf), "No user '%s'", locuser);
-	  syslog (LOG_ERR, "%s", buf);
-	  write_encrypted (sock, buf, strlen(buf), schedule,
-			   &auth.session, &thisaddr, &thataddr);
-	  return 1;
-     }
-     if (setgid (passwd->pw_gid) ||
-	 initgroups(passwd->pw_name, passwd->pw_gid) ||
-	 setuid(passwd->pw_uid)) {
-	  snprintf (buf, sizeof(buf), "Could not change user");
-	  syslog (LOG_ERR, "%s", buf);
-	  write_encrypted (sock, buf, strlen(buf), schedule,
-			   &auth.session, &thisaddr, &thataddr);
-	  return 1;
-     }
-     write_encrypted (sock, "ok", sizeof("ok") - 1, schedule,
-		      &auth.session, &thisaddr, &thataddr);
-
-     if (*tktfile == 0)
-	 snprintf(tktfile, sizeof(tktfile), "%s%u", TKT_ROOT, (unsigned)getuid());
-     krb_set_tkt_string (tktfile);
-
-     {
-	  struct remote_args arg;
-
-	  arg.sock     = sock;
-	  arg.schedule = &schedule;
-	  arg.session  = &auth.session;
-	  arg.me       = &thisaddr;
-	  arg.her      = &thataddr;
-
-	  status = krb_get_in_tkt (princ.name, princ.instance, princ.realm,
-				   KRB_TICKET_GRANTING_TICKET,
-				   princ.realm,
-				   lifetime, NULL, decrypt_remote_tkt, &arg);
-     }
-     if (status == KSUCCESS) {
-	 char remoteaddr[INET6_ADDRSTRLEN];
-
-	 getnameinfo ((struct sockaddr *)&thataddr, sizeof(thataddr),
-		      remoteaddr, sizeof(remoteaddr),
-		      NULL, 0, NI_NUMERICHOST);
-
-	 syslog (LOG_INFO, "from %s(%s): %s -> %s",
-		 remotehost, remoteaddr,
-		 locuser,
-		 krb_unparse_name (&princ));
-	  write_encrypted (sock, "ok", sizeof("ok") - 1, schedule,
-			   &auth.session, &thisaddr, &thataddr);
-	  return 0;
-     } else {
-	  snprintf (buf, sizeof(buf), "TGT failed: %s", krb_get_err_text(status));
-	  syslog (LOG_NOTICE, "%s", buf);
-	  write_encrypted (sock, buf, strlen(buf), schedule,
-			   &auth.session, &thisaddr, &thataddr);
-	  return 1;
-     }
-}
-
-int
-main (int argc, char **argv)
-{
-    openlog ("kauthd", LOG_ODELAY, LOG_AUTH);
-
-    if(argc > 1 && strcmp(argv[1], "-i") == 0)
-	mini_inetd (k_getportbyname("kauth", "tcp", htons(KAUTH_PORT)));
-    return doit(STDIN_FILENO);
-}
diff --git a/crypto/heimdal/appl/kauth/ksrvtgt.in b/crypto/heimdal/appl/kauth/ksrvtgt.in
deleted file mode 100755
index c2f33bb22fb0..000000000000
--- a/crypto/heimdal/appl/kauth/ksrvtgt.in
+++ /dev/null
@@ -1,14 +0,0 @@
-#! /bin/sh
-# $Id: ksrvtgt.in,v 1.3 1997/09/13 03:39:03 joda Exp $
-
-usage="Usage: `basename $0` name instance [[realm] srvtab]"
-
-if [ $# -lt 2 -o $# -gt 4 ]; then
-	echo "$usage"
-	exit 1
-fi
-
-srvtab="${4-${3-/etc/srvtab}}"
-realm="${4+@$3}"
-
-%bindir%/kauth -n "$1.$2$realm" -l 5 -f "$srvtab"
diff --git a/crypto/heimdal/appl/kauth/marshall.c b/crypto/heimdal/appl/kauth/marshall.c
deleted file mode 100644
index e37b8c969c81..000000000000
--- a/crypto/heimdal/appl/kauth/marshall.c
+++ /dev/null
@@ -1,126 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden).
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 
- * 3. Neither the name of the Institute nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "kauth.h"
-
-RCSID("$Id: marshall.c,v 1.10 1999/12/02 16:58:31 joda Exp $");
-
-int
-pack_args (char *buf,
-	   size_t sz,
-	   krb_principal *pr,
-	   int lifetime,
-	   const char *locuser,
-	   const char *tktfile)
-{
-    char *p = buf;
-    int len;
-
-    p = buf;
-
-    len = strlen(pr->name);
-    if (len >= sz)
-	return -1;
-    memcpy (p, pr->name, len + 1);
-    p += len + 1;
-    sz -= len + 1;
-
-    len = strlen(pr->instance);
-    if (len >= sz)
-	return -1;
-    memcpy (p, pr->instance, len + 1);
-    p += len + 1;
-    sz -= len + 1;
-
-    len = strlen(pr->realm);
-    if (len >= sz)
-	return -1;
-    memcpy(p, pr->realm, len + 1);
-    p += len + 1;
-    sz -= len + 1;
-
-    if (sz < 1)
-	return -1;
-    *p++ = (unsigned char)lifetime;
-
-    len = strlen(locuser);
-    if (len >= sz)
-	return -1;
-    memcpy (p, locuser, len + 1);
-    p += len + 1;
-    sz -= len + 1;
-
-    len = strlen(tktfile);
-    if (len >= sz)
-	return -1;
-    memcpy (p, tktfile, len + 1);
-    p += len + 1;
-    sz -= len + 1;
-
-    return p - buf;
-}
-
-int
-unpack_args (const char *buf, krb_principal *pr, int *lifetime,
-	     char *locuser, char *tktfile)
-{
-    int len;
-
-    len = strlen(buf);
-    if (len >= SNAME_SZ)
-	return -1;
-    strlcpy (pr->name, buf, ANAME_SZ);
-    buf += len + 1;
-    len = strlen (buf);
-    if (len >= INST_SZ)
-	return -1;
-    strlcpy (pr->instance, buf, INST_SZ);
-    buf += len + 1;
-    len = strlen (buf);
-    if (len >= REALM_SZ)
-	return -1;
-    strlcpy (pr->realm, buf, REALM_SZ);
-    buf += len + 1;
-    *lifetime = (unsigned char)*buf++;
-    len = strlen(buf);
-    if (len >= SNAME_SZ)
-	return -1;
-    strlcpy (locuser, buf, SNAME_SZ);
-    buf += len + 1;
-    len = strlen(buf);
-    if (len >= MaxPathLen)
-	return -1;
-    strlcpy (tktfile, buf, MaxPathLen);
-    buf += len + 1;
-    return 0;
-}
diff --git a/crypto/heimdal/appl/kauth/rkinit.c b/crypto/heimdal/appl/kauth/rkinit.c
deleted file mode 100644
index d4b07c6c842d..000000000000
--- a/crypto/heimdal/appl/kauth/rkinit.c
+++ /dev/null
@@ -1,226 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden).
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 
- * 3. Neither the name of the Institute nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "kauth.h"
-
-RCSID("$Id: rkinit.c,v 1.23 1999/12/06 17:07:20 assar Exp $");
-
-static struct in_addr *
-getalladdrs (char *hostname, unsigned *count)
-{
-    struct hostent *hostent;
-    struct in_addr **h;
-    struct in_addr *addr;
-    unsigned naddr;
-    unsigned maxaddr;
-
-    hostent = gethostbyname (hostname);
-    if (hostent == NULL) {
-	warnx ("gethostbyname '%s' failed: %s\n",
-	       hostname,
-	       hstrerror(h_errno));
-	return NULL;
-    }
-    maxaddr = 1;
-    naddr = 0;
-    addr = malloc(sizeof(*addr) * maxaddr);
-    if (addr == NULL) {
-	warnx ("out of memory");
-	return NULL;
-    }
-    for (h = (struct in_addr **)(hostent->h_addr_list);
-	 *h != NULL;
-	 h++) {
-	if (naddr >= maxaddr) {
-	    maxaddr *= 2;
-	    addr = realloc (addr, sizeof(*addr) * maxaddr);
-	    if (addr == NULL) {
-		warnx ("out of memory");
-		return NULL;
-	    }
-	}
-	addr[naddr++] = **h;
-    }
-    addr = realloc (addr, sizeof(*addr) * naddr);
-    if (addr == NULL) {
-	warnx ("out of memory");
-	return NULL;
-    }
-    *count = naddr;
-    return addr;
-}
-
-static int
-doit_host (krb_principal *princ, int lifetime, char *locuser, 
-	   char *tktfile, des_cblock *key, int s, char *hostname)
-{
-    char buf[BUFSIZ];
-    int inlen;
-    KTEXT_ST text;
-    CREDENTIALS cred;
-    MSG_DAT msg;
-    int status;
-    des_key_schedule schedule;
-    struct sockaddr_in thisaddr, thataddr;
-    int addrlen;
-    void *ret;
-
-    addrlen = sizeof(thisaddr);
-    if (getsockname (s, (struct sockaddr *)&thisaddr, &addrlen) < 0 ||
-	addrlen != sizeof(thisaddr)) {
-	warn ("getsockname(%s)", hostname);
-	return 1;
-    }
-    addrlen = sizeof(thataddr);
-    if (getpeername (s, (struct sockaddr *)&thataddr, &addrlen) < 0 ||
-	addrlen != sizeof(thataddr)) {
-	warn ("getpeername(%s)", hostname);
-	return 1;
-    }
-
-    if (krb_get_config_bool("nat_in_use")) {
-	struct in_addr natAddr;
-
-	if (krb_get_our_ip_for_realm(krb_realmofhost(hostname),
-				     &natAddr) == KSUCCESS
-	    || krb_get_our_ip_for_realm (NULL, &natAddr) == KSUCCESS)
-	    thisaddr.sin_addr = natAddr;
-    }
-
-    status = krb_sendauth (KOPT_DO_MUTUAL, s, &text, "rcmd",
-			   hostname, krb_realmofhost (hostname),
-			   getpid(), &msg, &cred, schedule,
-			   &thisaddr, &thataddr, KAUTH_VERSION);
-    if (status != KSUCCESS) {
-	warnx ("%s: %s\n", hostname, krb_get_err_text(status));
-	return 1;
-    }
-    inlen = pack_args (buf, sizeof(buf),
-		       princ, lifetime, locuser, tktfile);
-    if (inlen < 0) {
-	warn ("cannot marshall arguments to %s", hostname);
-	return 1;
-    }
-
-    if (write_encrypted(s, buf, inlen, schedule, &cred.session,
-			&thisaddr, &thataddr) < 0) {
-	warn ("write to %s", hostname);
-	return 1;
-    }
-
-    inlen = read_encrypted (s, buf, sizeof(buf), &ret, schedule,
-			    &cred.session, &thataddr, &thisaddr);
-    if (inlen < 0) {
-	warn ("read from %s failed", hostname);
-	return 1;
-    }
-
-    if (strncmp(ret, "ok", inlen) != 0) {
-	warnx ("error from %s: %.*s\n",
-	       hostname, inlen, (char *)ret);
-	return 1;
-    }
-
-    inlen = read_encrypted (s, buf, sizeof(buf), &ret, schedule,
-			    &cred.session, &thataddr, &thisaddr);
-    if (inlen < 0) {
-	warn ("read from %s", hostname);
-	return 1;
-    }
-     
-    {
-	des_key_schedule key_s;
-
-	des_key_sched(key, key_s);
-	des_pcbc_encrypt(ret, ret, inlen, key_s, key, DES_DECRYPT);
-	memset(key_s, 0, sizeof(key_s));
-    }
-    write_encrypted (s, ret, inlen, schedule, &cred.session,
-		     &thisaddr, &thataddr);
-
-    inlen = read_encrypted (s, buf, sizeof(buf), &ret, schedule,
-			    &cred.session, &thataddr, &thisaddr);
-    if (inlen < 0) {
-	warn ("read from %s", hostname);
-	return 1;
-    }
-
-    if (strncmp(ret, "ok", inlen) != 0) {
-	warnx ("error from %s: %.*s\n",
-	       hostname, inlen, (char *)ret);
-	return 1;
-    }
-    return 0;
-}
-
-int
-rkinit (krb_principal *princ, int lifetime, char *locuser, 
-	char *tktfile, des_cblock *key, char *hostname)
-{
-    struct in_addr *addr;
-    unsigned naddr;
-    unsigned i;
-    int port;
-    int success;
-
-    addr = getalladdrs (hostname, &naddr);
-    if (addr == NULL)
-	return 1;
-    port = k_getportbyname ("kauth", "tcp", htons(KAUTH_PORT));
-    success = 0;
-    for (i = 0; !success && i < naddr; ++i) {
-	struct sockaddr_in a;
-	int s;
-
-	memset(&a, 0, sizeof(a));
-	a.sin_family = AF_INET;
-	a.sin_port   = port;
-	a.sin_addr   = addr[i];
-
-	s = socket (AF_INET, SOCK_STREAM, 0);
-	if (s < 0) {
-	    warn("socket");
-	    return 1;
-	}
-	if (connect(s, (struct sockaddr *)&a, sizeof(a)) < 0) {
-	    warn("connect(%s)", hostname);
-	    continue;
-	}
-
-	success = success || !doit_host (princ, lifetime,
-					 locuser, tktfile, key,
-					 s, hostname);
-	close (s);
-    }
-    return !success;
-}
diff --git a/crypto/heimdal/appl/kauth/zrefresh b/crypto/heimdal/appl/kauth/zrefresh
deleted file mode 100755
index 8347a1b33c0c..000000000000
--- a/crypto/heimdal/appl/kauth/zrefresh
+++ /dev/null
@@ -1,12 +0,0 @@
-#!/bin/sh
-# 
-# @(#) $Id: zrefresh,v 1.3 1996/06/09 19:21:59 joda Exp $
-#
-# Substitute this script with a real zrefresh if running Zephyr. For
-# instance:
-#
-# if [ -f "$WGFILE" ] ; then
-#     zctl load
-# fi
-
-exit 0
diff --git a/crypto/heimdal/appl/kf/kf.cat1 b/crypto/heimdal/appl/kf/kf.cat1
deleted file mode 100644
index b87ed85af22f..000000000000
--- a/crypto/heimdal/appl/kf/kf.cat1
+++ /dev/null
@@ -1,46 +0,0 @@
-
-KF(1)                        UNIX Reference Manual                       KF(1)
-
-NNAAMMEE
-     kkff - securly forward tickets
-
-SSYYNNOOPPSSIISS
-     kkff [--pp _p_o_r_t | ----ppoorrtt=_p_o_r_t] [--ll _l_o_g_i_n | ----llooggiinn=_l_o_g_i_n] [--cc _c_c_a_c_h_e |
-     ----ccccaacchhee=_c_c_a_c_h_e] [--FF | ----ffoorrwwaarrddaabbllee] [--GG | ----nnoo--ffoorrwwaarrddaabbllee] [--hh |
-     ----hheellpp] [----vveerrssiioonn] _h_o_s_t _._._.
-
-DDEESSCCRRIIPPTTIIOONN
-     The kkff program forwards tickets to a remove host through an authenticated
-     and encrypted stream.  Options supported are:
-
-     --pp _p_o_r_t, ----ppoorrtt=_p_o_r_t
-             port to connect to
-
-     --ll _l_o_g_i_n, ----llooggiinn=_l_o_g_i_n
-             remote login name
-
-     --cc _c_c_a_c_h_e, ----ccccaacchhee=_c_c_a_c_h_e
-             remote cred cache
-
-     --FF, ----ffoorrwwaarrddaabbllee
-             forward forwardable credentials
-
-     --GG, ----nnoo--ffoorrwwaarrddaabbllee
-             do not forward forwardable credentials
-
-     --hh, ----hheellpp
-
-     ----vveerrssiioonn
-
-     kkff is useful when you do not want to enter your password on a remote host
-     but want to have your tickets one for example afs.
-
-     In order for kkff to work you will need to acquire your initial ticket with
-     forwardable flag, ie kkiinniitt ----ffoorrwwaarrddaabbllee.
-
-     tteellnneett is able to forward ticket by itself.
-
-SSEEEE AALLSSOO
-     kinit(1),  telnet(1),  kfd(8)
-
- Heimdal                         July 2, 2000                                1
diff --git a/crypto/heimdal/appl/kf/kfd.cat8 b/crypto/heimdal/appl/kf/kfd.cat8
deleted file mode 100644
index 396ffdc8fc68..000000000000
--- a/crypto/heimdal/appl/kf/kfd.cat8
+++ /dev/null
@@ -1,31 +0,0 @@
-
-KFD(8)                   UNIX System Manager's Manual                   KFD(8)
-
-NNAAMMEE
-     kkffdd - receive forwarded tickets
-
-SSYYNNOOPPSSIISS
-     kkffdd [--pp _p_o_r_t | ----ppoorrtt=_p_o_r_t] [--ii | ----iinneettdd] [--RR _r_e_g_p_a_g | ----rreeggppaagg=_r_e_g_p_a_g]
-     [--hh | ----hheellpp] [----vveerrssiioonn]
-
-DDEESSCCRRIIPPTTIIOONN
-     This is the daemon for kf(1).  Supported options:
-
-     --pp _p_o_r_t, ----ppoorrtt=_p_o_r_t
-             port to listen to
-
-     --ii, ----iinneettdd
-             not started from inetd
-
-     --RR _r_e_g_p_a_g, ----rreeggppaagg==_r_e_g_p_a_g
-             path to regpag binary
-
-EEXXAAMMPPLLEESS
-     Put the following in _/_e_t_c_/_i_n_e_t_d_._c_o_n_f:
-
-     kf      stream  tcp     nowait  root    /usr/heimdal/libexec/kfd        kfd
-
-SSEEEE AALLSSOO
-     kf(1)
-
- Heimdal                         July 2, 2000                                1
diff --git a/crypto/heimdal/appl/kx/kx.cat1 b/crypto/heimdal/appl/kx/kx.cat1
deleted file mode 100644
index ce22926ec6a1..000000000000
--- a/crypto/heimdal/appl/kx/kx.cat1
+++ /dev/null
@@ -1,39 +0,0 @@
-
-KX(1)                        UNIX Reference Manual                       KX(1)
-
-NNAAMMEE
-     kkxx - securely forward X conections
-
-SSYYNNOOPPSSIISS
-     _k_x [--ll _u_s_e_r_n_a_m_e] [--kk] [--dd] [--tt] [--pp _p_o_r_t] [--PP] _h_o_s_t
-
-DDEESSCCRRIIPPTTIIOONN
-     The kkxx program forwards a X connection from a remote client to a local
-     screen through an authenticated and encrypted stream.  Options supported
-     by kkxx:
-
-     --ll      Log in on remote the host as user _u_s_e_r_n_a_m_e.
-
-     --kk      Do not enable keep-alives on the TCP connections.
-
-     --dd      Do not fork. This is mainly useful for debugging.
-
-     --tt      Listen not only on a UNIX-domain socket but on a TCP socket as
-             well.
-
-     --pp      Use the port _p_o_r_t.
-
-     --PP      Force passive mode.
-
-     This program is used by rrxxtteellnneett and rrxxtteerrmm and you should not need to
-     run it directly.
-
-     It connects to a kkxxdd on the host _h_o_s_t and then will relay the traffic
-     from the remote X clients to the local server.  When started, it prints
-     the display and Xauthority-file to be used on host _h_o_s_t and then goes to
-     the background, waiting for connections from the remote kkxxdd..
-
-SSEEEE AALLSSOO
-     rxtelnet(1),  rxterm(1),  kxd(8)
-
- KTH-KRB                      September 27, 1996                             1
diff --git a/crypto/heimdal/appl/kx/kxd.cat8 b/crypto/heimdal/appl/kx/kxd.cat8
deleted file mode 100644
index e033cee412ec..000000000000
--- a/crypto/heimdal/appl/kx/kxd.cat8
+++ /dev/null
@@ -1,37 +0,0 @@
-
-KXD(8)                   UNIX System Manager's Manual                   KXD(8)
-
-NNAAMMEE
-     kkxxdd - securely forward X conections
-
-SSYYNNOOPPSSIISS
-     _k_x_d [--tt] [--ii] [--pp _p_o_r_t]
-
-DDEESSCCRRIIPPTTIIOONN
-     This is the daemon for kkxx.
-
-     Options supported by kkxxdd:
-
-     --tt      TCP.  Normally kkxxdd will only listen for X connections on a UNIX
-             socket, but some machines (for example, Cray) have X libraries
-             that are not able to use UNIX sockets and thus you need to use
-             TCP to talk to the pseudo-xserver created by kkxxdd.. This option de-
-             creases the security significantly and should only be used when
-             it is necessary and you have considered the consequences of doing
-             so.
-
-     --ii      Interactive.  Do not expect to be started by iinneettdd,, but allocate
-             and listen to the socket yourself.  Handy for testing and debug-
-             ging.
-
-     --pp      Port.  Listen on the port _p_o_r_t. Only usable with --ii.
-
-EEXXAAMMPPLLEESS
-     Put the following in _/_e_t_c_/_i_n_e_t_d_._c_o_n_f:
-
-     kx      stream  tcp     nowait  root    /usr/athena/libexec/kxd kxd
-
-SSEEEE AALLSSOO
-     kx(1),  rxtelnet(1),  rxterm(1)
-
- KTH-KRB                      September 27, 1996                             1
diff --git a/crypto/heimdal/appl/kx/rxtelnet.cat1 b/crypto/heimdal/appl/kx/rxtelnet.cat1
deleted file mode 100644
index ad3f4209cb7b..000000000000
--- a/crypto/heimdal/appl/kx/rxtelnet.cat1
+++ /dev/null
@@ -1,43 +0,0 @@
-
-RXTELNET(1)                  UNIX Reference Manual                 RXTELNET(1)
-
-NNAAMMEE
-     rrxxtteellnneett - start a telnet and forward X-connections.
-
-SSYYNNOOPPSSIISS
-     rrxxtteellnneett [--ll _u_s_e_r_n_a_m_e] [--kk] [--tt _t_e_l_n_e_t___a_r_g_s] [--xx _x_t_e_r_m___a_r_g_s] [--ww
-              _t_e_r_m___e_m_u_l_a_t_o_r] [--nn] _h_o_s_t [_p_o_r_t]
-
-DDEESSCCRRIIPPTTIIOONN
-     The rrxxtteellnneett program starts a xxtteerrmm window with a telnet to host _h_o_s_t.
-     From this window you will also be able to run X clients that will be able
-     to connect securily to your X server. If _p_o_r_t is given, that port will be
-     used instead of the default.
-
-     The supported options are:
-
-     --ll      Log in on the remote host as user _u_s_e_r_n_a_m_e
-
-     --kk      Disables keep-alives
-
-     --tt      Send _t_e_l_n_e_t___a_r_g_s as arguments to tteellnneett
-
-     --xx      Send _x_t_e_r_m___a_r_g_s as arguments to xxtteerrmm
-
-     --ww      Use _t_e_r_m___e_m_u_l_a_t_o_r instead of xterm.
-
-     --nn      Do not start any terminal emulator.
-
-EEXXAAMMPPLLEE
-     To login from host _f_o_o (where your display is) to host _b_a_r, you might do
-     the following.
-
-     1.   On foo: rrxxtteellnneett _b_a_r
-
-     2.   You will get a new window with a tteellnneett to _b_a_r. In this window you
-          will be able to start X clients.
-
-SSEEEE AALLSSOO
-     rxterm(1),  tenletxr(1),  kx(1),  kxd(8),  telnet(1)
-
- KTH_KRB                      September 27, 1996                             1
diff --git a/crypto/heimdal/appl/kx/rxterm.cat1 b/crypto/heimdal/appl/kx/rxterm.cat1
deleted file mode 100644
index 56eec66236bb..000000000000
--- a/crypto/heimdal/appl/kx/rxterm.cat1
+++ /dev/null
@@ -1,41 +0,0 @@
-
-RXTERM(1)                    UNIX Reference Manual                   RXTERM(1)
-
-NNAAMMEE
-     rrxxtteerrmm - start a secure remote xterm
-
-SSYYNNOOPPSSIISS
-     rrxxtteerrmm [--ll _u_s_e_r_n_a_m_e] [--kk] [--rr _r_s_h___a_r_g_s] [--xx _x_t_e_r_m___a_r_g_s] [--ww
-            _t_e_r_m___e_m_u_l_a_t_o_r] _h_o_s_t [_p_o_r_t]
-
-DDEESSCCRRIIPPTTIIOONN
-     The rrxxtteerrmm program starts a xxtteerrmm window on host _h_o_s_t. From this window
-     you will also be able to run X clients that will be able to connect se-
-     curily to your X server. If _p_o_r_t is given, that port will be used instead
-     of the default.
-
-     The supported options are:
-
-     --ll      Log in on the remote host as user _u_s_e_r_n_a_m_e
-
-     --kk      Disable keep-alives
-
-     --rr      Send _r_s_h___a_r_g_s as arguments to rrsshh
-
-     --xx      Send _x_t_e_r_m___a_r_g_s as arguments to xxtteerrmm
-
-     --ww      Use _t_e_r_m___e_m_u_l_a_t_o_r instead of xterm.
-
-EEXXAAMMPPLLEE
-     To login from host _f_o_o (where your display is) to host _b_a_r, you might do
-     the following.
-
-     1.   On foo: rrxxtteerrmm _b_a_r
-
-     2.   You will get a new window running an xxtteerrmm on host _b_a_r. In this win-
-          dow you will be able to start X clients.
-
-SSEEEE AALLSSOO
-     rxtelnet(1),  tenletxr(1),  kx(1),  kxd(8),  rsh(1)
-
- KTH_KRB                      September 27, 1996                             1
diff --git a/crypto/heimdal/appl/kx/tenletxr.cat1 b/crypto/heimdal/appl/kx/tenletxr.cat1
deleted file mode 100644
index c1714e7a092b..000000000000
--- a/crypto/heimdal/appl/kx/tenletxr.cat1
+++ /dev/null
@@ -1,37 +0,0 @@
-
-TENLETXR(1)                  UNIX Reference Manual                 TENLETXR(1)
-
-NNAAMMEE
-     tteennlleettxxrr - forward X-connections backwards.
-
-SSYYNNOOPPSSIISS
-     tteennlleettxxrr [--ll _u_s_e_r_n_a_m_e] [--kk] _h_o_s_t [_p_o_r_t]
-
-DDEESSCCRRIIPPTTIIOONN
-     The tteennlleettxxrr program enables forwarding of X-connections from this ma-
-     chine to host _h_o_s_t. If _p_o_r_t is given, that port will be used instead of
-     the default.
-
-     The supported options are:
-
-     --ll      Log in on the remote host as user _u_s_e_r_n_a_m_e
-
-     --kk      Disables keep-alives.
-
-EEXXAAMMPPLLEE
-     To login from host _f_o_o to host _b_a_r (where your display is), you might do
-     the following.
-
-     1.   On foo: tteennlleettxxrr _b_a_r
-
-     2.   You will get a new shell where you will be able to start X clients
-          that will show their windows on _b_a_r.
-
-BBUUGGSS
-     It currently checks if you have permission to run it by checking if you
-     own _/_d_e_v_/_c_o_n_s_o_l_e on the remote host.
-
-SSEEEE AALLSSOO
-     rxtelnet(1),  rxterm(1),  kx(1),  kxd(8),  telnet(1)
-
- KTH_KRB                        March 31, 1997                               1
diff --git a/crypto/heimdal/appl/otp/otp.cat1 b/crypto/heimdal/appl/otp/otp.cat1
deleted file mode 100644
index 588bcc2f6c81..000000000000
--- a/crypto/heimdal/appl/otp/otp.cat1
+++ /dev/null
@@ -1,43 +0,0 @@
-
-OTP(1)                       UNIX Reference Manual                      OTP(1)
-
-NNAAMMEE
-     oottpp - manages one-time passwords
-
-SSYYNNOOPPSSIISS
-     oottpp [--ddhhlloorr] [--ff _a_l_g_o_r_i_t_h_m] [--uu _u_s_e_r] _s_e_q_u_e_n_c_e_-_n_u_m_b_e_r _s_e_e_d
-
-DDEESSCCRRIIPPTTIIOONN
-     The oottpp program initializes and updates your current series of one-time
-     passwords (OTPs).
-
-     Use this to set a new series of one-time passwords.  Only perform this on
-     the console or over an encrypted link as you will have to supply your
-     pass-phrase.  The other two parameters are _s_e_q_u_e_n_c_e_-_n_u_m_b_e_r and _s_e_e_d.
-
-     Options are:
-
-     --dd      To delete a one-time password.
-
-     --ff      Choose a different _a_l_g_o_r_i_t_h_m from the default md5.  Pick any of:
-             md4, md5, and sha.
-
-     --hh      For getting a help message.
-
-     --ll      List the current table of one-time passwords.
-
-     --oo      To open (unlock) the otp-entry for a user.
-
-     --rr      To renew a one-time password series.  This operation can be per-
-             formed over an potentially eavesdropped link because you do not
-             supply the pass-phrase.  First you need to supply the current
-             one-time password and then the new one corresponding to the sup-
-             plied _s_e_q_u_e_n_c_e_-_n_u_m_b_e_r and _s_e_e_d.
-
-     --uu      To choose a different _u_s_e_r to set one-time passwords for.  This
-             only works when running oottpp as root.
-
-SSEEEE AALLSSOO
-     otpprint(1)
-
- KTH-KRB                       November 17, 1996                             1
diff --git a/crypto/heimdal/appl/otp/otpprint.cat1 b/crypto/heimdal/appl/otp/otpprint.cat1
deleted file mode 100644
index 1c4d2444fafd..000000000000
--- a/crypto/heimdal/appl/otp/otpprint.cat1
+++ /dev/null
@@ -1,36 +0,0 @@
-
-OTP(1)                       UNIX Reference Manual                      OTP(1)
-
-NNAAMMEE
-     oottpppprriinntt - print lists of one-time passwords
-
-SSYYNNOOPPSSIISS
-     oottpp [--nn _c_o_u_n_t] [--ee] [--hh] [--ff _a_l_g_o_r_i_t_h_m] _s_e_q_u_e_n_c_e_-_n_u_m_b_e_r _s_e_e_d
-
-DDEESSCCRRIIPPTTIIOONN
-     The oottpppprriinntt program prints lists of OTPs.
-
-     Use this to print out a series of one-time passwords.  You will have to
-     supply the _s_e_q_u_e_n_c_e _n_u_m_b_e_r and the _s_e_e_d as arguments and then the program
-     will prompt you for your pass-phrase.
-
-     There are several different print formats.  The default is to print each
-     password with six short english words.
-
-     Options are:
-
-     --ee      Print the passwords in ``extended'' format.  In this format a
-             prefix that says ``hex:'' or ``word:'' is included.
-
-     --ff      To choose a different _a_l_g_o_r_i_t_h_m from the default md5.  Pick any
-             of: md4, md5, and sha.
-
-     --hh      Print the passwords in hex.
-
-     --nn      Print _c_o_u_n_t one-time passwords, starting at _s_e_q_u_e_n_c_e_-_n_u_m_b_e_r and
-             going backwards. The default is 10.
-
-SSEEEE AALLSSOO
-     otp(1)
-
- KTH-KRB                       November 17, 1996                             1
diff --git a/crypto/heimdal/appl/push/pfrom.cat1 b/crypto/heimdal/appl/push/pfrom.cat1
deleted file mode 100644
index 8abf68aff9c4..000000000000
--- a/crypto/heimdal/appl/push/pfrom.cat1
+++ /dev/null
@@ -1,17 +0,0 @@
-
-PFROM(1)                     UNIX Reference Manual                    PFROM(1)
-
-NNAAMMEE
-     ppffrroomm - fetch a list of the current mail via POP
-
-SSYYNNOOPPSSIISS
-     ppffrroomm [--44 | ----kkrrbb44] [--55 | ----kkrrbb55] [--vv | ----vveerrbboossee] [--cc | ----ccoouunntt]
-     [----hheeaaddeerr] [--pp _p_o_r_t_-_s_p_e_c | ----ppoorrtt==_p_o_r_t_-_s_p_e_c]
-
-DDEESSCCRRIIPPTTIIOONN
-     ppffrroomm is a script that does push --from.
-
-SSEEEE AALLSSOO
-     push(8)
-
- HEIMDAL                         Mars 4, 2000                                1
diff --git a/crypto/heimdal/appl/push/push.cat8 b/crypto/heimdal/appl/push/push.cat8
deleted file mode 100644
index dff390efe7a1..000000000000
--- a/crypto/heimdal/appl/push/push.cat8
+++ /dev/null
@@ -1,77 +0,0 @@
-
-PUSH(8)                  UNIX System Manager's Manual                  PUSH(8)
-
-NNAAMMEE
-     ppuusshh - fetch mail via POP
-
-SSYYNNOOPPSSIISS
-     ppuusshh [--44 | ----kkrrbb44] [--55 | ----kkrrbb55] [--vv | ----vveerrbboossee] [--ff | ----ffoorrkk] [--ll |
-     ----lleeaavvee] [----ffrroomm] [--cc | ----ccoouunntt] [----hheeaaddeerrss=_h_e_a_d_e_r_s] [--pp _p_o_r_t_-_s_p_e_c |
-     ----ppoorrtt=_p_o_r_t_-_s_p_e_c] _p_o_-_b_o_x _f_i_l_e_n_a_m_e
-
-DDEESSCCRRIIPPTTIIOONN
-     ppuusshh retrieves mail from the post office box _p_o_-_b_o_x, and stores the mail
-     in mbox format in _f_i_l_e_n_a_m_e. The _p_o_-_b_o_x can have any of the following for-
-     mats:
-           `hostname:username'
-           `po:hostname:username'
-           `username@hostname'
-           `po:username@hostname'
-           `hostname'
-           `po:username'
-
-     If no username is specified, ppuusshh assumes that it's the same as on the
-     local machine; _h_o_s_t_n_a_m_e defaults to the value of the MAILHOST environment
-     variable.
-
-     Supported options:
-
-     --44, ----kkrrbb44
-             use Kerberos 4 (if compiled with support for Kerberos 4)
-
-     --55, ----kkrrbb55
-             use Kerberos 5 (if compiled with support for Kerberos 5)
-
-     --ff, ----ffoorrkk
-             fork before starting to delete messages
-
-     --ll, ----lleeaavvee
-             don't delete fetched mail
-
-     ----ffrroomm  behave like from.
-
-     --cc, ----ccoouunntt
-             first print how many messages and bytes there are.
-
-     ----hheeaaddeerrss=_h_e_a_d_e_r_s
-             a list of comma-separated headers that should get printed.
-
-     --pp _p_o_r_t_-_s_p_e_c, ----ppoorrtt=_p_o_r_t_-_s_p_e_c
-             use this port instead of the default `kpop' or `1109'.
-
-     The default is to first try Kerberos 5 authentication and then, if that
-     fails, Kerberos 4.
-
-EENNVVIIRROONNMMEENNTT
-     MAILHOST
-             points to the post office, if no other hostname is specified.
-
-EEXXAAMMPPLLEESS
-           $ push cornfield:roosta ~/.emacs-mail-crash-box
-
-     tries to fetch mail for the user _r_o_o_s_t_a from the post office at
-     ``cornfield'', and stores the mail in _~_/_._e_m_a_c_s_-_m_a_i_l_-_c_r_a_s_h_-_b_o_x (you are
-     using Gnus, aren't you?)
-
-           $ push --from -5 havregryn
-
-     tries to fetch FFrroomm:: lines for current user at post office ``havregryn''
-     using Kerberos 5.
-
-SSEEEE AALLSSOO
-     movemail(8),  popper(8),  from(1),  pfrom(1)
-
-HHIISSTTOORRYY
-     ppuusshh was written while waiting for mmoovveemmaaiill to finish getting the mail.
-
- HEIMDAL                         May 31, 1998                                2
diff --git a/crypto/heimdal/appl/telnet/telnet/telnet.cat1 b/crypto/heimdal/appl/telnet/telnet/telnet.cat1
deleted file mode 100644
index 708994e60a47..000000000000
--- a/crypto/heimdal/appl/telnet/telnet/telnet.cat1
+++ /dev/null
@@ -1,718 +0,0 @@
-
-TELNET(1)                    UNIX Reference Manual                   TELNET(1)
-
-NNAAMMEE
-     tteellnneett - user interface to the TELNET protocol
-
-SSYYNNOOPPSSIISS
-     tteellnneett [--7788EEFFKKLLaaccddffrrxx] [--SS _t_o_s] [--XX _a_u_t_h_t_y_p_e] [--ee _e_s_c_a_p_e_c_h_a_r] [--kk _r_e_a_l_m]
-            [--ll _u_s_e_r] [--nn _t_r_a_c_e_f_i_l_e] [_h_o_s_t [port]]
-
-DDEESSCCRRIIPPTTIIOONN
-     The tteellnneett command is used to communicate with another host using the
-     TELNET protocol.  If tteellnneett is invoked without the _h_o_s_t argument, it en-
-     ters command mode, indicated by its prompt (tteellnneett>>). In this mode, it
-     accepts and executes the commands listed below.  If it is invoked with
-     arguments, it performs an ooppeenn command with those arguments.
-
-     Options:
-
-     --88      Specifies an 8-bit data path.  This causes an attempt to negoti-
-             ate the TELNET BINARY option on both input and output.
-
-     --77      Do not try to negotiate TELNET BINARY option.
-
-     --EE      Stops any character from being recognized as an escape character.
-
-     --FF      If Kerberos V5 authentication is being used, the --FF option allows
-             the local credentials to be forwarded to the remote system, in-
-             cluding any credentials that have already been forwarded into the
-             local environment.
-
-     --KK      Specifies no automatic login to the remote system.
-
-     --LL      Specifies an 8-bit data path on output.  This causes the BINARY
-             option to be negotiated on output.
-
-     --SS _t_o_s  Sets the IP type-of-service (TOS) option for the telnet connec-
-             tion to the value _t_o_s, which can be a numeric TOS value or, on
-             systems that support it, a symbolic TOS name found in the
-             /etc/iptos file.
-
-     --XX _a_t_y_p_e
-             Disables the _a_t_y_p_e type of authentication.
-
-     --aa      Attempt automatic login.  Currently, this sends the user name via
-             the USER variable of the ENVIRON option if supported by the re-
-             mote system.  The name used is that of the current user as re-
-             turned by getlogin(2) if it agrees with the current user ID, oth-
-             erwise it is the name associated with the user ID.
-
-     --cc      Disables the reading of the user's _._t_e_l_n_e_t_r_c file.  (See the
-             ttooggggllee sskkiipprrcc command on this man page.)
-
-     --dd      Sets the initial value of the ddeebbuugg toggle to TRUE
-
-     --ee _e_s_c_a_p_e _c_h_a_r
-             Sets the initial tteellnneett tteellnneett escape character to _e_s_c_a_p_e _c_h_a_r.
-             If _e_s_c_a_p_e _c_h_a_r is omitted, then there will be no escape charac-
-             ter.
-
-     --ff      If Kerberos V5 authentication is being used, the --ff option allows
-             the local credentials to be forwarded to the remote system.
-
-     --kk _r_e_a_l_m
-             If Kerberos authentication is being used, the --kk option requests
-             that telnet obtain tickets for the remote host in realm realm in-
-             stead of the remote host's realm, as determined by
-             krb_realmofhost(3).
-
-     --ll _u_s_e_r
-             When connecting to the remote system, if the remote system under-
-             stands the ENVIRON option, then _u_s_e_r will be sent to the remote
-             system as the value for the variable USER.  This option implies
-             the --aa option.  This option may also be used with the ooppeenn com-
-             mand.
-
-     --nn _t_r_a_c_e_f_i_l_e
-             Opens _t_r_a_c_e_f_i_l_e for recording trace information.  See the sseett
-             ttrraacceeffiillee command below.
-
-     --rr      Specifies a user interface similar to rlogin(1).  In this mode,
-             the escape character is set to the tilde (~) character, unless
-             modified by the -e option.
-
-     --xx      Turns on encryption of the data stream if possible. This is cur-
-             rently the default and when it fails a warning is issued.
-
-     _h_o_s_t    Indicates the official name, an alias, or the Internet address of
-             a remote host.
-
-     _p_o_r_t    Indicates a port number (address of an application).  If a number
-             is not specified, the default tteellnneett port is used.
-
-     When in rlogin mode, a line of the form ~.  disconnects from the remote
-     host; ~ is the telnet escape character.  Similarly, the line ~^Z suspends
-     the telnet session.  The line ~^] escapes to the normal telnet escape
-     prompt.
-
-     Once a connection has been opened, tteellnneett will attempt to enable the
-     TELNET LINEMODE option.  If this fails, then tteellnneett will revert to one of
-     two input modes: either ``character at a time'' or ``old line by line''
-     depending on what the remote system supports.
-
-     When LINEMODE is enabled, character processing is done on the local sys-
-     tem, under the control of the remote system.  When input editing or char-
-     acter echoing is to be disabled, the remote system will relay that infor-
-     mation.  The remote system will also relay changes to any special charac-
-     ters that happen on the remote system, so that they can take effect on
-     the local system.
-
-     In ``character at a time'' mode, most text typed is immediately sent to
-     the remote host for processing.
-
-     In ``old line by line'' mode, all text is echoed locally, and (normally)
-     only completed lines are sent to the remote host.  The ``local echo char-
-     acter'' (initially ``^E'') may be used to turn off and on the local echo
-     (this would mostly be used to enter passwords without the password being
-     echoed).
-
-     If the LINEMODE option is enabled, or if the llooccaallcchhaarrss toggle is TRUE
-     (the default for ``old line by line``; see below), the user's qquuiitt, iinnttrr,
-     and fflluusshh characters are trapped locally, and sent as TELNET protocol se-
-     quences to the remote side.  If LINEMODE has ever been enabled, then the
-     user's ssuusspp and eeooff are also sent as TELNET protocol sequences, and qquuiitt
-     is sent as a TELNET ABORT instead of BREAK There are options (see ttooggggllee
-     aauuttoofflluusshh and ttooggggllee aauuttoossyynncchh below) which cause this action to flush
-     subsequent output to the terminal (until the remote host acknowledges the
-     TELNET sequence) and flush previous terminal input (in the case of qquuiitt
-     and iinnttrr).
-
-
-     While connected to a remote host, tteellnneett command mode may be entered by
-     typing the tteellnneett ``escape character'' (initially ``^]'').  When in com-
-     mand mode, the normal terminal editing conventions are available.
-
-     The following tteellnneett commands are available.  Only enough of each command
-     to uniquely identify it need be typed (this is also true for arguments to
-     the mmooddee, sseett, ttooggggllee, uunnsseett, ssllcc, eennvviirroonn, and ddiissppllaayy commands).
-
-     aauutthh _a_r_g_u_m_e_n_t _._._.
-                The auth command manipulates the information sent through the
-                TELNET AUTHENTICATE option.  Valid arguments for the auth com-
-                mand are as follows:
-
-                ddiissaabbllee _t_y_p_e  Disables the specified type of authentication.
-                              To obtain a list of available types, use the
-                              aauutthh ddiissaabbllee ?? command.
-
-                eennaabbllee _t_y_p_e   Enables the specified type of authentication.
-                              To obtain a list of available types, use the
-                              aauutthh eennaabbllee ?? command.
-
-                ssttaattuuss        Lists the current status of the various types of
-                              authentication.
-
-     cclloossee      Close a TELNET session and return to command mode.
-
-     ddiissppllaayy _a_r_g_u_m_e_n_t _._._.
-                Displays all, or some, of the sseett and ttooggggllee values (see be-
-                low).
-
-     eennccrryypptt _a_r_g_u_m_e_n_t _._._.
-                The encrypt command manipulates the information sent through
-                the TELNET ENCRYPT option.
-
-                Note:  Because of export controls, the TELNET ENCRYPT option
-                is not supported outside of the United States and Canada.
-
-                Valid arguments for the encrypt command are as follows:
-
-                ddiissaabbllee _t_y_p_e [iinnppuutt | oouuttppuutt]
-                              Disables the specified type of encryption.  If
-                              you omit the input and output, both input and
-                              output are disabled.  To obtain a list of avail-
-                              able types, use the eennccrryypptt ddiissaabbllee ?? command.
-
-                eennaabbllee _t_y_p_e [iinnppuutt | oouuttppuutt]
-                              Enables the specified type of encryption.  If
-                              you omit input and output, both input and output
-                              are enabled.  To obtain a list of available
-                              types, use the eennccrryypptt eennaabbllee ?? command.
-
-                iinnppuutt         This is the same as the eennccrryypptt ssttaarrtt iinnppuutt com-
-                              mand.
-
-                --iinnppuutt        This is the same as the eennccrryypptt ssttoopp iinnppuutt com-
-                              mand.
-
-                oouuttppuutt        This is the same as the eennccrryypptt ssttaarrtt oouuttppuutt
-                              command.
-
-                --oouuttppuutt       This is the same as the eennccrryypptt ssttoopp oouuttppuutt com-
-                              mand.
-
-                ssttaarrtt [iinnppuutt | oouuttppuutt]
-                              Attempts to start encryption.  If you omit iinnppuutt
-                              and oouuttppuutt, both input and output are enabled.
-                              To obtain a list of available types, use the
-                              eennccrryypptt eennaabbllee ?? command.
-
-                ssttaattuuss        Lists the current status of encryption.
-
-                ssttoopp [iinnppuutt | oouuttppuutt]
-                              Stops encryption.  If you omit input and output,
-                              encryption is on both input and output.
-
-                ttyyppee _t_y_p_e     Sets the default type of encryption to be used
-                              with later eennccrryypptt ssttaarrtt or eennccrryypptt ssttoopp com-
-                              mands.
-
-     eennvviirroonn _a_r_g_u_m_e_n_t_s _._._.
-                The eennvviirroonn command is used to manipulate the the variables
-                that my be sent through the TELNET ENVIRON option.  The ini-
-                tial set of variables is taken from the users environment,
-                with only the DISPLAY and PRINTER variables being exported by
-                default.  The USER variable is also exported if the --aa or --ll
-                options are used.
-
-                Valid arguments for the eennvviirroonn command are:
-
-                ddeeffiinnee _v_a_r_i_a_b_l_e _v_a_l_u_e
-                            Define the variable _v_a_r_i_a_b_l_e to have a value of
-                            _v_a_l_u_e. Any variables defined by this command are
-                            automatically exported.  The _v_a_l_u_e may be enclosed
-                            in single or double quotes so that tabs and spaces
-                            may be included.
-
-                uunnddeeffiinnee _v_a_r_i_a_b_l_e
-                            Remove _v_a_r_i_a_b_l_e from the list of environment vari-
-                            ables.
-
-                eexxppoorrtt _v_a_r_i_a_b_l_e
-                            Mark the variable _v_a_r_i_a_b_l_e to be exported to the
-                            remote side.
-
-                uunneexxppoorrtt _v_a_r_i_a_b_l_e
-                            Mark the variable _v_a_r_i_a_b_l_e to not be exported un-
-                            less explicitly asked for by the remote side.
-
-                lliisstt        List the current set of environment variables.
-                            Those marked with a ** will be sent automatically,
-                            other variables will only be sent if explicitly
-                            requested.
-
-                ??           Prints out help information for the eennvviirroonn com-
-                            mand.
-
-     llooggoouutt     Sends the TELNET LOGOUT option to the remote side.  This com-
-                mand is similar to a cclloossee command; however, if the remote
-                side does not support the LOGOUT option, nothing happens.  If,
-                however, the remote side does support the LOGOUT option, this
-                command should cause the remote side to close the TELNET con-
-                nection.  If the remote side also supports the concept of sus-
-                pending a user's session for later reattachment, the logout
-                argument indicates that you should terminate the session imme-
-                diately.
-
-     mmooddee _t_y_p_e  _T_y_p_e is one of several options, depending on the state of the
-                TELNET session.  The remote host is asked for permission to go
-                into the requested mode.  If the remote host is capable of en-
-                tering that mode, the requested mode will be entered.
-
-                cchhaarraacctteerr     Disable the TELNET LINEMODE option, or, if the
-                              remote side does not understand the LINEMODE op-
-                              tion, then enter ``character at a time`` mode.
-
-                lliinnee          Enable the TELNET LINEMODE option, or, if the
-                              remote side does not understand the LINEMODE op-
-                              tion, then attempt to enter ``old-line-by-line``
-                              mode.
-
-                iissiigg (--iissiigg)  Attempt to enable (disable) the TRAPSIG mode of
-                              the LINEMODE option.  This requires that the
-                              LINEMODE option be enabled.
-
-                eeddiitt (--eeddiitt)  Attempt to enable (disable) the EDIT mode of the
-                              LINEMODE option.  This requires that the
-                              LINEMODE option be enabled.
-
-                ssooffttttaabbss (--ssooffttttaabbss)
-                              Attempt to enable (disable) the SOFT_TAB mode of
-                              the LINEMODE option.  This requires that the
-                              LINEMODE option be enabled.
-
-                lliitteecchhoo (--lliitteecchhoo)
-                              Attempt to enable (disable) the LIT_ECHO mode of
-                              the LINEMODE option.  This requires that the
-                              LINEMODE option be enabled.
-
-                ??             Prints out help information for the mmooddee com-
-                              mand.
-
-     ooppeenn _h_o_s_t [--ll _u_s_e_r] [[--]_p_o_r_t]
-                Open a connection to the named host.  If no port number is
-                specified, tteellnneett will attempt to contact a TELNET server at
-                the default port.  The host specification may be either a host
-                name (see hosts(5))  or an Internet address specified in the
-                ``dot notation'' (see inet(3)).  The [--ll] option may be used
-                to specify the user name to be passed to the remote system via
-                the ENVIRON option.  When connecting to a non-standard port,
-                tteellnneett omits any automatic initiation of TELNET options.  When
-                the port number is preceded by a minus sign, the initial op-
-                tion negotiation is done.  After establishing a connection,
-                the file _._t_e_l_n_e_t_r_c in the users home directory is opened.
-                Lines beginning with a # are comment lines.  Blank lines are
-                ignored.  Lines that begin without white space are the start
-                of a machine entry.  The first thing on the line is the name
-                of the machine that is being connected to.  The rest of the
-                line, and successive lines that begin with white space are as-
-                sumed to be tteellnneett commands and are processed as if they had
-                been typed in manually to the tteellnneett command prompt.
-
-     qquuiitt       Close any open TELNET session and exit tteellnneett. An end of file
-                (in command mode) will also close a session and exit.
-
-     sseenndd _a_r_g_u_m_e_n_t_s
-                Sends one or more special character sequences to the remote
-                host.  The following are the arguments which may be specified
-                (more than one argument may be specified at a time):
-
-                aabboorrtt   Sends the TELNET ABORT (Abort processes) sequence.
-
-                aaoo      Sends the TELNET AO (Abort Output) sequence, which
-                        should cause the remote system to flush all output
-                        _f_r_o_m the remote system _t_o the user's terminal.
-
-                aayytt     Sends the TELNET AYT (Are You There) sequence, to
-                        which the remote system may or may not choose to re-
-
-                        spond.
-
-                bbrrkk     Sends the TELNET BRK (Break) sequence, which may have
-                        significance to the remote system.
-
-                eecc      Sends the TELNET EC (Erase Character) sequence, which
-                        should cause the remote system to erase the last char-
-                        acter entered.
-
-                eell      Sends the TELNET EL (Erase Line) sequence, which
-                        should cause the remote system to erase the line cur-
-                        rently being entered.
-
-                eeooff     Sends the TELNET EOF (End Of File) sequence.
-
-                eeoorr     Sends the TELNET EOR (End of Record) sequence.
-
-                eessccaappee  Sends the current tteellnneett escape character (initially
-                        ``^'').
-
-                ggaa      Sends the TELNET GA (Go Ahead) sequence, which likely
-                        has no significance to the remote system.
-
-                ggeettssttaattuuss
-                        If the remote side supports the TELNET STATUS command,
-                        ggeettssttaattuuss will send the subnegotiation to request that
-                        the server send its current option status.
-
-                iipp      Sends the TELNET IP (Interrupt Process) sequence,
-                        which should cause the remote system to abort the cur-
-                        rently running process.
-
-                nnoopp     Sends the TELNET NOP (No OPeration) sequence.
-
-                ssuusspp    Sends the TELNET SUSP (SUSPend process) sequence.
-
-                ssyynncchh   Sends the TELNET SYNCH sequence.  This sequence causes
-                        the remote system to discard all previously typed (but
-                        not yet read) input.  This sequence is sent as TCP ur-
-                        gent data (and may not work if the remote system is a
-                        4.2BSD system -- if it doesn't work, a lower case
-                        ``r'' may be echoed on the terminal).
-
-                ddoo _c_m_d
-
-                ddoonntt _c_m_d
-
-                wwiillll _c_m_d
-
-                wwoonntt _c_m_d
-                        Sends the TELNET DO _c_m_d sequence.  _C_m_d can be either a
-                        decimal number between 0 and 255, or a symbolic name
-                        for a specific TELNET command.  _C_m_d can also be either
-                        hheellpp or ?? to print out help information, including a
-                        list of known symbolic names.
-
-                ??       Prints out help information for the sseenndd command.
-
-     sseett _a_r_g_u_m_e_n_t _v_a_l_u_e
-
-     uunnsseett _a_r_g_u_m_e_n_t _v_a_l_u_e
-                The sseett command will set any one of a number of tteellnneett vari-
-                ables to a specific value or to TRUE. The special value ooffff
-                turns off the function associated with the variable, this is
-                equivalent to using the uunnsseett command.  The uunnsseett command will
-                disable or set to FALSE any of the specified functions.  The
-                values of variables may be interrogated with the ddiissppllaayy com-
-                mand.  The variables which may be set or unset, but not tog-
-                gled, are listed here.  In addition, any of the variables for
-                the ttooggggllee command may be explicitly set or unset using the
-                sseett and uunnsseett commands.
-
-                aayytt     If TELNET is in localchars mode, or LINEMODE is en-
-                        abled, and the status character is typed, a TELNET AYT
-                        sequence (see sseenndd aayytt preceding) is sent to the re-
-                        mote host.  The initial value for the "Are You There"
-                        character is the terminal's status character.
-
-                eecchhoo    This is the value (initially ``^E'') which, when in
-                        ``line by line'' mode, toggles between doing local
-                        echoing of entered characters (for normal processing),
-                        and suppressing echoing of entered characters (for en-
-                        tering, say, a password).
-
-                eeooff     If tteellnneett is operating in LINEMODE or ``old line by
-                        line'' mode, entering this character as the first
-                        character on a line will cause this character to be
-                        sent to the remote system.  The initial value of the
-                        eof character is taken to be the terminal's eeooff char-
-                        acter.
-
-                eerraassee   If tteellnneett is in llooccaallcchhaarrss mode (see ttooggggllee llooccaallcchhaarrss
-                        below), aanndd if tteellnneett is operating in ``character at a
-                        time'' mode, then when this character is typed, a
-                        TELNET EC sequence (see sseenndd eecc above) is sent to the
-                        remote system.  The initial value for the erase char-
-                        acter is taken to be the terminal's eerraassee character.
-
-                eessccaappee  This is the tteellnneett escape character (initially ``^['')
-                        which causes entry into tteellnneett command mode (when con-
-                        nected to a remote system).
-
-                fflluusshhoouuttppuutt
-                        If tteellnneett is in llooccaallcchhaarrss mode (see ttooggggllee llooccaallcchhaarrss
-                        below) and the fflluusshhoouuttppuutt character is typed, a
-                        TELNET AO sequence (see sseenndd aaoo above) is sent to the
-                        remote host.  The initial value for the flush charac-
-                        ter is taken to be the terminal's fflluusshh character.
-
-                ffoorrww11
-
-                ffoorrww22   If TELNET is operating in LINEMODE, these are the
-                        characters that, when typed, cause partial lines to be
-                        forwarded to the remote system.  The initial value for
-                        the forwarding characters are taken from the termi-
-                        nal's eol and eol2 characters.
-
-                iinntteerrrruupptt
-                        If tteellnneett is in llooccaallcchhaarrss mode (see ttooggggllee llooccaallcchhaarrss
-                        below) and the iinntteerrrruupptt character is typed, a TELNET
-                        IP sequence (see sseenndd iipp above) is sent to the remote
-                        host.  The initial value for the interrupt character
-                        is taken to be the terminal's iinnttrr character.
-
-                kkiillll    If tteellnneett is in llooccaallcchhaarrss mode (see ttooggggllee llooccaallcchhaarrss
-                        below), aanndd if tteellnneett is operating in ``character at a
-                        time'' mode, then when this character is typed, a
-                        TELNET EL sequence (see sseenndd eell above) is sent to the
-                        remote system.  The initial value for the kill charac-
-                        ter is taken to be the terminal's kkiillll character.
-
-                llnneexxtt   If tteellnneett is operating in LINEMODE or ``old line by
-                        line`` mode, then this character is taken to be the
-                        terminal's llnneexxtt character.  The initial value for the
-                        lnext character is taken to be the terminal's llnneexxtt
-                        character.
-
-                qquuiitt    If tteellnneett is in llooccaallcchhaarrss mode (see ttooggggllee llooccaallcchhaarrss
-                        below) and the qquuiitt character is typed, a TELNET BRK
-                        sequence (see sseenndd bbrrkk above) is sent to the remote
-                        host.  The initial value for the quit character is
-                        taken to be the terminal's qquuiitt character.
-
-                rreepprriinntt
-                        If tteellnneett is operating in LINEMODE or ``old line by
-                        line`` mode, then this character is taken to be the
-                        terminal's rreepprriinntt character.  The initial value for
-                        the reprint character is taken to be the terminal's
-                        rreepprriinntt character.
-
-                rrllooggiinn  This is the rlogin escape character.  If set, the nor-
-                        mal TELNET escape character is ignored unless it is
-                        preceded by this character at the beginning of a line.
-                        This character, at the beginning of a line followed by
-                        a "."  closes the connection; when followed by a ^Z it
-                        suspends the telnet command.  The initial state is to
-                        disable the rlogin escape character.
-
-                ssttaarrtt   If the TELNET TOGGLE-FLOW-CONTROL option has been en-
-                        abled, then this character is taken to be the termi-
-                        nal's ssttaarrtt character.  The initial value for the kill
-                        character is taken to be the terminal's ssttaarrtt charac-
-                        ter.
-
-                ssttoopp    If the TELNET TOGGLE-FLOW-CONTROL option has been en-
-                        abled, then this character is taken to be the termi-
-                        nal's ssttoopp character.  The initial value for the kill
-                        character is taken to be the terminal's ssttoopp charac-
-                        ter.
-
-                ssuusspp    If tteellnneett is in llooccaallcchhaarrss mode, or LINEMODE is en-
-                        abled, and the ssuussppeenndd character is typed, a TELNET
-                        SUSP sequence (see sseenndd ssuusspp above) is sent to the re-
-                        mote host.  The initial value for the suspend charac-
-                        ter is taken to be the terminal's ssuussppeenndd character.
-
-                ttrraacceeffiillee
-                        This is the file to which the output, caused by
-                        nneettddaattaa or ooppttiioonn tracing being TRUE, will be written.
-                        If it is set to ``--'', then tracing information will
-                        be written to standard output (the default).
-
-                wwoorrddeerraassee
-                        If tteellnneett is operating in LINEMODE or ``old line by
-                        line`` mode, then this character is taken to be the
-                        terminal's wwoorrddeerraassee character.  The initial value for
-                        the worderase character is taken to be the terminal's
-                        wwoorrddeerraassee character.
-
-                ??       Displays the legal sseett (uunnsseett) commands.
-
-     ssllcc _s_t_a_t_e  The ssllcc command (Set Local Characters) is used to set or
-                change the state of the the special characters when the TELNET
-                LINEMODE option has been enabled.  Special characters are
-                characters that get mapped to TELNET commands sequences (like
-                iipp or qquuiitt) or line editing characters (like eerraassee and kkiillll).
-
-
-                By default, the local special characters are exported.
-
-                cchheecckk       Verify the current settings for the current spe-
-                            cial characters.  The remote side is requested to
-                            send all the current special character settings,
-                            and if there are any discrepancies with the local
-                            side, the local side will switch to the remote
-                            value.
-
-                eexxppoorrtt      Switch to the local defaults for the special char-
-                            acters.  The local default characters are those of
-                            the local terminal at the time when tteellnneett was
-                            started.
-
-                iimmppoorrtt      Switch to the remote defaults for the special
-                            characters.  The remote default characters are
-                            those of the remote system at the time when the
-                            TELNET connection was established.
-
-                ??           Prints out help information for the ssllcc command.
-
-     ssttaattuuss     Show the current status of tteellnneett. This includes the peer one
-                is connected to, as well as the current mode.
-
-     ttooggggllee _a_r_g_u_m_e_n_t_s _._._.
-                Toggle (between TRUE and FALSE) various flags that control how
-                tteellnneett responds to events.  These flags may be set explicitly
-                to TRUE or FALSE using the sseett and uunnsseett commands listed
-                above.  More than one argument may be specified.  The state of
-                these flags may be interrogated with the ddiissppllaayy command.
-                Valid arguments are:
-
-                aauutthhddeebbuugg     Turns on debugging information for the authenti-
-                              cation code.
-
-                aauuttoofflluusshh     If aauuttoofflluusshh and llooccaallcchhaarrss are both TRUE, then
-                              when the aaoo, or qquuiitt characters are recognized
-                              (and transformed into TELNET sequences; see sseett
-                              above for details), tteellnneett refuses to display
-                              any data on the user's terminal until the remote
-                              system acknowledges (via a TELNET TIMING MARK
-                              option) that it has processed those TELNET se-
-                              quences.  The initial value for this toggle is
-                              TRUE if the terminal user had not done an "stty
-                              noflsh", otherwise FALSE (see stty(1)).
-
-                aauuttooddeeccrryypptt   When the TELNET ENCRYPT option is negotiated, by
-                              default the actual encryption (decryption) of
-                              the data stream does not start automatically.
-                              The autoencrypt (autodecrypt) command states
-                              that encryption of the output (input) stream
-                              should be enabled as soon as possible.
-
-                              Note:  Because of export controls, the TELNET
-                              ENCRYPT option is not supported outside the
-                              United States and Canada.
-
-                aauuttoollooggiinn     If the remote side supports the TELNET
-                              AUTHENTICATION option TELNET attempts to use it
-                              to perform automatic authentication.  If the
-                              AUTHENTICATION option is not supported, the us-
-                              er's login name are propagated through the
-                              TELNET ENVIRON option.  This command is the same
-                              as specifying _a option on the ooppeenn command.
-
-                aauuttoossyynncchh     If aauuttoossyynncchh and llooccaallcchhaarrss are both TRUE, then
-                              when either the iinnttrr or qquuiitt characters is typed
-                              (see sseett above for descriptions of the iinnttrr and
-                              qquuiitt characters), the resulting TELNET sequence
-                              sent is followed by the TELNET SYNCH sequence.
-                              This procedure sshhoouulldd cause the remote system to
-                              begin throwing away all previously typed input
-                              until both of the TELNET sequences have been
-                              read and acted upon.  The initial value of this
-                              toggle is FALSE.
-
-                bbiinnaarryy        Enable or disable the TELNET BINARY option on
-                              both input and output.
-
-                iinnbbiinnaarryy      Enable or disable the TELNET BINARY option on
-                              input.
-
-                oouuttbbiinnaarryy     Enable or disable the TELNET BINARY option on
-                              output.
-
-                ccrrllff          If this is TRUE, then carriage returns will be
-                              sent as <CR><LF>. If this is FALSE, then car-
-                              riage returns will be send as <CR><NUL>. The
-                              initial value for this toggle is FALSE.
-
-                ccrrmmoodd         Toggle carriage return mode.  When this mode is
-                              enabled, most carriage return characters re-
-                              ceived from the remote host will be mapped into
-                              a carriage return followed by a line feed.  This
-                              mode does not affect those characters typed by
-                              the user, only those received from the remote
-                              host.  This mode is not very useful unless the
-                              remote host only sends carriage return, but nev-
-                              er line feed.  The initial value for this toggle
-                              is FALSE.
-
-                ddeebbuugg         Toggles socket level debugging (useful only to
-                              the ssuuppeerr uusseerr). The initial value for this tog-
-                              gle is FALSE.
-
-                eennccddeebbuugg      Turns on debugging information for the encryp-
-                              tion code.
-
-                llooccaallcchhaarrss    If this is TRUE, then the fflluusshh, iinntteerrrruupptt,
-                              qquuiitt, eerraassee, and kkiillll characters (see sseett above)
-                              are recognized locally, and transformed into
-                              (hopefully) appropriate TELNET control sequences
-                              (respectively aaoo, iipp, bbrrkk, eecc, and eell; see sseenndd
-                              above).  The initial value for this toggle is
-                              TRUE in ``old line by line'' mode, and FALSE in
-                              ``character at a time'' mode.  When the LINEMODE
-                              option is enabled, the value of llooccaallcchhaarrss is
-                              ignored, and assumed to always be TRUE. If
-                              LINEMODE has ever been enabled, then qquuiitt is
-                              sent as aabboorrtt, and eeooff and ssuussppeenndd are sent as
-                              eeooff and ssuusspp, see sseenndd above).
-
-                nneettddaattaa       Toggles the display of all network data (in hex-
-                              adecimal format).  The initial value for this
-                              toggle is FALSE.
-
-                ooppttiioonnss       Toggles the display of some internal tteellnneett pro-
-                              tocol processing (having to do with TELNET op-
-                              tions).  The initial value for this toggle is
-                              FALSE.
-
-                pprreettttyydduummpp    When the nneettddaattaa toggle is enabled, if
-                              pprreettttyydduummpp is enabled the output from the
-                              nneettddaattaa command will be formatted in a more user
-                              readable format.  Spaces are put between each
-                              character in the output, and the beginning of
-                              any TELNET escape sequence is preceded by a '*'
-                              to aid in locating them.
-
-                sskkiipprrcc        When the skiprc toggle is TRUE, TELNET skips the
-                              reading of the _._t_e_l_n_e_t_r_c file in the users home
-                              directory when connections are opened.  The ini-
-                              tial value for this toggle is FALSE.
-
-                tteerrmmddaattaa      Toggles the display of all terminal data (in
-                              hexadecimal format).  The initial value for this
-                              toggle is FALSE.
-
-                vveerrbboossee__eennccrryypptt
-                              When the vveerrbboossee__eennccrryypptt toggle is TRUE, TELNET
-                              prints out a message each time encryption is en-
-                              abled or disabled.  The initial value for this
-                              toggle is FALSE. Note:  Because of export con-
-                              trols, data encryption is not supported outside
-                              of the United States and Canada.
-
-                ??             Displays the legal ttooggggllee commands.
-
-     zz          Suspend tteellnneett. This command only works when the user is using
-                the csh(1).
-
-     !! [_c_o_m_m_a_n_d]
-                Execute a single command in a subshell on the local system.
-                If ccoommmmaanndd is omitted, then an interactive subshell is in-
-                voked.
-
-     ?? [_c_o_m_m_a_n_d]
-                Get help.  With no arguments, tteellnneett prints a help summary.
-                If a command is specified, tteellnneett will print the help informa-
-                tion for just that command.
-
-EENNVVIIRROONNMMEENNTT
-     TTeellnneett uses at least the HOME, SHELL, DISPLAY, and TERM environment vari-
-     ables.  Other environment variables may be propagated to the other side
-     via the TELNET ENVIRON option.
-
-FFIILLEESS
-     ~/.telnetrc  user customized telnet startup values
-
-HHIISSTTOORRYY
-     The TTeellnneett command appeared in 4.2BSD.
-
-NNOOTTEESS
-     On some remote systems, echo has to be turned off manually when in ``old
-     line by line'' mode.
-
-     In ``old line by line'' mode or LINEMODE the terminal's eeooff character is
-     only recognized (and sent to the remote system) when it is the first
-     character on a line.
-
-4.2 Berkeley Distribution        June 1, 1994                               11
diff --git a/crypto/heimdal/appl/telnet/telnetd/telnetd.cat8 b/crypto/heimdal/appl/telnet/telnetd/telnetd.cat8
deleted file mode 100644
index 988bf31b832d..000000000000
--- a/crypto/heimdal/appl/telnet/telnetd/telnetd.cat8
+++ /dev/null
@@ -1,297 +0,0 @@
-
-TELNETD(8)               UNIX System Manager's Manual               TELNETD(8)
-
-NNAAMMEE
-     tteellnneettdd - DARPA TELNET protocol server
-
-SSYYNNOOPPSSIISS
-     tteellnneettdd [--BBUUhhkkllnn] [--DD _d_e_b_u_g_m_o_d_e] [--SS _t_o_s] [--XX _a_u_t_h_t_y_p_e] [--aa _a_u_t_h_m_o_d_e]
-             [--rr_l_o_w_p_t_y_-_h_i_g_h_p_t_y] [--uu _l_e_n] [--ddeebbuugg] [--LL _/_b_i_n_/_l_o_g_i_n] [_p_o_r_t]
-
-DDEESSCCRRIIPPTTIIOONN
-     The tteellnneettdd command is a server which supports the DARPA standard TELNET
-     virtual terminal protocol.  TTeellnneettdd is normally invoked by the internet
-     server (see inetd(8))  for requests to connect to the TELNET port as in-
-     dicated by the _/_e_t_c_/_s_e_r_v_i_c_e_s file (see services(5)).  The --ddeebbuugg option
-     may be used to start up tteellnneettdd manually, instead of through inetd(8).
-     If started up this way, _p_o_r_t may be specified to run tteellnneettdd on an alter-
-     nate TCP port number.
-
-     The tteellnneettdd command accepts the following options:
-
-     --aa _a_u_t_h_m_o_d_e  This option may be used for specifying what mode should be
-                  used for authentication.  Note that this option is only use-
-                  ful if tteellnneettdd has been compiled with support for the
-                  AUTHENTICATION option.  There are several valid values for
-                  _a_u_t_h_m_o_d_e:
-
-                  debug  Turns on authentication debugging code.
-
-                  user   Only allow connections when the remote user can pro-
-                         vide valid authentication information to identify the
-                         remote user, and is allowed access to the specified
-                         account without providing a password.
-
-                  valid  Only allow connections when the remote user can pro-
-                         vide valid authentication information to identify the
-                         remote user.  The login(1) command will provide any
-                         additional user verification needed if the remote us-
-                         er is not allowed automatic access to the specified
-                         account.
-
-                  other  Only allow connections that supply some authentica-
-                         tion information.  This option is currently not sup-
-                         ported by any of the existing authentication mecha-
-                         nisms, and is thus the same as specifying --aa vvaalliidd.
-
-                  otp    Only allow authenticated connections (as with --aa
-                         uusseerr) and also logins with one-time passwords (OTPs).
-                         This option will call login with an option so that
-                         only OTPs are accepted.  The user can of course still
-                         type secret information at the prompt.
-
-                  none   This is the default state.  Authentication informa-
-                         tion is not required.  If no or insufficient authen-
-                         tication information is provided, then the login(1)
-                         program will provide the necessary user verification.
-
-                  off    This disables the authentication code.  All user ver-
-                         ification will happen through the login(1) program.
-
-     --BB           Ignored.
-
-     --DD _d_e_b_u_g_m_o_d_e
-                  This option may be used for debugging purposes.  This allows
-                  tteellnneettdd to print out debugging information to the connec-
-                  tion, allowing the user to see what tteellnneettdd is doing.  There
-                  are several possible values for _d_e_b_u_g_m_o_d_e:
-
-                  ooppttiioonnss   Prints information about the negotiation of TELNET
-                            options.
-
-                  rreeppoorrtt    Prints the ooppttiioonnss information, plus some addi-
-                            tional information about what processing is going
-                            on.
-
-                  nneettddaattaa   Displays the data stream received by tteellnneettdd.
-
-                  ppttyyddaattaa   Displays data written to the pty.
-
-                  eexxeerrcciissee  Has not been implemented yet.
-
-     --hh           Disables the printing of host-specific information before
-                  login has been completed.
-
-     --kk
-
-     --ll           Ignored.
-
-     --nn           Disable TCP keep-alives.  Normally tteellnneettdd enables the TCP
-                  keep-alive mechanism to probe connections that have been
-                  idle for some period of time to determine if the client is
-                  still there, so that idle connections from machines that
-                  have crashed or can no longer be reached may be cleaned up.
-
-     --rr _l_o_w_p_t_y_-_h_i_g_h_p_t_y
-                  This option is only enabled when tteellnneettdd is compiled for
-                  UNICOS. It specifies an inclusive range of pseudo-terminal
-                  devices to use.  If the system has sysconf variable
-                  _SC_CRAY_NPTY configured, the default pty search range is 0
-                  to _SC_CRAY_NPTY; otherwise, the default range is 0 to 128.
-                  Either _l_o_w_p_t_y or _h_i_g_h_p_t_y may be omitted to allow changing
-                  either end of the search range.  If _l_o_w_p_t_y is omitted, the -
-                  character is still required so that tteellnneettdd can differenti-
-                  ate _h_i_g_h_p_t_y from _l_o_w_p_t_y.
-
-     --SS _t_o_s
-
-     --uu _l_e_n       This option is used to specify the size of the field in the
-                  utmp structure that holds the remote host name.  If the re-
-                  solved host name is longer than _l_e_n, the dotted decimal val-
-                  ue will be used instead.  This allows hosts with very long
-                  host names that overflow this field to still be uniquely
-                  identified.  Specifying --uu00 indicates that only dotted deci-
-                  mal addresses should be put into the _u_t_m_p file.
-
-     --UU           This option causes tteellnneettdd to refuse connections from ad-
-                  dresses that cannot be mapped back into a symbolic name via
-                  the gethostbyaddr(3) routine.
-
-     --XX _a_u_t_h_t_y_p_e  This option is only valid if tteellnneettdd has been built with
-                  support for the authentication option.  It disables the use
-                  of _a_u_t_h_t_y_p_e authentication, and can be used to temporarily
-                  disable a specific authentication type without having to re-
-                  compile tteellnneettdd.
-
-     --LL --ppaatthhnnaammee
-                  Specify pathname to an alternative login program.
-
-     TTeellnneettdd operates by allocating a pseudo-terminal device (see pty(4))  for
-     a client, then creating a login process which has the slave side of the
-     pseudo-terminal as stdin, stdout and stderr. TTeellnneettdd manipulates the mas-
-     ter side of the pseudo-terminal, implementing the TELNET protocol and
-     passing characters between the remote client and the login process.
-
-     When a TELNET session is started up, tteellnneettdd sends TELNET options to the
-     client side indicating a willingness to do the following TELNET options,
-     which are described in more detail below:
-
-           DO AUTHENTICATION
-           WILL ENCRYPT
-           DO TERMINAL TYPE
-           DO TSPEED
-           DO XDISPLOC
-           DO NEW-ENVIRON
-           DO ENVIRON
-           WILL SUPPRESS GO AHEAD
-           DO ECHO
-           DO LINEMODE
-           DO NAWS
-           WILL STATUS
-           DO LFLOW
-           DO TIMING-MARK
-
-     The pseudo-terminal allocated to the client is configured to operate in
-     ``cooked'' mode, and with XTABS and CRMOD enabled (see tty(4)).
-
-     TTeellnneettdd has support for enabling locally the following TELNET options:
-
-     WILL ECHO          When the LINEMODE option is enabled, a WILL ECHO or
-                        WONT ECHO will be sent to the client to indicate the
-                        current state of terminal echoing.  When terminal echo
-                        is not desired, a WILL ECHO is sent to indicate that
-                        telnetd will take care of echoing any data that needs
-                        to be echoed to the terminal, and then nothing is
-                        echoed.  When terminal echo is desired, a WONT ECHO is
-                        sent to indicate that telnetd will not be doing any
-                        terminal echoing, so the client should do any terminal
-                        echoing that is needed.
-
-     WILL BINARY        Indicates that the client is willing to send a 8 bits
-                        of data, rather than the normal 7 bits of the Network
-                        Virtual Terminal.
-
-     WILL SGA           Indicates that it will not be sending IAC GA, go
-                        ahead, commands.
-
-     WILL STATUS        Indicates a willingness to send the client, upon re-
-                        quest, of the current status of all TELNET options.
-
-     WILL TIMING-MARK   Whenever a DO TIMING-MARK command is received, it is
-                        always responded to with a WILL TIMING-MARK
-
-     WILL LOGOUT        When a DO LOGOUT is received, a WILL LOGOUT is sent in
-                        response, and the TELNET session is shut down.
-
-     WILL ENCRYPT       Only sent if tteellnneettdd is compiled with support for data
-                        encryption, and indicates a willingness to decrypt the
-                        data stream.
-
-     TTeellnneettdd has support for enabling remotely the following TELNET options:
-
-     DO BINARY          Sent to indicate that telnetd is willing to receive an
-                        8 bit data stream.
-
-     DO LFLOW           Requests that the client handle flow control charac-
-
-
-                        ters remotely.
-
-     DO ECHO            This is not really supported, but is sent to identify
-                        a 4.2BSD telnet(1) client, which will improperly re-
-                        spond with WILL ECHO. If a WILL ECHO is received, a
-                        DONT ECHO will be sent in response.
-
-     DO TERMINAL-TYPE   Indicates a desire to be able to request the name of
-                        the type of terminal that is attached to the client
-                        side of the connection.
-
-     DO SGA             Indicates that it does not need to receive IAC GA, the
-                        go ahead command.
-
-     DO NAWS            Requests that the client inform the server when the
-                        window (display) size changes.
-
-     DO TERMINAL-SPEED  Indicates a desire to be able to request information
-                        about the speed of the serial line to which the client
-                        is attached.
-
-     DO XDISPLOC        Indicates a desire to be able to request the name of
-                        the X windows display that is associated with the tel-
-                        net client.
-
-     DO NEW-ENVIRON     Indicates a desire to be able to request environment
-                        variable information, as described in RFC 1572.
-
-     DO ENVIRON         Indicates a desire to be able to request environment
-                        variable information, as described in RFC 1408.
-
-     DO LINEMODE        Only sent if tteellnneettdd is compiled with support for
-                        linemode, and requests that the client do line by line
-                        processing.
-
-     DO TIMING-MARK     Only sent if tteellnneettdd is compiled with support for both
-                        linemode and kludge linemode, and the client responded
-                        with WONT LINEMODE. If the client responds with WILL
-                        TM, the it is assumed that the client supports kludge
-                        linemode.  Note that the [--kk] option can be used to
-                        disable this.
-
-     DO AUTHENTICATION  Only sent if tteellnneettdd is compiled with support for au-
-                        thentication, and indicates a willingness to receive
-                        authentication information for automatic login.
-
-     DO ENCRYPT         Only sent if tteellnneettdd is compiled with support for data
-                        encryption, and indicates a willingness to decrypt the
-                        data stream.
-
-EENNVVIIRROONNMMEENNTT
-FFIILLEESS
-     /etc/services
-     /etc/inittab   (UNICOS systems only)
-     /etc/iptos     (if supported)
-
-SSEEEE AALLSSOO
-     telnet(1),  login(1)
-
-SSTTAANNDDAARRDDSS
-     RRFFCC--885544   TELNET PROTOCOL SPECIFICATION
-     RRFFCC--885555   TELNET OPTION SPECIFICATIONS
-     RRFFCC--885566   TELNET BINARY TRANSMISSION
-     RRFFCC--885577   TELNET ECHO OPTION
-
-
-     RRFFCC--885588   TELNET SUPPRESS GO AHEAD OPTION
-     RRFFCC--885599   TELNET STATUS OPTION
-     RRFFCC--886600   TELNET TIMING MARK OPTION
-     RRFFCC--886611   TELNET EXTENDED OPTIONS - LIST OPTION
-     RRFFCC--888855   TELNET END OF RECORD OPTION
-     RRFFCC--11007733  Telnet Window Size Option
-     RRFFCC--11007799  Telnet Terminal Speed Option
-     RRFFCC--11009911  Telnet Terminal-Type Option
-     RRFFCC--11009966  Telnet X Display Location Option
-     RRFFCC--11112233  Requirements for Internet Hosts -- Application and Support
-     RRFFCC--11118844  Telnet Linemode Option
-     RRFFCC--11337722  Telnet Remote Flow Control Option
-     RRFFCC--11441166  Telnet Authentication Option
-     RRFFCC--11441111  Telnet Authentication: Kerberos Version 4
-     RRFFCC--11441122  Telnet Authentication: SPX
-     RRFFCC--11557711  Telnet Environment Option Interoperability Issues
-     RRFFCC--11557722  Telnet Environment Option
-
-BBUUGGSS
-     Some TELNET commands are only partially implemented.
-
-     Because of bugs in the original 4.2 BSD telnet(1),  tteellnneettdd performs some
-     dubious protocol exchanges to try to discover if the remote client is, in
-     fact, a 4.2 BSD telnet(1).
-
-     Binary mode has no common interpretation except between similar operating
-     systems (Unix in this case).
-
-     The terminal type name received from the remote client is converted to
-     lower case.
-
-     TTeellnneettdd never sends TELNET IAC GA (go ahead) commands.
-
-4.2 Berkeley Distribution        June 1, 1994                                5
diff --git a/crypto/heimdal/appl/xnlock/xnlock.cat1 b/crypto/heimdal/appl/xnlock/xnlock.cat1
deleted file mode 100644
index dde8eef6cf0b..000000000000
--- a/crypto/heimdal/appl/xnlock/xnlock.cat1
+++ /dev/null
@@ -1,132 +0,0 @@
-
-
-
-XNLOCK(1L)                                                         XNLOCK(1L)
-
-
-
-NAME
-  xnlock - amusing lock screen program with message for passers-by
-
-SYNOPSIS
-  xxnnlloocckk [ _o_p_t_i_o_n_s ] [ _m_e_s_s_a_g_e ]
-
-DESCRIPTION
-  _x_n_l_o_c_k is a program that acts as a screen saver for workstations running
-  X11.  It also "locks" the screen such that the workstation can be left
-  unattended without worry that someone else will walk up to it and mess
-  everything up.  When _x_n_l_o_c_k is running, a little man with a big nose and a
-  hat runs around spewing out messages to the screen.  By default, the mes-
-  sages are "humorous", but that depends on your sense of humor.
-
-  If a key or mouse button is pressed, a prompt is printed requesting the
-  user's password.  If a RETURN is not typed within 30 seconds, the little
-  man resumes running around.
-
-  Text on the command line is used as the message.  For example:
-          % xnlock I'm out to lunch for a couple of hours.
-  Note the need to quote shell metacharacters.
-
-  In the absence of flags or text, _x_n_l_o_c_k displays random fortunes.
-
-OPTIONS
-  Command line options override all resource specifications.  All arguments
-  that are not associated with a command line option is taken to be message
-  text that the little man will "say" every once in a while.  The resource
-  xxnnlloocckk..tteexxtt may be set to a string.
-
-  --ffnn _f_o_n_t_n_a_m_e
-       The default font is the first 18 point font in the _n_e_w _c_e_n_t_u_r_y _s_c_h_o_o_l_-
-       _b_o_o_k family.  While larger fonts are recokmmended over smaller ones,
-       any font in the server's font list will work.  The resource to use for
-       this option is xxnnlloocckk..ffoonntt.
-
-  --ffiilleennaammee  _f_i_l_e_n_a_m_e
-       Take the message to be displayed from the file _f_i_l_e_n_a_m_e.  If _f_i_l_e_n_a_m_e
-       is not specified, _$_H_O_M_E_/_._m_s_g_f_i_l_e is used.  If the contents of the file
-       are changed during runtime, the most recent text of the file is used
-       (allowing the displayed message to be altered remotely).  Carriage
-       returns within the text are allowed, but tabs or other control charac-
-       ters are not translated and should not be used.  The resource avail-
-       able for this option is xxnnlloocckk..ffiillee.
-
-  --aarr  Accept root's password to unlock screen.  This option is true by
-       default.  The reason for this is so that someone's screen may be
-       unlocked by autorized users in case of emergency and the person run-
-       ning the program is still out to lunch.  The resource available for
-       specifying this option is xxnnlloocckk..aacccceeppttRRoooottPPaasssswwdd.
-
-  --nnooaarr
-       Don't accept root's password.  This option is for paranoids who fear
-       their peers might breakin using root's password and remove their files
-       anyway.  Specifying this option on the command line overrides the
-       xxnnlloocckk..aacccceeppttRRoooottPPaasssswwdd if set to True.
-
-  --iipp  Ignore password prompt.  The resource available for this option is
-       xxnnlloocckk..iiggnnoorreePPaasssswwdd.
-
-  --nnooiipp
-       Don't ignore password prompt.  This is available in order to override
-       the resource iiggnnoorreePPaasssswwdd if set to True.
-
-  --ffgg _c_o_l_o_r
-       Specifies the foreground color.  The resource available for this is
-       xxnnlloocckk..ffoorreeggrroouunndd.
-
-  --bbgg _c_o_l_o_r
-       Specifies the background color.  The resource available for this is
-       xxnnlloocckk..bbaacckkggrroouunndd.
-
-  --rrvv  Reverse the foreground and background colors.  The resource for this
-       is xxvvnnlloocckk..rreevveerrsseeVViiddeeoo.
-
-  --nnoorrvv
-       Don't use reverse video.  This is available to override the reverseV-
-       ideo resource if set to True.
-
-  --pprroogg _p_r_o_g_r_a_m
-       Receive message text from the running program _p_r_o_g_r_a_m. If there are
-       arguments to _p_r_o_g_r_a_m, encase them with the name of the program in
-       quotes (e.g. xnlock -t "fortune -o").  The resource for this is
-       xxnnlloocckk..pprrooggrraamm.
-
-RESOURCES
-  xnlock.font:               fontname
-  xnlock.foreground:         color
-  xnlock.background:         color
-  xnlock.reverseVideo:       True/False
-  xnlock.text:               Some random text string
-  xnlock.program:            program [args]
-  xnlock.ignorePasswd:       True/False
-  xnlock.acceptRootPasswd:   True/False
-
-FILES
-  _x_n_l_o_c_k               executable file
-  ~/.msgfile                 default message file
-
-AUTHOR
-  Dan Heller <argv@sun.com>  Copyright (c) 1985, 1990.
-  The original version of this program was written using pixrects on a Sun 2
-  running SunOS 1.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/crypto/heimdal/cf/grok-type.m4 b/crypto/heimdal/cf/grok-type.m4
deleted file mode 100644
index 5bc6a66241fb..000000000000
--- a/crypto/heimdal/cf/grok-type.m4
+++ /dev/null
@@ -1,38 +0,0 @@
-dnl $Id: grok-type.m4,v 1.4 1999/11/29 11:16:48 joda Exp $
-dnl
-AC_DEFUN(AC_GROK_TYPE, [
-AC_CACHE_VAL(ac_cv_type_$1, 
-AC_TRY_COMPILE([
-#ifdef HAVE_INTTYPES_H
-#include <inttypes.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-#ifdef HAVE_SYS_BITYPES_H
-#include <sys/bitypes.h>
-#endif
-#ifdef HAVE_BIND_BITYPES_H
-#include <bind/bitypes.h>
-#endif
-#ifdef HAVE_NETINET_IN6_MACHTYPES_H
-#include <netinet/in6_machtypes.h>
-#endif
-],
-$i x;
-,
-eval ac_cv_type_$1=yes,
-eval ac_cv_type_$1=no))])
-
-AC_DEFUN(AC_GROK_TYPES, [
-for i in $1; do
-	AC_MSG_CHECKING(for $i)
-	AC_GROK_TYPE($i)
-	eval ac_res=\$ac_cv_type_$i
-	if test "$ac_res" = yes; then
-		type=HAVE_[]upcase($i)
-		AC_DEFINE_UNQUOTED($type)
-	fi
-	AC_MSG_RESULT($ac_res)
-done
-])
diff --git a/crypto/heimdal/cf/krb-find-db.m4 b/crypto/heimdal/cf/krb-find-db.m4
deleted file mode 100644
index 5d38f2e2a718..000000000000
--- a/crypto/heimdal/cf/krb-find-db.m4
+++ /dev/null
@@ -1,100 +0,0 @@
-dnl $Id: krb-find-db.m4,v 1.6 2000/08/16 03:58:51 assar Exp $
-dnl
-dnl find a suitable database library
-dnl
-dnl AC_FIND_DB(libraries)
-AC_DEFUN(KRB_FIND_DB, [
-
-lib_dbm=no
-lib_db=no
-
-for i in $1; do
-
-	if test "$i"; then
-		m="lib$i"
-		l="-l$i"
-	else
-		m="libc"
-		l=""
-	fi	
-
-	AC_MSG_CHECKING(for dbm_open in $m)
-	AC_CACHE_VAL(ac_cv_krb_dbm_open_$m, [
-
-	save_LIBS="$LIBS"
-	LIBS="$l $LIBS"
-	AC_TRY_RUN([
-#include <unistd.h>
-#include <fcntl.h>
-#if defined(HAVE_NDBM_H)
-#include <ndbm.h>
-#elif defined(HAVE_GDBM_NDBM_H)
-#include <gdbm/ndbm.h>
-#elif defined(HAVE_DBM_H)
-#include <dbm.h>
-#elif defined(HAVE_RPCSVC_DBM_H)
-#include <rpcsvc/dbm.h>
-#elif defined(HAVE_DB_H)
-#define DB_DBM_HSEARCH 1
-#include <db.h>
-#endif
-int main()
-{
-  DBM *d;
-
-  d = dbm_open("conftest", O_RDWR | O_CREAT, 0666);
-  if(d == NULL)
-    return 1;
-  dbm_close(d);
-  return 0;
-}], [
-	if test -f conftest.db; then
-		ac_res=db
-	else
-		ac_res=dbm
-	fi], ac_res=no, ac_res=no)
-
-	LIBS="$save_LIBS"
-
-	eval ac_cv_krb_dbm_open_$m=$ac_res])
-	eval ac_res=\$ac_cv_krb_dbm_open_$m
-	AC_MSG_RESULT($ac_res)
-
-	if test "$lib_dbm" = no -a $ac_res = dbm; then
-		lib_dbm="$l"
-	elif test "$lib_db" = no -a $ac_res = db; then
-		lib_db="$l"
-		break
-	fi
-done
-
-AC_MSG_CHECKING(for NDBM library)
-ac_ndbm=no
-if test "$lib_db" != no; then
-	LIB_DBM="$lib_db"
-	ac_ndbm=yes
-	AC_DEFINE(HAVE_NEW_DB, 1, [Define if NDBM really is DB (creates files ending in .db).])
-	if test "$LIB_DBM"; then
-		ac_res="yes, $LIB_DBM"
-	else
-		ac_res=yes
-	fi
-elif test "$lib_dbm" != no; then
-	LIB_DBM="$lib_dbm"
-	ac_ndbm=yes
-	if test "$LIB_DBM"; then
-		ac_res="yes, $LIB_DBM"
-	else
-		ac_res=yes
-	fi
-else
-	LIB_DBM=""
-	ac_res=no
-fi
-test "$ac_ndbm" = yes && AC_DEFINE(NDBM, 1, [Define if you have NDBM (and not DBM)])dnl
-AC_SUBST(LIB_DBM)
-DBLIB="$LIB_DBM"
-AC_SUBST(DBLIB)
-AC_MSG_RESULT($ac_res)
-
-])
diff --git a/crypto/heimdal/cf/shared-libs.m4 b/crypto/heimdal/cf/shared-libs.m4
deleted file mode 100644
index bddc1211abca..000000000000
--- a/crypto/heimdal/cf/shared-libs.m4
+++ /dev/null
@@ -1,192 +0,0 @@
-dnl
-dnl $Id: shared-libs.m4,v 1.6 2000/11/17 02:59:27 assar Exp $
-dnl
-dnl Shared library stuff has to be different everywhere
-dnl
-
-AC_DEFUN(AC_SHARED_LIBS, [
-
-dnl Check if we want to use shared libraries
-AC_ARG_ENABLE(shared,
-[  --enable-shared         create shared libraries for Kerberos])
-
-AC_SUBST(CFLAGS)dnl
-AC_SUBST(LDFLAGS)dnl
-
-case ${enable_shared} in
-  yes ) enable_shared=yes;;
-  no  ) enable_shared=no;;
-  *   ) enable_shared=no;;
-esac
-
-# NOTE: Building shared libraries may not work if you do not use gcc!
-#
-# OS		$SHLIBEXT
-# HP-UX		sl
-# Linux		so
-# NetBSD	so
-# FreeBSD	so
-# OSF		so
-# SunOS5	so
-# SunOS4	so.0.5
-# Irix		so
-#
-# LIBEXT is the extension we should build (.a or $SHLIBEXT)
-LINK='$(CC)'
-AC_SUBST(LINK)
-lib_deps=yes
-REAL_PICFLAGS="-fpic"
-LDSHARED='$(CC) $(PICFLAGS) -shared'
-LIBPREFIX=lib
-build_symlink_command=@true
-install_symlink_command=@true
-install_symlink_command2=@true
-REAL_SHLIBEXT=so
-changequote({,})dnl
-SHLIB_VERSION=`echo $VERSION | sed 's/\([0-9.]*\).*/\1/'`
-SHLIB_SONAME=`echo $VERSION | sed 's/\([0-9]*\).*/\1/'`
-changequote([,])dnl
-case "${host}" in
-*-*-hpux*)
-	REAL_SHLIBEXT=sl
-	REAL_LD_FLAGS='-Wl,+b$(libdir)'
-	if test -z "$GCC"; then
-		LDSHARED="ld -b"
-		REAL_PICFLAGS="+z"
-	fi
-	lib_deps=no
-	;;
-*-*-linux*)
-	LDSHARED='$(CC) -shared -Wl,-soname,$(LIBNAME).so.'"${SHLIB_SONAME}"
-	REAL_LD_FLAGS='-Wl,-rpath,$(libdir)'
-	REAL_SHLIBEXT=so.$SHLIB_VERSION
-	build_symlink_command='$(LN_S) -f [$][@] $(LIBNAME).so'
-	install_symlink_command='$(LN_S) -f $(LIB) $(DESTDIR)$(libdir)/$(LIBNAME).so.'"${SHLIB_SONAME}"';$(LN_S) -f $(LIB) $(DESTDIR)$(libdir)/$(LIBNAME).so'
-	install_symlink_command2='$(LN_S) -f $(LIB2) $(DESTDIR)$(libdir)/$(LIBNAME2).so.'"${SHLIB_SONAME}"';$(LN_S) -f $(LIB2) $(DESTDIR)$(libdir)/$(LIBNAME2).so'
-	;;
-changequote(,)dnl
-*-*-freebsd[345]* | *-*-freebsdelf[345]*)
-changequote([,])dnl
-	REAL_SHLIBEXT=so.$SHLIB_VERSION
-	REAL_LD_FLAGS='-Wl,-R$(libdir)'
-	build_symlink_command='$(LN_S) -f [$][@] $(LIBNAME).so'
-	install_symlink_command='$(LN_S) -f $(LIB) $(DESTDIR)$(libdir)/$(LIBNAME).so'
-	install_symlink_command2='$(LN_S) -f $(LIB2) $(DESTDIR)$(libdir)/$(LIBNAME2).so'
-	;;
-*-*-*bsd*)
-	REAL_SHLIBEXT=so.$SHLIB_VERSION
-	LDSHARED='ld -Bshareable'
-	REAL_LD_FLAGS='-Wl,-R$(libdir)'
-	;;
-*-*-osf*)
-	REAL_LD_FLAGS='-Wl,-rpath,$(libdir)'
-	REAL_PICFLAGS=
-	LDSHARED='ld -shared -expect_unresolved \*'
-	;;
-*-*-solaris2*)
-	LDSHARED='$(CC) -shared -Wl,-soname,$(LIBNAME).so.'"${SHLIB_SONAME}"
-	REAL_SHLIBEXT=so.$SHLIB_VERSION
-	build_symlink_command='$(LN_S) [$][@] $(LIBNAME).so'
-	install_symlink_command='$(LN_S) $(LIB) $(DESTDIR)$(libdir)/$(LIBNAME).so.'"${SHLIB_SONAME}"';$(LN_S) $(LIB) $(DESTDIR)$(libdir)/$(LIBNAME).so'
-	install_symlink_command2='$(LN_S) $(LIB2) $(DESTDIR)$(libdir)/$(LIBNAME2).so.'"${SHLIB_SONAME}"';$(LN_S) $(LIB2) $(DESTDIR)$(libdir)/$(LIBNAME2).so'
-	REAL_LD_FLAGS='-Wl,-R$(libdir)'
-	if test -z "$GCC"; then
-		LDSHARED='$(CC) -G -h$(LIBNAME).so.'"${SHLIB_SONAME}"
-		REAL_PICFLAGS="-Kpic"
-	fi
-	;;
-*-fujitsu-uxpv*)
-	REAL_LD_FLAGS='' # really: LD_RUN_PATH=$(libdir) cc -o ...
-	REAL_LINK='LD_RUN_PATH=$(libdir) $(CC)'
-	LDSHARED='$(CC) -G'
-	REAL_PICFLAGS="-Kpic"
-	lib_deps=no # fails in mysterious ways
-	;;
-*-*-sunos*)
-	REAL_SHLIBEXT=so.$SHLIB_VERSION
-	REAL_LD_FLAGS='-Wl,-L$(libdir)'
-	lib_deps=no
-	;;
-*-*-irix*)
-        libdir="${libdir}${abilibdirext}"
-        REAL_LD_FLAGS="${abi} -Wl,-rpath,\$(libdir)"
-        LD_FLAGS="${abi} -Wl,-rpath,\$(libdir)"
-	LDSHARED="\$(CC) -shared ${abi}"
-        REAL_PICFLAGS=
-        CFLAGS="${abi} ${CFLAGS}"
-	;;
-*-*-os2*)
-	LIBPREFIX=
-	EXECSUFFIX='.exe'
-	RANLIB=EMXOMF
-	LD_FLAGS=-Zcrtdll
-	REAL_SHLIBEXT=nobuild
-	;;
-*-*-cygwin32*)
-	EXECSUFFIX='.exe'
-	REAL_SHLIBEXT=nobuild
-	;;
-*)	REAL_SHLIBEXT=nobuild
-	REAL_PICFLAGS= 
-	;;
-esac
-
-if test "${enable_shared}" != "yes" ; then 
- PICFLAGS=""
- SHLIBEXT="nobuild"
- LIBEXT="a"
- build_symlink_command=@true
- install_symlink_command=@true
- install_symlink_command2=@true
-else
- PICFLAGS="$REAL_PICFLAGS"
- SHLIBEXT="$REAL_SHLIBEXT"
- LIBEXT="$SHLIBEXT"
- AC_MSG_CHECKING(whether to use -rpath)
- case "$libdir" in
-   /lib | /usr/lib | /usr/local/lib)
-     AC_MSG_RESULT(no)
-     REAL_LD_FLAGS=
-     LD_FLAGS=
-     ;;
-   *)
-     LD_FLAGS="$REAL_LD_FLAGS"
-     test "$REAL_LINK" && LINK="$REAL_LINK"
-     AC_MSG_RESULT($LD_FLAGS)
-     ;;
-   esac
-fi
-
-if test "$lib_deps" = yes; then
-	lib_deps_yes=""
-	lib_deps_no="# "
-else
-	lib_deps_yes="# "
-	lib_deps_no=""
-fi
-AC_SUBST(lib_deps_yes)
-AC_SUBST(lib_deps_no)
-
-# use supplied ld-flags, or none if `no'
-if test "$with_ld_flags" = no; then
-	LD_FLAGS=
-elif test -n "$with_ld_flags"; then
-	LD_FLAGS="$with_ld_flags"
-fi
-
-AC_SUBST(REAL_PICFLAGS) dnl
-AC_SUBST(REAL_SHLIBEXT) dnl
-AC_SUBST(REAL_LD_FLAGS) dnl
-
-AC_SUBST(PICFLAGS) dnl
-AC_SUBST(SHLIBEXT) dnl
-AC_SUBST(LDSHARED) dnl
-AC_SUBST(LD_FLAGS) dnl
-AC_SUBST(LIBEXT) dnl
-AC_SUBST(LIBPREFIX) dnl
-AC_SUBST(EXECSUFFIX) dnl
-
-AC_SUBST(build_symlink_command)dnl
-AC_SUBST(install_symlink_command)dnl
-AC_SUBST(install_symlink_command2)dnl
-])
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
deleted file mode 100644
index d91c087dddf9..000000000000
--- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
+++ /dev/null
@@ -1,589 +0,0 @@
-
-INTERNET-DRAFT                                         Clifford Neuman
-draft-ietf-cat-kerberos-pk-init-03.txt                      Brian Tung
-Updates: RFC 1510                                                  ISI
-expires September 30, 1997                                   John Wray
-                                         Digital Equipment Corporation
-                                                         Ari Medvinsky
-                                                           Matthew Hur
-                                                 CyberSafe Corporation
-                                                      Jonathan Trostle
-                                                                Novell
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ds.internic.net (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30,
-    1997.  Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to to associate a key pair with each realm, which
-    can then be used to facilitate cross-realm authentication; this is
-    the topic of another draft proposal.  Another way is to allow users
-    with public key certificates to use them in initial authentication.
-    This is the concern of the current document.
-
-    One of the guiding principles in the design of PKINIT is that
-    changes should be as minimal as possible.  As a result, the basic
-    mechanism of PKINIT is as follows:  The user sends a request to the
-    KDC as before, except that if that user is to use public key
-    cryptography in the initial authentication step, his certificate
-    accompanies the initial request, in the preauthentication fields.
-
-    Upon receipt of this request, the KDC verifies the certificate and
-    issues a ticket granting ticket (TGT) as before, except that instead
-    of being encrypted in the user's long-term key (which is derived
-    from a password), it is encrypted in a randomly-generated key.  This
-    random key is in turn encrypted using the public key certificate
-    that came with the request and signed using the KDC's signature key,
-    and accompanies the reply, in the preauthentication fields.
-
-    PKINIT also allows for users with only digital signature keys to
-    authenticate using those keys, and for users to store and retrieve
-    private keys on the KDC.
-
-    The PKINIT specification may also be used for direct peer to peer
-    authentication without contacting a central KDC. This application
-    of PKINIT is described in PKTAPP [4] and is based on concepts
-    introduced in [5, 6]. For direct client-to-server authentication,
-    the client uses PKINIT to authenticate to the end server (instead
-    of a central KDC), which then issues a ticket for itself.  This
-    approach has an advantage over SSL [7] in that the server does not
-    need to save state (cache session keys).  Furthermore, an
-    additional benefit is that Kerberos tickets can facilitate
-    delegation (see [8]).
-
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following changes to RFC 1510 are proposed:
-
-        --> Users may authenticate using either a public key pair or a
-            conventional (symmetric) key.  If public key cryptography is
-            used, public key data is transported in preauthentication
-            data fields to help establish identity.
-        --> Users may store private keys on the KDC for retrieval during
-            Kerberos initial authentication.
-
-    This proposal addresses two ways that users may use public key
-    cryptography for initial authentication.  Users may present public
-    key certificates, or they may generate their own session key,
-    signed by their digital signature key.  In either case, the end
-    result is that the user obtains an ordinary TGT that may be used for
-    subsequent authentication, with such authentication using only
-    conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 and 3.3 describe the extensions for the two initial
-    authentication methods.  Section 3.3 describes a way for the user to
-    store and retrieve his private key on the KDC.
-
-
-3.1.  Definitions
-
-    Hash and encryption types will be specified using ENCTYPE tags; we
-    propose the addition of the following types:
-
-        #define ENCTYPE_SIGN_DSA_GENERATE   0x0011
-        #define ENCTYPE_SIGN_DSA_VERIFY     0x0012
-        #define ENCTYPE_ENCRYPT_RSA_PRIV    0x0021
-        #define ENCTYPE_ENCRYPT_RSA_PUB     0x0022
-
-    allowing further signature types to be defined in the range 0x0011
-    through 0x001f, and further encryption types to be defined in the
-    range 0x0021 through 0x002f.
-
-    The extensions involve new preauthentication fields.  The
-    preauthentication data types are in the range 17 through 21.
-    These values are also specified along with their corresponding
-    ASN.1 definition.
-
-        #define PA-PK-AS-REQ                17
-        #define PA-PK-AS-REP                18
-        #define PA-PK-AS-SIGN               19
-        #define PA-PK-KEY-REQ               20
-        #define PA-PK-KEY-REP               21
-
-    The extensions also involve new error types.  The new error types
-    are in the range 227 through 229.  They are:
-
-        #define KDC_ERROR_CLIENT_NOT_TRUSTED    227
-        #define KDC_ERROR_KDC_NOT_TRUSTED       228
-        #define KDC_ERROR_INVALID_SIG           229
-
-    In the exposition below, we use the following terms: encryption key,
-    decryption key, signature key, verification key.  It should be
-    understood that encryption and verification keys are essentially
-    public keys, and decryption and signature keys are essentially
-    private keys.  The fact that they are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-
-3.2.  Standard Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with pk-init.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's signature key accompanies the request:
-
-    PA-PK-AS-REQ ::- SEQUENCE {
-                                -- PA TYPE 17
-        signedPKAuth            [0] SignedPKAuthenticator,
-        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the user's certificate
-                                    -- optionally followed by that
-                                    -- certificate's certifier chain
-        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
-                                    -- CAs that the client trusts
-    }
-
-    SignedPKAuthenticator ::= SEQUENCE {
-        pkAuth                  [0] PKAuthenticator,
-        pkAuthSig               [1] Signature,
-                                    -- of pkAuth
-                                    -- using user's signature key
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-                                    -- for replay prevention
-        ctime                   [1] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [2] INTEGER,
-                                    -- binds response to this request
-        kdcName                 [3] PrincipalName,
-        clientPubValue          [4] SubjectPublicKeyInfo OPTIONAL,
-                                    -- for Diffie-Hellman algorithm
-    }
-
-    Signature ::= SEQUENCE {
-        signedHash              [0] EncryptedData
-                                    -- of type Checksum
-                                    -- encrypted under signature key
-    }
-
-    Checksum ::=   SEQUENCE {
-        cksumtype               [0] INTEGER,
-        checksum                [1] OCTET STRING
-    }   -- as specified by RFC 1510
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm               [0] algorithmIdentifier,
-        subjectPublicKey        [1] BIT STRING
-    }   -- as specified by the X.509 recommendation [9]
-
-    Certificate ::= SEQUENCE {
-        CertType                [0] INTEGER,
-                                    -- type of certificate
-                                    -- 1 = X.509v3 (DER encoding)
-                                    -- 2 = PGP (per PGP draft)
-        CertData                [1] OCTET STRING
-                                    -- actual certificate
-                                    -- type determined by CertType
-    }
-
-    Note: If the signature uses RSA keys, then it is to be performed
-    as per PKCS #1.
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response, and to optionally pass the
-    client's Diffie-Hellman public value (i.e. for using DSA in
-    combination with Diffie-Hellman).  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    In the PKAuthenticator, the client may specify the KDC name in one
-    of two ways: 1) a Kerberos principal name, or 2) the name in the
-    KDC's certificate (e.g., an X.500 name, or a PGP name).  Note that
-    case #1 requires that the certificate name and the Kerberos principal
-    name be bound together (e.g., via an X.509v3 extension).
-
-    The userCert field is a sequence of certificates, the first of which
-    must be the user's public key certificate. Any subsequent
-    certificates will be certificates of the certifiers of the user's
-    certificate.  These cerificates may be used by the KDC to verify the
-    user's public key.  This field is empty if the KDC already has the
-    user's certifcate.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.  If the certification path does not match one of
-    the KDC's trusted certifiers, the KDC sends back an error message of
-    type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
-    field a list of its own trusted certifiers, upon which the client
-    resends the request.
-
-    If  trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
-    verifies that it has a certificate issued by one of the certifiers
-    trusted by the client.  If it does not have a suitable certificate,
-    the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
-    to the client. 
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on PKAuthenticator.  If that fails, the KDC returns an
-    error message of type KDC_ERROR_INVALID_SIG.  Otherwise, the KDC
-    uses the timestamp in the PKAuthenticator to assure that the request
-    is not a replay.   The KDC also verifies that its name is specified
-    in PKAuthenticator.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except that it
-    encrypts the reply not with the user's key, but with a random key
-    generated only for this particular response.  This random key
-    is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= SEQUENCE {
-                               -- PA TYPE 18
-        kdcCert                 [0] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the KDC's certificate
-                                    -- optionally followed by that
-                                    -- certificate's certifier chain
-        encPaReply              [1] EncryptedData,
-                                    -- of type PaReply
-                                    -- using either the client public
-                                    -- key or the Diffie-Hellman key
-                                    -- specified by SignedDHPublicValue
-        signedDHPublicValue     [2] SignedDHPublicValue OPTIONAL
-    }
-
-
-    PaReply ::= SEQUENCE {
-        replyEncKeyPack         [0] ReplyEncKeyPack,
-        replyEncKeyPackSig      [1] Signature,
-                                    -- of replyEncKeyPack
-                                    -- using KDC's signature key
-    }
-
-    ReplyEncKeyPack ::= SEQUENCE {
-        replyEncKey             [0] EncryptionKey,
-                                    -- used to encrypt main reply
-        nonce                   [1] INTEGER
-                                    -- binds response to the request
-                                    -- passed in the PKAuthenticator
-    }
-
-    SignedDHPublicValue ::= SEQUENCE {
-        dhPublicValue           [0] SubjectPublicKeyInfo,
-        dhPublicValueSig        [1] Signature
-                                    -- of dhPublicValue
-                                    -- using KDC's signature key
-    }
-
-    The kdcCert field is a sequence of certificates, the first of which
-    must have as its root certifier one of the certifiers sent to the
-    KDC in the PA-PK-AS-REQ. Any subsequent certificates will be 
-    certificates of the certifiers of the KDC's certificate.  These
-    cerificates may be used by the client to verify the KDC's public
-    key.  This field is empty if the client did not send to the KDC a
-    list of trusted certifiers (the trustedCertifiers field was empty).
-    
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier shall be added to the transited field of the ticket.  The
-    format of these realm names shall follow the naming constraints set
-    forth in RFC 1510 (sections 7.1 and 3.3.3.1).  Note that this will
-    require new nametypes to be defined for PGP certifiers and other
-    types of realms as they arise.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  The client then extracts
-    the random key used to encrypt the main reply.  This random key (in
-    encPaReply) is encrypted with either the client's public key or
-    with a key derived from the DH values exchanged between the client
-    and the KDC.
-
-
-3.3.  Digital Signature
-
-    Implementation of the changes in this section are OPTIONAL for
-    compliance with pk-init.
-
-    We offer this option with the warning that it requires the client to
-    generate a random key; the client may not be able to guarantee the
-    same level of randomness as the KDC.
-
-    If the user registered a digital signature key with the KDC instead
-    of an encryption key, then a separate exchange must be used.  The
-    client sends a request for a TGT as usual, except that it (rather
-    than the KDC) generates the random key that will be used to encrypt
-    the KDC response.  This key is sent to the KDC along with the
-    request in a preauthentication field:
-
-    PA-PK-AS-SIGN ::= SEQUENCE {
-                                -- PA TYPE 19
-        encSignedKeyPack        [0] EncryptedData
-                                    -- of SignedKeyPack
-                                    -- using the KDC's public key
-    }
-
-    SignedKeyPack ::= SEQUENCE {
-        signedKey               [0] KeyPack,
-        signedKeyAuth           [1] PKAuthenticator,
-        signedKeySig            [2] Signature
-                                    -- of signedKey.signedKeyAuth
-                                    -- using user's signature key
-    }
-
-    KeyPack ::= SEQUENCE {
-        randomKey               [0] EncryptionKey,
-                                    -- will be used to encrypt reply
-        nonce                   [1] INTEGER
-    }
-
-    where the nonce is copied from the request.
-
-    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
-    the randomKey.  It then replies as per RFC 1510, except that the
-    reply is encrypted not with a password-derived user key, but with
-    the randomKey sent in the request.  Since the client already knows
-    this key, there is no need to accompany the reply with an extra
-    preauthentication field.  The transited field of the ticket should
-    specify the certification path as described in Section 3.2.
-
-
-3.4.  Retrieving the Private Key From the KDC
-
-    Implementation of the changes in this section is RECOMMENDED for
-    compliance with pk-init.
-
-    When the user's private key is not stored local to the user, he may
-    choose to store the private key (normally encrypted using a
-    password-derived key) on the KDC.  We provide this option to present
-    the user with an alternative to storing the private key on local
-    disk at each machine where he expects to authenticate himself using
-    pk-init.  It should be noted that it replaces the added risk of
-    long-term storage of the private key on possibly many workstations
-    with the added risk of storing the private key on the KDC in a
-    form vulnerable to brute-force attack.
-
-    In order to obtain a private key, the client includes a
-    preauthentication field with the AS-REQ message:
-
-    PA-PK-KEY-REQ ::= SEQUENCE {
-                                -- PA TYPE 20
-        patimestamp             [0] KerberosTime OPTIONAL, 
-                                    -- used to address replay attacks.
-        pausec                  [1] INTEGER OPTIONAL,
-                                    -- used to address replay attacks.
-        nonce                   [2] INTEGER,
-                                    -- binds the reply to this request
-        privkeyID               [3] SEQUENCE OF KeyID OPTIONAL
-                                    -- constructed as a hash of
-                                    -- public key corresponding to
-                                    -- desired private key
-    }
-
-    KeyID ::= SEQUENCE {
-        KeyIdentifier           [0] OCTET STRING
-    }
-
-    The client may request a specific private key by sending the
-    corresponding ID.  If this field is left empty, then all
-    private keys are returned.
-
-    If all checks out, the KDC responds as described in the above
-    sections, except that an additional preauthentication field,
-    containing the user's private key, accompanies the reply:
-
-    PA-PK-KEY-REP ::= SEQUENCE {
-                                -- PA TYPE 21
-        nonce                   [0] INTEGER,
-                                    -- binds the reply to the request
-        KeyData                 [1] SEQUENCE OF KeyPair
-    }
-
-    KeyPair ::= SEQUENCE {
-        privKeyID               [0] OCTET STRING,
-                                    -- corresponding to encPrivKey
-        encPrivKey              [1] OCTET STRING
-    }
-
-
-3.4.1.  Additional Protection of Retrieved Private Keys
-
-    We solicit discussion on the following proposal: that the client may
-    optionally include in its request additional data to encrypt the
-    private key, which is currently only protected by the user's
-    password.  One possibility is that the client might generate a
-    random string of bits, encrypt it with the public key of the KDC (as
-    in the SignedKeyPack, but with an ordinary OCTET STRING in place of
-    an EncryptionKey), and include this with the request.  The KDC then
-    XORs each returned key with this random bit string.  (If the bit
-    string is too short, the KDC could either return an error, or XOR
-    the returned key with a repetition of the bit string.)
-
-    In order to make this work, additional means of preauthentication
-    need to be devised in order to prevent attackers from simply
-    inserting their own bit string.  One way to do this is to store
-    a hash of the password-derived key (the one used to encrypt the
-    private key).  This hash is then used in turn to derive a second
-    key (called the hash-key); the hash-key is used to encrypt an ASN.1
-    structure containing the generated bit string and a nonce value
-    that binds it to the request.
-
-    Since the KDC possesses the hash, it can generate the hash-key and
-    verify this (weaker) preauthentication, and yet cannot reproduce
-    the private key itself, since the hash is a one-way function.
-
-
-4.  Logistics and Policy Issues
-
-    We solicit discussion on how clients and KDCs should be configured
-    in order to determine which of the options described above (if any)
-    should be used.  One possibility is to set the user's database
-    record to indicate that authentication is to use public key
-    cryptography; this will not work, however, in the event that the
-    client needs to know before making the initial request.
-
-5.  Compatibility with One-Time Passcodes
-
-    We solicit discussion on how the protocol changes proposed in this
-    draft will interact with the proposed use of one-time passcodes
-    discussed in draft-ietf-cat-kerberos-passwords-00.txt.
-
-
-6.  Strength of Cryptographic Schemes
-
-    In light of recent findings on the strength of MD5 and DES,
-    we solicit discussion on which encryption types to incorporate
-    into the protocol changes.
-
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
-    Service (V5).  Request for Comments: 1510
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.
-    September 1994.
-
-    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
-    Transport Layer Security (TLS).
-    draft-ietf-tls-kerb-cipher-suites-00.txt
-
-    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
-    Public Key Cryptography.  Symposium On Network and Distributed System 
-    Security, 1997.
-
-    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic Commerce,
-    July 1995.
-
-    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
-    The SSL Protocol, Version 3.0 - IETF Draft. 
-
-    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
-    Distributed Systems.  In Proceedings of the 13th International 
-    Conference on Distributed Computing Systems, May 1993
-
-    [9] ITU-T (formerly CCITT)
-    Information technology - Open Systems Interconnection -
-    The Directory: Authentication Framework Recommendation X.509
-    ISO/IEC 9594-8
-
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-
-9.  Expiration Date
-
-    This draft expires September 30, 1997.
-
-
-10.  Authors
-
-    Clifford Neuman
-    Brian Tung
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {bcn, brian}@isi.edu
-
-    John Wray
-    Digital Equipment Corporation
-    550 King Street, LKG2-2/Z7
-    Littleton, MA 01460
-    Phone: +1 508 486 5210
-    E-mail: wray@tuxedo.enet.dec.com
-
-    Ari Medvinsky
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road Suite 310
-    Issaquah WA 98027-5378
-    Phone: +1 206 391 6000
-    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
-
-    Jonathan Trostle
-    Novell
-    E-mail: jonathan.trostle@novell.com
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt
deleted file mode 100644
index 16af15dbce9f..000000000000
--- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt
+++ /dev/null
@@ -1,6780 +0,0 @@
-INTERNET-DRAFT                                          Clifford Neuman
-                                                              John Kohl
-                                                          Theodore Ts'o
-                                                          June 25, 1999
-                                              Expires December 25, 1999
-draft-ietf-cat-kerberos-revisions-04.txt
-
-The Kerberos Network Authentication Service (V5)
-
-STATUS OF THIS MEMO
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026. 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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html. To learn the current status of any
-Internet-Draft, please check the '1id-abstracts.txt' listing contained in
-the Internet-Drafts Shadow Directories.
-
-The distribution of this memo is unlimited. It is filed as
-draft-ietf-cat-kerberos-revisions-04.txt, and expires December 25th, 1999.
-Please send comments to: krb-protocol@MIT.EDU
-
-ABSTRACT
-
-This document provides an overview and specification of Version 5 of the
-Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
-and its intended use that require more detailed or clearer explanation than
-was provided in RFC1510. This document is intended to provide a detailed
-description of the protocol, suitable for implementation, together with
-descriptions of the appropriate use of protocol messages and fields within
-those messages.
-
-This document is not intended to describe Kerberos to the end user, system
-administrator, or application developer. Higher level papers describing
-Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
-are available elsewhere.
-
-OVERVIEW
-
-This INTERNET-DRAFT describes the concepts and model upon which the Kerberos
-network authentication system is based. It also specifies Version 5 of the
-Kerberos protocol.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-The motivations, goals, assumptions, and rationale behind most design
-decisions are treated cursorily; they are more fully described in a paper
-available in IEEE communications [NT94] and earlier in the Kerberos portion
-of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
-standard and are being considered for advancement for draft standard through
-the IETF standard process. Comments are encouraged on the presentation, but
-only minor refinements to the protocol as implemented or extensions that fit
-within current protocol framework will be considered at this time.
-
-Requests for addition to an electronic mailing list for discussion of
-Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
-This mailing list is gatewayed onto the Usenet as the group
-comp.protocols.kerberos. Requests for further information, including
-documents and code availability, may be sent to info-kerberos@MIT.EDU.
-
-BACKGROUND
-
-The Kerberos model is based in part on Needham and Schroeder's trusted
-third-party authentication protocol [NS78] and on modifications suggested by
-Denning and Sacco [DS81]. The original design and implementation of Kerberos
-Versions 1 through 4 was the work of two former Project Athena staff
-members, Steve Miller of Digital Equipment Corporation and Clifford Neuman
-(now at the Information Sciences Institute of the University of Southern
-California), along with Jerome Saltzer, Technical Director of Project
-Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members
-of Project Athena have also contributed to the work on Kerberos.
-
-Version 5 of the Kerberos protocol (described in this document) has evolved
-from Version 4 based on new requirements and desires for features not
-available in Version 4. The design of Version 5 of the Kerberos protocol was
-led by Clifford Neuman and John Kohl with much input from the community. The
-development of the MIT reference implementation was led at MIT by John Kohl
-and Theodore T'so, with help and contributed code from many others. Since
-RFC1510 was issued, extensions and revisions to the protocol have been
-proposed by many individuals. Some of these proposals are reflected in this
-document. Where such changes involved significant effort, the document cites
-the contribution of the proposer.
-
-Reference implementations of both version 4 and version 5 of Kerberos are
-publicly available and commercial implementations have been developed and
-are widely used. Details on the differences between Kerberos Versions 4 and
-5 can be found in [KNT92].
-
-1. Introduction
-
-Kerberos provides a means of verifying the identities of principals, (e.g. a
-workstation user or a network server) on an open (unprotected) network. This
-is accomplished without relying on assertions by the host operating system,
-without basing trust on host addresses, without requiring physical security
-of all the hosts on the network, and under the assumption that packets
-traveling along the network can be read, modified, and inserted at will[1].
-Kerberos performs authentication under these conditions as a trusted
-third-party authentication service by using conventional (shared secret key
-[2] cryptography. Kerberos extensions have been proposed and implemented
-that provide for the use of public key cryptography during certain phases of
-the authentication protocol. These extensions provide for authentication of
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-users registered with public key certification authorities, and allow the
-system to provide certain benefits of public key cryptography in situations
-where they are needed.
-
-The basic Kerberos authentication process proceeds as follows: A client
-sends a request to the authentication server (AS) requesting 'credentials'
-for a given server. The AS responds with these credentials, encrypted in the
-client's key. The credentials consist of 1) a 'ticket' for the server and 2)
-a temporary encryption key (often called a "session key"). The client
-transmits the ticket (which contains the client's identity and a copy of the
-session key, all encrypted in the server's key) to the server. The session
-key (now shared by the client and server) is used to authenticate the
-client, and may optionally be used to authenticate the server. It may also
-be used to encrypt further communication between the two parties or to
-exchange a separate sub-session key to be used to encrypt further
-communication.
-
-Implementation of the basic protocol consists of one or more authentication
-servers running on physically secure hosts. The authentication servers
-maintain a database of principals (i.e., users and servers) and their secret
-keys. Code libraries provide encryption and implement the Kerberos protocol.
-In order to add authentication to its transactions, a typical network
-application adds one or two calls to the Kerberos library directly or
-through the Generic Security Services Application Programming Interface,
-GSSAPI, described in separate document. These calls result in the
-transmission of the necessary messages to achieve authentication.
-
-The Kerberos protocol consists of several sub-protocols (or exchanges).
-There are two basic methods by which a client can ask a Kerberos server for
-credentials. In the first approach, the client sends a cleartext request for
-a ticket for the desired server to the AS. The reply is sent encrypted in
-the client's secret key. Usually this request is for a ticket-granting
-ticket (TGT) which can later be used with the ticket-granting server (TGS).
-In the second method, the client sends a request to the TGS. The client uses
-the TGT to authenticate itself to the TGS in the same manner as if it were
-contacting any other application server that requires Kerberos
-authentication. The reply is encrypted in the session key from the TGT.
-Though the protocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different protocol entry points
-within a single Kerberos server.
-
-Once obtained, credentials may be used to verify the identity of the
-principals in a transaction, to ensure the integrity of messages exchanged
-between them, or to preserve privacy of the messages. The application is
-free to choose whatever protection may be necessary.
-
-To verify the identities of the principals in a transaction, the client
-transmits the ticket to the application server. Since the ticket is sent "in
-the clear" (parts of it are encrypted, but this encryption doesn't thwart
-replay) and might be intercepted and reused by an attacker, additional
-information is sent to prove that the message originated with the principal
-to whom the ticket was issued. This information (called the authenticator)
-is encrypted in the session key, and includes a timestamp. The timestamp
-proves that the message was recently generated and is not a replay.
-Encrypting the authenticator in the session key proves that it was generated
-by a party possessing the session key. Since no one except the requesting
-principal and the server know the session key (it is never sent over the
-network in the clear) this guarantees the identity of the client.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-The integrity of the messages exchanged between principals can also be
-guaranteed using the session key (passed in the ticket and contained in the
-credentials). This approach provides detection of both replay attacks and
-message stream modification attacks. It is accomplished by generating and
-transmitting a collision-proof checksum (elsewhere called a hash or digest
-function) of the client's message, keyed with the session key. Privacy and
-integrity of the messages exchanged between principals can be secured by
-encrypting the data to be passed using the session key contained in the
-ticket or the subsession key found in the authenticator.
-
-The authentication exchanges mentioned above require read-only access to the
-Kerberos database. Sometimes, however, the entries in the database must be
-modified, such as when adding new principals or changing a principal's key.
-This is done using a protocol between a client and a third Kerberos server,
-the Kerberos Administration Server (KADM). There is also a protocol for
-maintaining multiple copies of the Kerberos database. Neither of these
-protocols are described in this document.
-
-1.1. Cross-Realm Operation
-
-The Kerberos protocol is designed to operate across organizational
-boundaries. A client in one organization can be authenticated to a server in
-another. Each organization wishing to run a Kerberos server establishes its
-own 'realm'. The name of the realm in which a client is registered is part
-of the client's name, and can be used by the end-service to decide whether
-to honor a request.
-
-By establishing 'inter-realm' keys, the administrators of two realms can
-allow a client authenticated in the local realm to prove its identity to
-servers in other realms[3]. The exchange of inter-realm keys (a separate key
-may be used for each direction) registers the ticket-granting service of
-each realm as a principal in the other realm. A client is then able to
-obtain a ticket-granting ticket for the remote realm's ticket-granting
-service from its local realm. When that ticket-granting ticket is used, the
-remote ticket-granting service uses the inter-realm key (which usually
-differs from its own normal TGS key) to decrypt the ticket-granting ticket,
-and is thus certain that it was issued by the client's own TGS. Tickets
-issued by the remote ticket-granting service will indicate to the
-end-service that the client was authenticated from another realm.
-
-A realm is said to communicate with another realm if the two realms share an
-inter-realm key, or if the local realm shares an inter-realm key with an
-intermediate realm that communicates with the remote realm. An
-authentication path is the sequence of intermediate realms that are
-transited in communicating from one realm to another.
-
-Realms are typically organized hierarchically. Each realm shares a key with
-its parent and a different key with each child. If an inter-realm key is not
-directly shared by two realms, the hierarchical organization allows an
-authentication path to be easily constructed. If a hierarchical organization
-is not used, it may be necessary to consult a database in order to construct
-an authentication path between realms.
-
-Although realms are typically hierarchical, intermediate realms may be
-bypassed to achieve cross-realm authentication through alternate
-authentication paths (these might be established to make communication
-between two realms more efficient). It is important for the end-service to
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-know which realms were transited when deciding how much faith to place in
-the authentication process. To facilitate this decision, a field in each
-ticket contains the names of the realms that were involved in authenticating
-the client.
-
-The application server is ultimately responsible for accepting or rejecting
-authentication and should check the transited field. The application server
-may choose to rely on the KDC for the application server's realm to check
-the transited field. The application server's KDC will set the
-TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
-realms may also check the transited field as they issue
-ticket-granting-tickets for other realms, but they are encouraged not to do
-so. A client may request that the KDC's not check the transited field by
-setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
-required to honor this flag.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of verifying the
-identity of principals on a network. Authentication is usually useful
-primarily as a first step in the process of authorization, determining
-whether a client may use a service, which objects the client is allowed to
-access, and the type of access allowed for each. Kerberos does not, by
-itself, provide authorization. Possession of a client ticket for a service
-provides only for authentication of the client to that service, and in the
-absence of a separate authorization procedure, it should not be considered
-by an application as authorizing the use of that service.
-
-Such separate authorization methods may be implemented as application
-specific access control functions and may be based on files such as the
-application server, or on separately issued authorization credentials such
-as those based on proxies [Neu93] , or on other authorization services.
-
-Applications should not be modified to accept the issuance of a service
-ticket by the Kerberos server (even by an modified Kerberos server) as
-granting authority to use the service, since such applications may become
-vulnerable to the bypass of this authorization check in an environment if
-they interoperate with other KDCs or where other options for application
-authentication (e.g. the PKTAPP proposal) are provided.
-
-1.3. Environmental assumptions
-
-Kerberos imposes a few assumptions on the environment in which it can
-properly function:
-
-   * 'Denial of service' attacks are not solved with Kerberos. There are
-     places in these protocols where an intruder can prevent an application
-     from participating in the proper authentication steps. Detection and
-     solution of such attacks (some of which can appear to be nnot-uncommon
-     'normal' failure modes for the system) is usually best left to the
-     human administrators and users.
-   * Principals must keep their secret keys secret. If an intruder somehow
-     steals a principal's key, it will be able to masquerade as that
-     principal or impersonate any server to the legitimate principal.
-   * 'Password guessing' attacks are not solved by Kerberos. If a user
-     chooses a poor password, it is possible for an attacker to successfully
-     mount an offline dictionary attack by repeatedly attempting to decrypt,
-     with successive entries from a dictionary, messages obtained which are
-     encrypted under a key derived from the user's password.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-   * Each host on the network must have a clock which is 'loosely
-     synchronized' to the time of the other hosts; this synchronization is
-     used to reduce the bookkeeping needs of application servers when they
-     do replay detection. The degree of "looseness" can be configured on a
-     per-server basis, but is typically on the order of 5 minutes. If the
-     clocks are synchronized over the network, the clock synchronization
-     protocol must itself be secured from network attackers.
-   * Principal identifiers are not recycled on a short-term basis. A typical
-     mode of access control will use access control lists (ACLs) to grant
-     permissions to particular principals. If a stale ACL entry remains for
-     a deleted principal and the principal identifier is reused, the new
-     principal will inherit rights specified in the stale ACL entry. By not
-     re-using principal identifiers, the danger of inadvertent access is
-     removed.
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-Authentication
-     Verifying the claimed identity of a principal.
-Authentication header
-     A record containing a Ticket and an Authenticator to be presented to a
-     server as part of the authentication process.
-Authentication path
-     A sequence of intermediate realms transited in the authentication
-     process when communicating from one realm to another.
-Authenticator
-     A record containing information that can be shown to have been recently
-     generated using the session key known only by the client and server.
-Authorization
-     The process of determining whether a client may use a service, which
-     objects the client is allowed to access, and the type of access allowed
-     for each.
-Capability
-     A token that grants the bearer permission to access an object or
-     service. In Kerberos, this might be a ticket whose use is restricted by
-     the contents of the authorization data field, but which lists no
-     network addresses, together with the session key necessary to use the
-     ticket.
-Ciphertext
-     The output of an encryption function. Encryption transforms plaintext
-     into ciphertext.
-Client
-     A process that makes use of a network service on behalf of a user. Note
-     that in some cases a Server may itself be a client of some other server
-     (e.g. a print server may be a client of a file server).
-Credentials
-     A ticket plus the secret session key necessary to successfully use that
-     ticket in an authentication exchange.
-KDC
-     Key Distribution Center, a network service that supplies tickets and
-     temporary session keys; or an instance of that service or the host on
-     which it runs. The KDC services both initial ticket and ticket-granting
-     ticket requests. The initial ticket portion is sometimes referred to as
-     the Authentication Server (or service). The ticket-granting ticket
-     portion is sometimes referred to as the ticket-granting server (or
-     service).
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-Kerberos
-     Aside from the 3-headed dog guarding Hades, the name given to Project
-     Athena's authentication service, the protocol used by that service, or
-     the code used to implement the authentication service.
-Plaintext
-     The input to an encryption function or the output of a decryption
-     function. Decryption transforms ciphertext into plaintext.
-Principal
-     A uniquely named client or server instance that participates in a
-     network communication.
-Principal identifier
-     The name used to uniquely identify each different principal.
-Seal
-     To encipher a record containing several fields in such a way that the
-     fields cannot be individually replaced without either knowledge of the
-     encryption key or leaving evidence of tampering.
-Secret key
-     An encryption key shared by a principal and the KDC, distributed
-     outside the bounds of the system, with a long lifetime. In the case of
-     a human user's principal, the secret key is derived from a password.
-Server
-     A particular Principal which provides a resource to network clients.
-     The server is sometimes refered to as the Application Server.
-Service
-     A resource provided to network clients; often provided by more than one
-     server (for example, remote file service).
-Session key
-     A temporary encryption key used between two principals, with a lifetime
-     limited to the duration of a single login "session".
-Sub-session key
-     A temporary encryption key used between two principals, selected and
-     exchanged by the principals using the session key, and with a lifetime
-     limited to the duration of a single association.
-Ticket
-     A record that helps a client authenticate itself to a server; it
-     contains the client's identity, a session key, a timestamp, and other
-     information, all sealed using the server's secret key. It only serves
-     to authenticate a client when presented along with a fresh
-     Authenticator.
-
-2. Ticket flag uses and requests
-
-Each Kerberos ticket contains a set of flags which are used to indicate
-various attributes of that ticket. Most flags may be requested by a client
-when the ticket is obtained; some are automatically turned on and off by a
-Kerberos server as required. The following sections explain what the various
-flags mean, and gives examples of reasons to use such a flag.
-
-2.1. Initial and pre-authenticated tickets
-
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
-want to require the demonstrated knowledge of a client's secret key (e.g. a
-password-changing program) can insist that this flag be set in any tickets
-they accept, and thus be assured that the client's key was recently
-presented to the application client.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
-initial authentication, regardless of whether the current ticket was issued
-directly (in which case INITIAL will also be set) or issued on the basis of
-a ticket-granting ticket (in which case the INITIAL flag is clear, but the
-PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
-ticket-granting ticket).
-
-2.2. Invalid tickets
-
-The INVALID flag indicates that a ticket is invalid. Application servers
-must reject tickets which have this flag set. A postdated ticket will
-usually be issued in this form. Invalid tickets must be validated by the KDC
-before use, by presenting them to the KDC in a TGS request with the VALIDATE
-option specified. The KDC will only validate tickets after their starttime
-has passed. The validation is required so that postdated tickets which have
-been stolen before their starttime can be rendered permanently invalid
-(through a hot-list mechanism) (see section 3.3.3.1).
-
-2.3. Renewable tickets
-
-Applications may desire to hold tickets which can be valid for long periods
-of time. However, this can expose their credentials to potential theft for
-equally long periods, and those stolen credentials would be valid until the
-expiration time of the ticket(s). Simply using short-lived tickets and
-obtaining new ones periodically would require the client to have long-term
-access to its secret key, an even greater risk. Renewable tickets can be
-used to mitigate the consequences of theft. Renewable tickets have two
-"expiration times": the first is when the current instance of the ticket
-expires, and the second is the latest permissible value for an individual
-expiration time. An application client must periodically (i.e. before it
-expires) present a renewable ticket to the KDC, with the RENEW option set in
-the KDC request. The KDC will issue a new ticket with a new session key and
-a later expiration time. All other fields of the ticket are left unmodified
-by the renewal process. When the latest permissible expiration time arrives,
-the ticket expires permanently. At each renewal, the KDC may consult a
-hot-list to determine if the ticket had been reported stolen since its last
-renewal; it will refuse to renew such stolen tickets, and thus the usable
-lifetime of stolen tickets is reduced.
-
-The RENEWABLE flag in a ticket is normally only interpreted by the
-ticket-granting service (discussed below in section 3.3). It can usually be
-ignored by application servers. However, some particularly careful
-application servers may wish to disallow renewable tickets.
-
-If a renewable ticket is not renewed by its expiration time, the KDC will
-not renew the ticket. The RENEWABLE flag is reset by default, but a client
-may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
-message. If it is set, then the renew-till field in the ticket contains the
-time after which the ticket may not be renewed.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-2.4. Postdated tickets
-
-Applications may occasionally need to obtain tickets for use much later,
-e.g. a batch submission system would need tickets to be valid at the time
-the batch job is serviced. However, it is dangerous to hold valid tickets in
-a batch queue, since they will be on-line longer and more prone to theft.
-Postdated tickets provide a way to obtain these tickets from the KDC at job
-submission time, but to leave them "dormant" until they are activated and
-validated by a further request of the KDC. If a ticket theft were reported
-in the interim, the KDC would refuse to validate the ticket, and the thief
-would be foiled.
-
-The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. This flag
-must be set in a ticket-granting ticket in order to issue a postdated ticket
-based on the presented ticket. It is reset by default; it may be requested
-by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message.
-This flag does not allow a client to obtain a postdated ticket-granting
-ticket; postdated ticket-granting tickets can only by obtained by requesting
-the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a
-postdated ticket will be the remaining life of the ticket-granting ticket at
-the time of the request, unless the RENEWABLE option is also set, in which
-case it can be the full life (endtime-starttime) of the ticket-granting
-ticket. The KDC may limit how far in the future a ticket may be postdated.
-
-The POSTDATED flag indicates that a ticket has been postdated. The
-application server can check the authtime field in the ticket to see when
-the original authentication occurred. Some services may choose to reject
-postdated tickets, or they may only accept them within a certain period
-after the original authentication. When the KDC issues a POSTDATED ticket,
-it will also be marked as INVALID, so that the application client must
-present the ticket to the KDC to be validated before use.
-
-2.5. Proxiable and proxy tickets
-
-At times it may be necessary for a principal to allow a service to perform
-an operation on its behalf. The service must be able to take on the identity
-of the client, but only for a particular purpose. A principal can allow a
-service to take on the principal's identity for a particular purpose by
-granting it a proxy.
-
-The process of granting a proxy using the proxy and proxiable flags is used
-to provide credentials for use with specific services. Though conceptually
-also a proxy, user's wishing to delegate their identity for ANY purpose must
-use the ticket forwarding mechanism described in the next section to forward
-a ticket granting ticket.
-
-The PROXIABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. When set,
-this flag tells the ticket-granting server that it is OK to issue a new
-ticket (but not a ticket-granting ticket) with a different network address
-based on this ticket. This flag is set if requested by the client on initial
-authentication. By default, the client will request that it be set when
-requesting a ticket granting ticket, and reset when requesting any other
-ticket.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-This flag allows a client to pass a proxy to a server to perform a remote
-request on its behalf, e.g. a print service client can give the print server
-a proxy to access the client's files on a particular file server in order to
-satisfy a print request.
-
-In order to complicate the use of stolen credentials, Kerberos tickets are
-usually valid from only those network addresses specifically included in the
-ticket[4]. When granting a proxy, the client must specify the new network
-address from which the proxy is to be used, or indicate that the proxy is to
-be issued for use from any address.
-
-The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
-Application servers may check this flag and at their option they may require
-additional authentication from the agent presenting the proxy in order to
-provide an audit trail.
-
-2.6. Forwardable tickets
-
-Authentication forwarding is an instance of a proxy where the service is
-granted complete use of the client's identity. An example where it might be
-used is when a user logs in to a remote system and wants authentication to
-work from that system as if the login were local.
-
-The FORWARDABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. The
-FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
-flag, except ticket-granting tickets may also be issued with different
-network addresses. This flag is reset by default, but users may request that
-it be set by setting the FORWARDABLE option in the AS request when they
-request their initial ticket- granting ticket.
-
-This flag allows for authentication forwarding without requiring the user to
-enter a password again. If the flag is not set, then authentication
-forwarding is not permitted, but the same result can still be achieved if
-the user engages in the AS exchange specifying the requested network
-addresses and supplies a password.
-
-The FORWARDED flag is set by the TGS when a client presents a ticket with
-the FORWARDABLE flag set and requests a forwarded ticket by specifying the
-FORWARDED KDC option and supplying a set of addresses for the new ticket. It
-is also set in all tickets issued based on tickets with the FORWARDED flag
-set. Application servers may choose to process FORWARDED tickets differently
-than non-FORWARDED tickets.
-
-2.7. Other KDC options
-
-There are two additional options which may be set in a client's request of
-the KDC. The RENEWABLE-OK option indicates that the client will accept a
-renewable ticket if a ticket with the requested life cannot otherwise be
-provided. If a ticket with the requested life cannot be provided, then the
-KDC may issue a renewable ticket with a renew-till equal to the the
-requested endtime. The value of the renew-till field may still be adjusted
-by site-determined limits or limits imposed by the individual principal or
-server.
-
-The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
-It indicates that the ticket to be issued for the end server is to be
-encrypted in the session key from the a additional second ticket-granting
-ticket provided with the request. See section 3.3.3 for specific details.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-3. Message Exchanges
-
-The following sections describe the interactions between network clients and
-servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-                          Summary
-      Message direction       Message type    Section
-      1. Client to Kerberos   KRB_AS_REQ      5.4.1
-      2. Kerberos to client   KRB_AS_REP or   5.4.2
-                              KRB_ERROR       5.9.1
-
-The Authentication Service (AS) Exchange between the client and the Kerberos
-Authentication Server is initiated by a client when it wishes to obtain
-authentication credentials for a given server but currently holds no
-credentials. In its basic form, the client's secret key is used for
-encryption and decryption. This exchange is typically used at the initiation
-of a login session to obtain credentials for a Ticket-Granting Server which
-will subsequently be used to obtain credentials for other servers (see
-section 3.3) without requiring further use of the client's secret key. This
-exchange is also used to request credentials for services which must not be
-mediated through the Ticket-Granting Service, but rather require a
-principal's secret key, such as the password-changing service[5]. This
-exchange does not by itself provide any assurance of the the identity of the
-user[6].
-
-The exchange consists of two messages: KRB_AS_REQ from the client to
-Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-In the request, the client sends (in cleartext) its own identity and the
-identity of the server for which it is requesting credentials. The response,
-KRB_AS_REP, contains a ticket for the client to present to the server, and a
-session key that will be shared by the client and the server. The session
-key and additional information are encrypted in the client's secret key. The
-KRB_AS_REP message contains information which can be used to detect replays,
-and to associate it with the message to which it replies. Various errors can
-occur; these are indicated by an error response (KRB_ERROR) instead of the
-KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR
-message contains information which can be used to associate it with the
-message to which it replies. The lack of encryption in the KRB_ERROR message
-precludes the ability to detect replays, fabrications, or modifications of
-such messages.
-
-Without preautentication, the authentication server does not know whether
-the client is actually the principal named in the request. It simply sends a
-reply without knowing or caring whether they are the same. This is
-acceptable because nobody but the principal whose identity was given in the
-request will be able to use the reply. Its critical information is encrypted
-in that principal's key. The initial request supports an optional field that
-can be used to pass additional information that might be needed for the
-initial exchange. This field may be used for preauthentication as described
-in section [hl<>].
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-3.1.1. Generation of KRB_AS_REQ message
-
-The client may specify a number of options in the initial request. Among
-these options are whether pre-authentication is to be performed; whether the
-requested ticket is to be renewable, proxiable, or forwardable; whether it
-should be postdated or allow postdating of derivative tickets; and whether a
-renewable ticket will be accepted in lieu of a non-renewable ticket if the
-requested ticket expiration date cannot be satisfied by a non-renewable
-ticket (due to configuration constraints; see section 4). See section A.1
-for pseudocode.
-
-The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-If all goes well, processing the KRB_AS_REQ message will result in the
-creation of a ticket for the client to present to the server. The format for
-the ticket is described in section 5.3.1. The contents of the ticket are
-determined as follows.
-
-3.1.3. Generation of KRB_AS_REP message
-
-The authentication server looks up the client and server principals named in
-the KRB_AS_REQ in its database, extracting their respective keys. If
-required, the server pre-authenticates the request, and if the
-pre-authentication check fails, an error message with the code
-KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
-requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
-is returned. Otherwise it generates a 'random' session key[7].
-
-If there are multiple encryption keys registered for a client in the
-Kerberos database (or if the key registered supports multiple encryption
-types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS
-request is used by the KDC to select the encryption method to be used for
-encrypting the response to the client. If there is more than one supported,
-strong encryption type in the etype list, the first valid etype for which an
-encryption key is available is used. The encryption method used to respond
-to a TGS request is taken from the keytype of the session key found in the
-ticket granting ticket. [***I will change the example keytypes to be 3DES
-based examples 7/14***]
-
-When the etype field is present in a KDC request, whether an AS or TGS
-request, the KDC will attempt to assign the type of the random session key
-from the list of methods in the etype field. The KDC will select the
-appropriate type using the list of methods provided together with
-information from the Kerberos database indicating acceptable encryption
-methods for the application server. The KDC will not issue tickets with a
-weak session key encryption type.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise
-the requested start time is checked against the policy of the local realm
-(the administrator might decide to prohibit certain types or ranges of
-postdated tickets), and if acceptable, the ticket's start time is set as
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-requested and the INVALID flag is set in the new ticket. The postdated
-ticket must be validated before use by presenting it to the KDC after the
-start time has been reached.
-
-The expiration time of the ticket will be set to the minimum of the
-following:
-
-   * The expiration time (endtime) requested in the KRB_AS_REQ message.
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the client principal (the authentication server's database
-     includes a maximum ticket lifetime field in each principal's record;
-     see section 4).
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the server principal.
-   * The ticket's start time plus the maximum lifetime set by the policy of
-     the local realm.
-
-If the requested expiration time minus the start time (as determined above)
-is less than a site-determined minimum lifetime, an error message with code
-KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
-ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
-option was requested, then the 'RENEWABLE' flag is set in the new ticket,
-and the renew-till value is set as if the 'RENEWABLE' option were requested
-(the field and option names are described fully in section 5.4.1).
-
-If the RENEWABLE option has been requested or if the RENEWABLE-OK option has
-been set and a renewable ticket is to be issued, then the renew-till field
-is set to the minimum of:
-
-   * Its requested value.
-   * The start time of the ticket plus the minimum of the two maximum
-     renewable lifetimes associated with the principals' database entries.
-   * The start time of the ticket plus the maximum renewable lifetime set by
-     the policy of the local realm.
-
-The flags field of the new ticket will have the following options set if
-they have been requested and if the policy of the local realm allows:
-FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
-ticket is post-dated (the start time is in the future), its INVALID flag
-will also be set.
-
-If all of the above succeed, the server formats a KRB_AS_REP message (see
-section 5.4.2), copying the addresses in the request into the caddr of the
-response, placing any required pre-authentication data into the padata of
-the response, and encrypts the ciphertext part in the client's key using the
-requested encryption method, and sends it to the client. See section A.2 for
-pseudocode.
-
-3.1.4. Generation of KRB_ERROR message
-
-Several errors can occur, and the Authentication Server responds by
-returning an error message, KRB_ERROR, to the client, with the error-code
-and e-text fields set to appropriate values. The error message contents and
-details are described in Section 5.9.1.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-3.1.5. Receipt of KRB_AS_REP message
-
-If the reply message type is KRB_AS_REP, then the client verifies that the
-cname and crealm fields in the cleartext portion of the reply match what it
-requested. If any padata fields are present, they may be used to derive the
-proper secret key to decrypt the message. The client decrypts the encrypted
-part of the response using its secret key, verifies that the nonce in the
-encrypted part matches the nonce it supplied in its request (to detect
-replays). It also verifies that the sname and srealm in the response match
-those in the request (or are otherwise expected values), and that the host
-address field is also correct. It then stores the ticket, session key, start
-and expiration times, and other information for later use. The
-key-expiration field from the encrypted part of the response may be checked
-to notify the user of impending key expiration (the client program could
-then suggest remedial action, such as a password change). See section A.3
-for pseudocode.
-
-Proper decryption of the KRB_AS_REP message is not sufficient to verify the
-identity of the user; the user and an attacker could cooperate to generate a
-KRB_AS_REP format message which decrypts properly but is not from the proper
-KDC. If the host wishes to verify the identity of the user, it must require
-the user to present application credentials which can be verified using a
-securely-stored secret key for the host. If those credentials can be
-verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-If the reply message type is KRB_ERROR, then the client interprets it as an
-error and performs whatever application-specific tasks are necessary to
-recover.
-
-3.2. The Client/Server Authentication Exchange
-
-                             Summary
-Message direction                         Message type    Section
-Client to Application server              KRB_AP_REQ      5.5.1
-[optional] Application server to client   KRB_AP_REP or   5.5.2
-                                          KRB_ERROR       5.9.1
-
-The client/server authentication (CS) exchange is used by network
-applications to authenticate the client to the server and vice versa. The
-client must have already acquired credentials for the server using the AS or
-TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-The KRB_AP_REQ contains authentication information which should be part of
-the first message in an authenticated transaction. It contains a ticket, an
-authenticator, and some additional bookkeeping information (see section
-5.5.1 for the exact format). The ticket by itself is insufficient to
-authenticate a client, since tickets are passed across the network in
-cleartext[DS90], so the authenticator is used to prevent invalid replay of
-tickets by proving to the server that the client knows the session key of
-the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is
-referred to elsewhere as the 'authentication header.'
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-When a client wishes to initiate authentication to a server, it obtains
-(either through a credentials cache, the AS exchange, or the TGS exchange) a
-ticket and session key for the desired service. The client may re-use any
-tickets it holds until they expire. To use a ticket the client constructs a
-new Authenticator from the the system time, its name, and optionally an
-application specific checksum, an initial sequence number to be used in
-KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
-negotiations for a session key unique to this particular session.
-Authenticators may not be re-used and will be rejected if replayed to a
-server[LGDSR87]. If a sequence number is to be included, it should be
-randomly chosen so that even after many messages have been exchanged it is
-not likely to collide with other sequence numbers in use.
-
-The client may indicate a requirement of mutual authentication or the use of
-a session-key based ticket by setting the appropriate flag(s) in the
-ap-options field of the message.
-
-The Authenticator is encrypted in the session key and combined with the
-ticket to form the KRB_AP_REQ message which is then sent to the end server
-along with any additional application-specific information. See section A.9
-for pseudocode.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-Authentication is based on the server's current time of day (clocks must be
-loosely synchronized), the authenticator, and the ticket. Several errors are
-possible. If an error occurs, the server is expected to reply to the client
-with a KRB_ERROR message. This message may be encapsulated in the
-application protocol if its 'raw' form is not acceptable to the protocol.
-The format of error messages is described in section 5.9.1.
-
-The algorithm for verifying authentication information is as follows. If the
-message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE
-error. If the key version indicated by the Ticket in the KRB_AP_REQ is not
-one the server can use (e.g., it indicates an old key, and the server no
-longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is
-returned. If the USE-SESSION-KEY flag is set in the ap-options field, it
-indicates to the server that the ticket is encrypted in the session key from
-the server's ticket-granting ticket rather than its secret key[10]. Since it
-is possible for the server to be registered in multiple realms, with
-different keys in each, the srealm field in the unencrypted portion of the
-ticket in the KRB_AP_REQ is used to specify which secret key the server
-should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is
-returned if the server doesn't have the proper key to decipher the ticket.
-
-The ticket is decrypted using the version of the server's key specified by
-the ticket. If the decryption routines detect a modification of the ticket
-(each encryption system must provide safeguards to detect modified
-ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
-(chances are good that different keys were used to encrypt and decrypt).
-
-The authenticator is decrypted using the session key extracted from the
-decrypted ticket. If decryption shows it to have been modified, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client
-from the ticket are compared against the same fields in the authenticator.
-If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-not match, for example, if the wrong session key was used to encrypt the
-authenticator). The addresses in the ticket (if any) are then searched for
-an address matching the operating-system reported address of the client. If
-no match is found or the server insists on ticket addresses but none are
-present in the ticket, the KRB_AP_ERR_BADADDR error is returned.
-
-If the local (server) time and the client time in the authenticator differ
-by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW
-error is returned. If the server name, along with the client name, time and
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must
-remember any authenticator presented within the allowable clock skew, so
-that a replay attempt is guaranteed to fail. If a server loses track of any
-authenticator presented within the allowable clock skew, it must reject all
-requests until the clock skew interval has passed. This assures that any
-lost or re-played authenticators will fall outside the allowable clock skew
-and can no longer be successfully replayed (If this is not done, an attacker
-could conceivably record the ticket and authenticator sent over the network
-to a server, then disable the client's host, pose as the disabled host, and
-replay the ticket and authenticator to subvert the authentication.). If a
-sequence number is provided in the authenticator, the server saves it for
-later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is
-present, the server either saves it for later use or uses it to help
-generate its own choice for a subkey to be returned in a KRB_AP_REP message.
-
-The server computes the age of the ticket: local (server) time minus the
-start time inside the Ticket. If the start time is later than the current
-time by more than the allowable clock skew or if the INVALID flag is set in
-the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
-current time is later than end time by more than the allowable clock skew,
-the KRB_AP_ERR_TKT_EXPIRED error is returned.
-
-If all these checks succeed without an error, the server is assured that the
-client possesses the credentials of the principal named in the ticket and
-thus, the client has been authenticated to the server. See section A.10 for
-pseudocode.
-
-Passing these checks provides only authentication of the named principal; it
-does not imply authorization to use the named service. Applications must
-make a separate authorization decisions based upon the authenticated name of
-the user, the requested operation, local acces control information such as
-that contained in a .k5login or .k5users file, and possibly a separate
-distributed authorization service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-Typically, a client's request will include both the authentication
-information and its initial request in the same message, and the server need
-not explicitly reply to the KRB_AP_REQ. However, if mutual authentication
-(not only authenticating the client to the server, but also the server to
-the client) is being performed, the KRB_AP_REQ message will have
-MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is
-required in response. As with the error message, this message may be
-encapsulated in the application protocol if its "raw" form is not acceptable
-to the application's protocol. The timestamp and microsecond field used in
-the reply must be the client's timestamp and microsecond field (as provided
-in the authenticator)[12]. If a sequence number is to be included, it should
-be randomly chosen as described above for the authenticator. A subkey may be
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-included if the server desires to negotiate a different subkey. The
-KRB_AP_REP message is encrypted in the session key extracted from the
-ticket. See section A.11 for pseudocode.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-If a KRB_AP_REP message is returned, the client uses the session key from
-the credentials obtained for the server[13] to decrypt the message, and
-verifies that the timestamp and microsecond fields match those in the
-Authenticator it sent to the server. If they match, then the client is
-assured that the server is genuine. The sequence number and subkey (if
-present) are retained for later use. See section A.12 for pseudocode.
-
-3.2.6. Using the encryption key
-
-After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server
-share an encryption key which can be used by the application. The 'true
-session key' to be used for KRB_PRIV, KRB_SAFE, or other
-application-specific uses may be chosen by the application based on the
-subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
-the use of this session key will be implicit in the protocol; in others the
-method of use must be chosen from several alternatives. We leave the
-protocol negotiations of how to use the key (e.g. selecting an encryption or
-checksum type) to the application programmer; the Kerberos protocol does not
-constrain the implementation options, but an example of how this might be
-done follows.
-
-One way that an application may choose to negotiate a key to be used for
-subequent integrity and privacy protection is for the client to propose a
-key in the subkey field of the authenticator. The server can then choose a
-key using the proposed key from the client as input, returning the new
-subkey in the subkey field of the application reply. This key could then be
-used for subsequent communication. To make this example more concrete, if
-the encryption method in use required a 56 bit key, and for whatever reason,
-one of the parties was prevented from using a key with more than 40 unknown
-bits, this method would allow the the party which is prevented from using
-more than 40 bits to either propose (if the client) an initial key with a
-known quantity for 16 of those bits, or to mask 16 of the bits (if the
-server) with the known quantity. The application implementor is warned,
-however, that this is only an example, and that an analysis of the
-particular crytosystem to be used, and the reasons for limiting the key
-length, must be made before deciding whether it is acceptable to mask bits
-of the key.
-
-With both the one-way and mutual authentication exchanges, the peers should
-take care not to send sensitive information to each other without proper
-assurances. In particular, applications that require privacy or integrity
-should use the KRB_AP_REP response from the server to client to assure both
-client and server of their peer's identity. If an application protocol
-requires privacy of its messages, it can use the KRB_PRIV message (section
-3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-                          Summary
-      Message direction       Message type     Section
-      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-      2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                              KRB_ERROR        5.9.1
-
-The TGS exchange between a client and the Kerberos Ticket-Granting Server is
-initiated by a client when it wishes to obtain authentication credentials
-for a given server (which might be registered in a remote realm), when it
-wishes to renew or validate an existing ticket, or when it wishes to obtain
-a proxy ticket. In the first case, the client must already have acquired a
-ticket for the Ticket-Granting Service using the AS exchange (the
-ticket-granting ticket is usually obtained when a client initially
-authenticates to the system, such as when a user logs in). The message
-format for the TGS exchange is almost identical to that for the AS exchange.
-The primary difference is that encryption and decryption in the TGS exchange
-does not take place under the client's key. Instead, the session key from
-the ticket-granting ticket or renewable ticket, or sub-session key from an
-Authenticator is used. As is the case for all application servers, expired
-tickets are not accepted by the TGS, so once a renewable or ticket-granting
-ticket expires, the client must use a separate exchange to obtain valid
-tickets.
-
-The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
-client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
-KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
-client plus a request for credentials. The authentication information
-consists of the authentication header (KRB_AP_REQ) which includes the
-client's previously obtained ticket-granting, renewable, or invalid ticket.
-In the ticket-granting ticket and proxy cases, the request may include one
-or more of: a list of network addresses, a collection of typed authorization
-data to be sealed in the ticket for authorization use by the application
-server, or additional tickets (the use of which are described later). The
-TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the
-session key from the ticket-granting ticket or renewable ticket, or if
-present, in the sub-session key from the Authenticator (part of the
-authentication header). The KRB_ERROR message contains an error code and
-text explaining what went wrong. The KRB_ERROR message is not encrypted. The
-KRB_TGS_REP message contains information which can be used to detect
-replays, and to associate it with the message to which it replies. The
-KRB_ERROR message also contains information which can be used to associate
-it with the message to which it replies, but the lack of encryption in the
-KRB_ERROR message precludes the ability to detect replays or fabrications of
-such messages.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-Before sending a request to the ticket-granting service, the client must
-determine in which realm the application server is registered[15]. If the
-client does not already possess a ticket-granting ticket for the appropriate
-realm, then one must be obtained. This is first attempted by requesting a
-ticket-granting ticket for the destination realm from a Kerberos server for
-which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ
-message recursively). The Kerberos server may return a TGT for the desired
-realm in which case one can proceed. Alternatively, the Kerberos server may
-return a TGT for a realm which is 'closer' to the desired realm (further
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-along the standard hierarchical path), in which case this step must be
-repeated with a Kerberos server in the realm specified in the returned TGT.
-If neither are returned, then the request must be retried with a Kerberos
-server for a realm higher in the hierarchy. This request will itself require
-a ticket-granting ticket for the higher realm which must be obtained by
-recursively applying these directions.
-
-Once the client obtains a ticket-granting ticket for the appropriate realm,
-it determines which Kerberos servers serve that realm, and contacts one. The
-list might be obtained through a configuration file or network service or it
-may be generated from the name of the realm; as long as the secret keys
-exchanged by realms are kept secret, only denial of service results from
-using a false Kerberos server.
-
-As in the AS exchange, the client may specify a number of options in the
-KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
-an authentication header as an element of the padata field, and including
-the same fields as used in the KRB_AS_REQ message along with several
-optional fields: the enc-authorization-data field for application server use
-and additional tickets required by some options.
-
-In preparing the authentication header, the client can select a sub-session
-key under which the response from the Kerberos server will be encrypted[16].
-If the sub-session key is not specified, the session key from the
-ticket-granting ticket will be used. If the enc-authorization-data is
-present, it must be encrypted in the sub-session key, if present, from the
-authenticator portion of the authentication header, or if not present, using
-the session key from the ticket-granting ticket.
-
-Once prepared, the message is sent to a Kerberos server for the destination
-realm. See section A.5 for pseudocode.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
-message, but there are many additional checks to be performed. First, the
-Kerberos server must determine which server the accompanying ticket is for
-and it must select the appropriate key to decrypt it. For a normal
-KRB_TGS_REQ message, it will be for the ticket granting service, and the
-TGS's key will be used. If the TGT was issued by another realm, then the
-appropriate inter-realm key must be used. If the accompanying ticket is not
-a ticket granting ticket for the current realm, but is for an application
-server in the current realm, the RENEW, VALIDATE, or PROXY options are
-specified in the request, and the server for which a ticket is requested is
-the server named in the accompanying ticket, then the KDC will decrypt the
-ticket in the authentication header using the key of the server for which it
-was issued. If no ticket can be found in the padata field, the
-KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-Once the accompanying ticket has been decrypted, the user-supplied checksum
-in the Authenticator must be verified against the contents of the request,
-and the message rejected if the checksums do not match (with an error code
-of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
-collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
-checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
-returned. If the authorization-data are present, they are decrypted using
-the sub-session key from the Authenticator.
-
-If any of the decryptions indicate failed integrity checks, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-3.3.3. Generation of KRB_TGS_REP message
-
-The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP),
-but with its type field set to KRB_TGS_REP. The detailed specification is in
-section 5.4.2.
-
-The response will include a ticket for the requested server. The Kerberos
-database is queried to retrieve the record for the requested server
-(including the key with which the ticket will be encrypted). If the request
-is for a ticket granting ticket for a remote realm, and if no key is shared
-with the requested realm, then the Kerberos server will select the realm
-"closest" to the requested realm with which it does share a key, and use
-that realm instead. This is the only case where the response from the KDC
-will be for a different server than that requested by the client.
-
-By default, the address field, the client's name and realm, the list of
-transited realms, the time of initial authentication, the expiration time,
-and the authorization data of the newly-issued ticket will be copied from
-the ticket-granting ticket (TGT) or renewable ticket. If the transited field
-needs to be updated, but the transited type is not supported, the
-KDC_ERR_TRTYPE_NOSUPP error is returned.
-
-If the request specifies an endtime, then the endtime of the new ticket is
-set to the minimum of (a) that request, (b) the endtime from the TGT, and
-(c) the starttime of the TGT plus the minimum of the maximum life for the
-application server and the maximum life for the local realm (the maximum
-life for the requesting principal was already applied when the TGT was
-issued). If the new ticket is to be a renewal, then the endtime above is
-replaced by the minimum of (a) the value of the renew_till field of the
-ticket and (b) the starttime for the new ticket plus the life
-(endtime-starttime) of the old ticket.
-
-If the FORWARDED option has been requested, then the resulting ticket will
-contain the addresses specified by the client. This option will only be
-honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
-similar; the resulting ticket will contain the addresses specified by the
-client. It will be honored only if the PROXIABLE flag in the TGT is set. The
-PROXY option will not be honored on requests for additional ticket-granting
-tickets.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified or the MAY-POSTDATE flag is not set in the TGT, then the
-error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting
-ticket has the MAY-POSTDATE flag set, then the resulting ticket will be
-postdated and the requested starttime is checked against the policy of the
-local realm. If acceptable, the ticket's start time is set as requested, and
-the INVALID flag is set. The postdated ticket must be validated before use
-by presenting it to the KDC after the starttime has been reached. However,
-in no case may the starttime, endtime, or renew-till time of a newly-issued
-postdated ticket extend beyond the renew-till time of the ticket-granting
-ticket.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
-has been included in the request, the KDC will decrypt the additional ticket
-using the key for the server to which the additional ticket was issued and
-verify that it is a ticket-granting ticket. If the name of the requested
-server is missing from the request, the name of the client in the additional
-ticket will be used. Otherwise the name of the requested server will be
-compared to the name of the client in the additional ticket and if
-different, the request will be rejected. If the request succeeds, the
-session key from the additional ticket will be used to encrypt the new
-ticket that is issued instead of using the key of the server for which the
-new ticket will be used[17].
-
-If the name of the server in the ticket that is presented to the KDC as part
-of the authentication header is not that of the ticket-granting server
-itself, the server is registered in the realm of the KDC, and the RENEW
-option is requested, then the KDC will verify that the RENEWABLE flag is set
-in the ticket, that the INVALID flag is not set in the ticket, and that the
-renew_till time is still in the future. If the VALIDATE option is rqeuested,
-the KDC will check that the starttime has passed and the INVALID flag is
-set. If the PROXY option is requested, then the KDC will check that the
-PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket
-passes the hotlist check described in the next paragraph, the KDC will issue
-the appropriate new ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-Whenever a request is made to the ticket-granting server, the presented
-ticket(s) is(are) checked against a hot-list of tickets which have been
-canceled. This hot-list might be implemented by storing a range of issue
-timestamps for 'suspect tickets'; if a presented ticket had an authtime in
-that range, it would be rejected. In this way, a stolen ticket-granting
-ticket or renewable ticket cannot be used to gain additional tickets
-(renewals or otherwise) once the theft has been reported. Any normal ticket
-obtained before it was reported stolen will still be valid (because they
-require no interaction with the KDC), but only until their normal expiration
-time.
-
-The ciphertext part of the response in the KRB_TGS_REP message is encrypted
-in the sub-session key from the Authenticator, if present, or the session
-key key from the ticket-granting ticket. It is not encrypted using the
-client's secret key. Furthermore, the client's key's expiration date and the
-key version number fields are left out since these values are stored along
-with the client's database record, and that record is not needed to satisfy
-a request based on a ticket-granting ticket. See section A.6 for pseudocode.
-
-3.3.3.2. Encoding the transited field
-
-If the identity of the server in the TGT that is presented to the KDC as
-part of the authentication header is that of the ticket-granting service,
-but the TGT was issued from another realm, the KDC will look up the
-inter-realm key shared with that realm and use that key to decrypt the
-ticket. If the ticket is valid, then the KDC will honor the request, subject
-to the constraints outlined above in the section describing the AS exchange.
-The realm part of the client's identity will be taken from the
-ticket-granting ticket. The name of the realm that issued the
-ticket-granting ticket will be added to the transited field of the ticket to
-be issued. This is accomplished by reading the transited field from the
-ticket-granting ticket (which is treated as an unordered set of realm
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-names), adding the new realm to the set, then constructing and writing out
-its encoded (shorthand) form (this may involve a rearrangement of the
-existing encoding).
-
-Note that the ticket-granting service does not add the name of its own
-realm. Instead, its responsibility is to add the name of the previous realm.
-This prevents a malicious Kerberos server from intentionally leaving out its
-own name (it could, however, omit other realms' names).
-
-The names of neither the local realm nor the principal's realm are to be
-included in the transited field. They appear elsewhere in the ticket and
-both are known to have taken part in authenticating the principal. Since the
-endpoints are not included, both local and single-hop inter-realm
-authentication result in a transited field that is empty.
-
-Because the name of each realm transited is added to this field, it might
-potentially be very long. To decrease the length of this field, its contents
-are encoded. The initially supported encoding is optimized for the normal
-case of inter-realm communication: a hierarchical arrangement of realms
-using either domain or X.500 style realm names. This encoding (called
-DOMAIN-X500-COMPRESS) is now described.
-
-Realm names in the transited field are separated by a ",". The ",", "\",
-trailing "."s, and leading spaces (" ") are special characters, and if they
-are part of a realm name, they must be quoted in the transited field by
-preced- ing them with a "\".
-
-A realm name ending with a "." is interpreted as being prepended to the
-previous realm. For example, we can encode traversal of EDU, MIT.EDU,
-ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they
-would not be included in this field, and we would have:
-
-     "EDU,MIT.,WASHINGTON.EDU"
-
-A realm name beginning with a "/" is interpreted as being appended to the
-previous realm[18]. If it is to stand by itself, then it should be preceded
-by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
-/COM/HP, /COM, and /COM/DEC as:
-
-     "/COM,/HP,/APOLLO, /COM/DEC".
-
-Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
-they would not be included in this field, and we would have:
-
-     "/COM,/HP"
-
-A null subfield preceding or following a "," indicates that all realms
-between the previous realm and the next realm have been traversed[19]. Thus,
-"," means that all realms along the path between the client and the server
-have been traversed. ",EDU, /COM," means that that all realms from the
-client's realm up to EDU (in a domain style hierarchy) have been traversed,
-and that everything from /COM down to the server's realm in an X.500 style
-has also been traversed. This could occur if the EDU realm in one hierarchy
-shares an inter-realm key directly with the /COM realm in another hierarchy.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it is processed in the same
-manner as the KRB_AS_REP processing described above. The primary difference
-is that the ciphertext part of the response must be decrypted using the
-session key from the ticket-granting ticket rather than the client's secret
-key. See section A.7 for pseudocode.
-
-3.4. The KRB_SAFE Exchange
-
-The KRB_SAFE message may be used by clients requiring the ability to detect
-modifications of messages they exchange. It achieves this by including a
-keyed collision-proof checksum of the user data and some control
-information. The checksum is keyed with an encryption key (usually the last
-key negotiated via subkeys, or the session key if no negotiation has
-occured).
-
-3.4.1. Generation of a KRB_SAFE message
-
-When an application wishes to send a KRB_SAFE message, it collects its data
-and the appropriate control information and computes a checksum over them.
-The checksum algorithm should be a keyed one-way hash function (such as the
-RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC),
-generated using the sub-session key if present, or the session key.
-Different algorithms may be selected by changing the checksum type in the
-message. Unkeyed or non-collision-proof checksums are not suitable for this
-use.
-
-The control information for the KRB_SAFE message includes both a timestamp
-and a sequence number. The designer of an application using the KRB_SAFE
-message must choose at least one of the two mechanisms. This choice should
-be based on the needs of the application protocol.
-
-Sequence numbers are useful when all messages sent will be received by one's
-peer. Connection state is presently required to maintain the session key, so
-maintaining the next sequence number should not present an additional
-problem.
-
-If the application protocol is expected to tolerate lost messages without
-them being resent, the use of the timestamp is the appropriate replay
-detection mechanism. Using timestamps is also the appropriate mechanism for
-multi-cast protocols where all of one's peers share a common sub-session
-key, but some messages will be sent to a subset of one's peers.
-
-After computing the checksum, the client then transmits the information and
-checksum to the recipient in the message format specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-When an application receives a KRB_SAFE message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_SAFE, respectively. A mismatch
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application verifies that the checksum used is a collision-proof keyed
-checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If
-the sender's address was included in the control information, the recipient
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-verifies that the operating system's report of the sender's address matches
-the sender's address in the message, and (if a recipient address is
-specified or the recipient requires an address) that one of the recipient's
-addresses appears as the recipient's address in the message. A failed match
-for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and
-usec and/or the sequence number fields are checked. If timestamp and usec
-are expected and not present, or they are present but not current, the
-KRB_AP_ERR_SKEW error is generated. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match any
-recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT
-error is generated. If an incorrect sequence number is included, or a
-sequence number is expected but not present, the KRB_AP_ERR_BADORDER error
-is generated. If neither a time-stamp and usec or a sequence number is
-present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is
-computed over the data and control information, and if it doesn't match the
-received checksum, a KRB_AP_ERR_MODIFIED error is generated.
-
-If all the checks succeed, the application is assured that the message was
-generated by its peer and was not modi- fied in transit.
-
-3.5. The KRB_PRIV Exchange
-
-The KRB_PRIV message may be used by clients requiring confidentiality and
-the ability to detect modifications of exchanged messages. It achieves this
-by encrypting the messages and adding control information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-When an application wishes to send a KRB_PRIV message, it collects its data
-and the appropriate control information (specified in section 5.7.1) and
-encrypts them under an encryption key (usually the last key negotiated via
-subkeys, or the session key if no negotiation has occured). As part of the
-control information, the client must choose to use either a timestamp or a
-sequence number (or both); see the discussion in section 3.4.1 for
-guidelines on which to use. After the user data and control information are
-encrypted, the client transmits the ciphertext and some 'envelope'
-information to the recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-When an application receives a KRB_PRIV message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_PRIV, respectively. A mismatch
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application then decrypts the ciphertext and processes the resultant
-plaintext. If decryption shows the data to have been modified, a
-KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was
-included in the control information, the recipient verifies that the
-operating system's report of the sender's address matches the sender's
-address in the message, and (if a recipient address is specified or the
-recipient requires an address) that one of the recipient's addresses appears
-as the recipient's address in the message. A failed match for either case
-generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
-sequence number fields are checked. If timestamp and usec are expected and
-not present, or they are present but not current, the KRB_AP_ERR_SKEW error
-is generated. If the server name, along with the client name, time and
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
-number is included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
-a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-If all the checks succeed, the application can assume the message was
-generated by its peer, and was securely transmitted (without intruders able
-to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-The KRB_CRED message may be used by clients requiring the ability to send
-Kerberos credentials from one host to another. It achieves this by sending
-the tickets together with encrypted data containing the session keys and
-other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-When an application wishes to send a KRB_CRED message it first (using the
-KRB_TGS exchange) obtains credentials to be sent to the remote host. It then
-constructs a KRB_CRED message using the ticket or tickets so obtained,
-placing the session key needed to use each ticket in the key field of the
-corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED
-message.
-
-Other information associated with each ticket and obtained during the
-KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in
-the encrypted part of the KRB_CRED message. The current time and, if
-specifically required by the application the nonce, s-address, and r-address
-fields, are placed in the encrypted part of the KRB_CRED message which is
-then encrypted under an encryption key previosuly exchanged in the KRB_AP
-exchange (usually the last key negotiated via subkeys, or the session key if
-no negotiation has occured).
-
-3.6.2. Receipt of KRB_CRED message
-
-When an application receives a KRB_CRED message, it verifies it. If any
-error occurs, an error code is reported for use by the application. The
-message is verified by checking that the protocol version and type fields
-match the current version and KRB_CRED, respectively. A mismatch generates a
-KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
-decrypts the ciphertext and processes the resultant plaintext. If decryption
-shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-generated.
-
-If present or required, the recipient verifies that the operating system's
-report of the sender's address matches the sender's address in the message,
-and that one of the recipient's addresses appears as the recipient's address
-in the message. A failed match for either case generates a
-KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field
-if required) are checked next. If the timestamp and usec are not present, or
-they are present but not current, the KRB_AP_ERR_SKEW error is generated.
-
-If all the checks succeed, the application stores each of the new tickets in
-its ticket cache together with the session key and other information in the
-corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED
-message.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-4. The Kerberos Database
-
-The Kerberos server must have access to a database contain- ing the
-principal identifiers and secret keys of principals to be authenticated[21].
-
-4.1. Database contents
-
-A database entry should contain at least the following fields:
-
-Field                Value
-
-name                 Principal's identifier
-key                  Principal's secret key
-p_kvno               Principal's key version
-max_life             Maximum lifetime for Tickets
-max_renewable_life   Maximum total lifetime for renewable Tickets
-
-The name field is an encoding of the principal's identifier. The key field
-contains an encryption key. This key is the principal's secret key. (The key
-can be encrypted before storage under a Kerberos "master key" to protect it
-in case the database is compromised but the master key is not. In that case,
-an extra field must be added to indicate the master key version used, see
-below.) The p_kvno field is the key version number of the principal's secret
-key. The max_life field contains the maximum allowable lifetime (endtime -
-starttime) for any Ticket issued for this principal. The max_renewable_life
-field contains the maximum allowable total lifetime for any renewable Ticket
-issued for this principal. (See section 3.1 for a description of how these
-lifetimes are used in determining the lifetime of a given Ticket.)
-
-A server may provide KDC service to several realms, as long as the database
-representation provides a mechanism to distinguish between principal records
-with identifiers which differ only in the realm name.
-
-When an application server's key changes, if the change is routine (i.e. not
-the result of disclosure of the old key), the old key should be retained by
-the server until all tickets that had been issued using that key have
-expired. Because of this, it is possible for several keys to be active for a
-single principal. Ciphertext encrypted in a principal's key is always tagged
-with the version of the key that was used for encryption, to help the
-recipient find the proper key for decryption.
-
-When more than one key is active for a particular principal, the principal
-will have more than one record in the Kerberos database. The keys and key
-version numbers will differ between the records (the rest of the fields may
-or may not be the same). Whenever Kerberos issues a ticket, or responds to a
-request for initial authentication, the most recent key (known by the
-Kerberos server) will be used for encryption. This is the key with the
-highest key version number.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-4.2. Additional fields
-
-Project Athena's KDC implementation uses additional fields in its database:
-
-Field        Value
-
-K_kvno       Kerberos' key version
-expiration   Expiration date for entry
-attributes   Bit field of attributes
-mod_date     Timestamp of last modification
-mod_name     Modifying principal's identifier
-
-The K_kvno field indicates the key version of the Kerberos master key under
-which the principal's secret key is encrypted.
-
-After an entry's expiration date has passed, the KDC will return an error to
-any client attempting to gain tickets as or for the principal. (A database
-may want to maintain two expiration dates: one for the principal, and one
-for the principal's current key. This allows password aging to work
-independently of the principal's expiration date. However, due to the
-limited space in the responses, the KDC must combine the key expiration and
-principal expiration date into a single value called 'key_exp', which is
-used as a hint to the user to take administrative action.)
-
-The attributes field is a bitfield used to govern the operations involving
-the principal. This field might be useful in conjunction with user
-registration procedures, for site-specific policy implementations (Project
-Athena currently uses it for their user registration process controlled by
-the system-wide database service, Moira [LGDSR87]), to identify whether a
-principal can play the role of a client or server or both, to note whether a
-server is appropriate trusted to recieve credentials delegated by a client,
-or to identify the 'string to key' conversion algorithm used for a
-principal's key[22]. Other bits are used to indicate that certain ticket
-options should not be allowed in tickets encrypted under a principal's key
-(one bit each): Disallow issuing postdated tickets, disallow issuing
-forwardable tickets, disallow issuing tickets based on TGT authentication,
-disallow issuing renewable tickets, disallow issuing proxiable tickets, and
-disallow issuing tickets for which the principal is the server.
-
-The mod_date field contains the time of last modification of the entry, and
-the mod_name field contains the name of the principal which last modified
-the entry.
-
-4.3. Frequently Changing Fields
-
-Some KDC implementations may wish to maintain the last time that a request
-was made by a particular principal. Information that might be maintained
-includes the time of the last request, the time of the last request for a
-ticket-granting ticket, the time of the last use of a ticket-granting
-ticket, or other times. This information can then be returned to the user in
-the last-req field (see section 5.2).
-
-Other frequently changing information that can be maintained is the latest
-expiration time for any tickets that have been issued using each key. This
-field would be used to indicate how long old keys must remain valid to allow
-the continued use of outstanding tickets.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-4.4. Site Constants
-
-The KDC implementation should have the following configurable constants or
-options, to allow an administrator to make and enforce policy decisions:
-
-   * The minimum supported lifetime (used to determine whether the
-     KDC_ERR_NEVER_VALID error should be returned). This constant should
-     reflect reasonable expectations of round-trip time to the KDC,
-     encryption/decryption time, and processing time by the client and
-     target server, and it should allow for a minimum 'useful' lifetime.
-   * The maximum allowable total (renewable) lifetime of a ticket
-     (renew_till - starttime).
-   * The maximum allowable lifetime of a ticket (endtime - starttime).
-   * Whether to allow the issue of tickets with empty address fields
-     (including the ability to specify that such tickets may only be issued
-     if the request specifies some authorization_data).
-   * Whether proxiable, forwardable, renewable or post-datable tickets are
-     to be issued.
-
-5. Message Specifications
-
-The following sections describe the exact contents and encoding of protocol
-messages and objects. The ASN.1 base definitions are presented in the first
-subsection. The remaining subsections specify the protocol objects (tickets
-and authenticators) and messages. Specification of encryption and checksum
-techniques, and the fields related to them, appear in section 6.
-
-Optional field in ASN.1 sequences
-
-For optional integer value and date fields in ASN.1 sequences where a
-default value has been specified, certain default values will not be allowed
-in the encoding because these values will always be represented through
-defaulting by the absence of the optional field. For example, one will not
-send a microsecond zero value because one must make sure that there is only
-one way to encode this value.
-
-Additional fields in ASN.1 sequences
-
-Implementations receiving Kerberos messages with additional fields present
-in ASN.1 sequences should carry the those fields through, unmodified, when
-the message is forwarded. Implementations should not drop such fields if the
-sequence is reencoded.
-
-5.1. ASN.1 Distinguished Encoding Representation
-
-All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
-Representation of the data elements as described in the X.509 specification,
-section 8.7 [X509-88].
-
-5.3. ASN.1 Base Definitions
-
-The following ASN.1 base definitions are used in the rest of this section.
-Note that since the underscore character (_) is not permitted in ASN.1
-names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
-
-Realm ::=           GeneralString
-PrincipalName ::=   SEQUENCE {
-                    name-type[0]     INTEGER,
-                    name-string[1]   SEQUENCE OF GeneralString
-}
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
-character with the code 0 (the ASCII NUL). Most realms will usually consist
-of several components separated by periods (.), in the style of Internet
-Domain Names, or separated by slashes (/) in the style of X.500 names.
-Acceptable forms for realm names are specified in section 7. A PrincipalName
-is a typed sequence of components consisting of the following sub-fields:
-
-name-type
-     This field specifies the type of name that follows. Pre-defined values
-     for this field are specified in section 7.2. The name-type should be
-     treated as a hint. Ignoring the name type, no two names can be the same
-     (i.e. at least one of the components, or the realm, must be different).
-     This constraint may be eliminated in the future.
-name-string
-     This field encodes a sequence of components that form a name, each
-     component encoded as a GeneralString. Taken together, a PrincipalName
-     and a Realm form a principal identifier. Most PrincipalNames will have
-     only a few components (typically one or two).
-
-KerberosTime ::=   GeneralizedTime
-                   -- Specifying UTC time zone (Z)
-
-The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding
-shall specify the UTC time zone (Z) and shall not include any fractional
-portions of the seconds. It further shall not include any separators.
-Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm
-on 6 November 1985 is 19851106210627Z.
-
-HostAddress ::=     SEQUENCE  {
-                    addr-type[0]             INTEGER,
-                    address[1]               OCTET STRING
-}
-
-HostAddresses ::=   SEQUENCE OF HostAddress
-
-The host adddress encodings consists of two fields:
-
-addr-type
-     This field specifies the type of address that follows. Pre-defined
-     values for this field are specified in section 8.1.
-address
-     This field encodes a single address of type addr-type.
-
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
-AuthorizationData ::=   SEQUENCE OF SEQUENCE {
-                        ad-type[0]               INTEGER,
-                        ad-data[1]               OCTET STRING
-}
-
-ad-data
-     This field contains authorization data to be interpreted according to
-     the value of the corresponding ad-type field.
-ad-type
-     This field specifies the format for the ad-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved for
-     registered use.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-Each sequence of type and data is refered to as an authorization element.
-Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
-elements contain other elements embedded within them, and the interpretation
-of the encapsulating element determines which of the embedded elements must
-be interpreted, and which may be ignored. Definitions for these common
-elements may be found in Appendix B.
-
-TicketExtensions ::= SEQUENCE OF SEQUENCE {
-           te-type[0]       INTEGER,
-           te-data[1]       OCTET STRING
-}
-
-te-data
-     This field contains opaque data that must be caried with the ticket to
-     support extensions to the Kerberos protocol including but not limited
-     to some forms of inter-realm key exchange and plaintext authorization
-     data. See appendix C for some common uses of this field.
-te-type
-     This field specifies the format for the te-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved for
-     registered use.
-
-APOptions ::=   BIT STRING
-                  -- reserved(0),
-                  -- use-session-key(1),
-                  -- mutual-required(2)
-
-TicketFlags ::= BIT STRING
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- may-postdate(5),
-                  -- postdated(6),
-                  -- invalid(7),
-                  -- renewable(8),
-                  -- initial(9),
-                  -- pre-authent(10),
-                  -- hw-authent(11),
-                  -- transited-policy-checked(12),
-                  -- ok-as-delegate(13)
-
-KDCOptions ::=   BIT STRING
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- allow-postdate(5),
-                  -- postdated(6),
-                  -- unused7(7),
-                  -- renewable(8),
-                  -- unused9(9),
-                  -- unused10(10),
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                  -- unused11(11),
-                  -- unused12(12),
-                  -- unused13(13),
-                  -- disable-transited-check(26),
-                  -- renewable-ok(27),
-                  -- enc-tkt-in-skey(28),
-                  -- renew(30),
-                  -- validate(31)
-
-ASN.1 Bit strings have a length and a value. When used in Kerberos for the
-APOptions, TicketFlags, and KDCOptions, the length of the bit string on
-generated values should be the smallest number of bits needed to include the
-highest order bit that is set (1), but in no case less than 32 bits. The
-ASN.1 representation of the bit strings uses unnamed bits, with the meaning
-of the individual bits defined by the comments in the specification above.
-Implementations should accept values of bit strings of any length and treat
-the value of flags corresponding to bits beyond the end of the bit string as
-if the bit were reset (0). Comparison of bit strings of different length
-should treat the smaller string as if it were padded with zeros beyond the
-high order bits to the length of the longer string[23].
-
-LastReq ::=   SEQUENCE OF SEQUENCE {
-               lr-type[0]               INTEGER,
-               lr-value[1]              KerberosTime
-}
-
-lr-type
-     This field indicates how the following lr-value field is to be
-     interpreted. Negative values indicate that the information pertains
-     only to the responding server. Non-negative values pertain to all
-     servers for the realm. If the lr-type field is zero (0), then no
-     information is conveyed by the lr-value subfield. If the absolute value
-     of the lr-type field is one (1), then the lr-value subfield is the time
-     of last initial request for a TGT. If it is two (2), then the lr-value
-     subfield is the time of last initial request. If it is three (3), then
-     the lr-value subfield is the time of issue for the newest
-     ticket-granting ticket used. If it is four (4), then the lr-value
-     subfield is the time of the last renewal. If it is five (5), then the
-     lr-value subfield is the time of last request (of any type). If it is
-     (6), then the lr-value subfield is the time when the password will
-     expire.
-lr-value
-     This field contains the time of the last request. the time must be
-     interpreted according to the contents of the accompanying lr-type
-     subfield.
-
-See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
-EncryptionKey, EncryptionType, and KeyType.
-
-5.3. Tickets and Authenticators
-
-This section describes the format and encryption parameters for tickets and
-authenticators. When a ticket or authenticator is included in a protocol
-message it is treated as an opaque object.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-5.3.1. Tickets
-
-A ticket is a record that helps a client authenticate to a service. A Ticket
-contains the following information:
-
-Ticket ::=        [APPLICATION 1] SEQUENCE {
-                  tkt-vno[0]                   INTEGER,
-                  realm[1]                     Realm,
-                  sname[2]                     PrincipalName,
-                  enc-part[3]                  EncryptedData,
-                  extensions[4]                TicketExtensions OPTIONAL
-}
-
--- Encrypted part of ticket
-EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-                  flags[0]                     TicketFlags,
-                  key[1]                       EncryptionKey,
-                  crealm[2]                    Realm,
-                  cname[3]                     PrincipalName,
-                  transited[4]                 TransitedEncoding,
-                  authtime[5]                  KerberosTime,
-                  starttime[6]                 KerberosTime OPTIONAL,
-                  endtime[7]                   KerberosTime,
-                  renew-till[8]                KerberosTime OPTIONAL,
-                  caddr[9]                     HostAddresses OPTIONAL,
-                  authorization-data[10]       AuthorizationData OPTIONAL
-}
--- encoded Transited field
-TransitedEncoding ::=   SEQUENCE {
-                        tr-type[0]             INTEGER, -- must be
-registered
-                        contents[1]            OCTET STRING
-}
-
-The encoding of EncTicketPart is encrypted in the key shared by Kerberos and
-the end server (the server's secret key). See section 6 for the format of
-the ciphertext.
-
-tkt-vno
-     This field specifies the version number for the ticket format. This
-     document describes version number 5.
-realm
-     This field specifies the realm that issued a ticket. It also serves to
-     identify the realm part of the server's principal identifier. Since a
-     Kerberos server can only issue tickets for servers within its realm,
-     the two will always be identical.
-sname
-     This field specifies all components of the name part of the server's
-     identity, including those parts that identify a specific instance of a
-     service.
-enc-part
-     This field holds the encrypted encoding of the EncTicketPart sequence.
-extensions
-     [*** This change is still subject to discussion. Several alternatives
-     for this - including none at all - will be distributed to the cat and
-     krb-protocol mailing lists before the Oslo IETF, and an alternative
-     will be selected and the spec modified by 7/14/99 ***] This optional
-     field contains a sequence of extentions that may be used to carry
-     information that must be carried with the ticket to support several
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-     extensions, including but not limited to plaintext authorization data,
-     tokens for exchanging inter-realm keys, and other information that must
-     be associated with a ticket for use by the application server. See
-     Appendix C for definitions of some common extensions.
-
-     Note that some older versions of Kerberos did not support this field.
-     Because this is an optional field it will not break older clients, but
-     older clients might strip this field from the ticket before sending it
-     to the application server. This limits the usefulness of this ticket
-     field to environments where the ticket will not be parsed and
-     reconstructed by these older Kerberos clients.
-
-     If it is known that the client will strip this field from the ticket,
-     as an interim measure the KDC may append this field to the end of the
-     enc-part of the ticket and append a traler indicating the lenght of the
-     appended extensions field. (this paragraph is open for discussion,
-     including the form of the traler).
-flags
-     This field indicates which of various options were used or requested
-     when the ticket was issued. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). Bit 0 is the most
-     significant bit. The encoding of the bits is specified in section 5.2.
-     The flags are described in more detail above in section 2. The meanings
-     of the flags are:
-
-          Bit(s)      Name         Description
-
-          0           RESERVED
-                                   Reserved for future  expansion  of  this
-                                   field.
-
-          1           FORWARDABLE
-                                   The FORWARDABLE flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  When set,  this
-                                   flag  tells  the  ticket-granting server
-                                   that it is OK to  issue  a  new  ticket-
-                                   granting ticket with a different network
-                                   address based on the presented ticket.
-
-          2           FORWARDED
-                                   When set, this flag indicates  that  the
-                                   ticket  has either been forwarded or was
-                                   issued based on authentication involving
-                                   a forwarded ticket-granting ticket.
-
-          3           PROXIABLE
-                                   The  PROXIABLE  flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.   The  PROXIABLE
-                                   flag  has an interpretation identical to
-                                   that of  the  FORWARDABLE  flag,  except
-                                   that   the   PROXIABLE  flag  tells  the
-                                   ticket-granting server  that  only  non-
-                                   ticket-granting  tickets  may  be issued
-                                   with different network addresses.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-          4           PROXY
-                                   When set, this  flag  indicates  that  a
-                                   ticket is a proxy.
-
-          5           MAY-POSTDATE
-                                   The MAY-POSTDATE flag is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  This flag tells
-                                   the  ticket-granting server that a post-
-                                   dated ticket may be issued based on this
-                                   ticket-granting ticket.
-
-          6           POSTDATED
-                                   This flag indicates that this ticket has
-                                   been  postdated.   The  end-service  can
-                                   check the authtime field to see when the
-                                   original authentication occurred.
-
-          7           INVALID
-                                   This flag indicates  that  a  ticket  is
-                                   invalid, and it must be validated by the
-                                   KDC  before  use.   Application  servers
-                                   must reject tickets which have this flag
-                                   set.
-
-          8           RENEWABLE
-                                   The  RENEWABLE  flag  is  normally  only
-                                   interpreted  by the TGS, and can usually
-                                   be ignored by end servers (some particu-
-                                   larly careful servers may wish to disal-
-                                   low  renewable  tickets).   A  renewable
-                                   ticket  can be used to obtain a replace-
-                                   ment ticket  that  expires  at  a  later
-                                   date.
-
-          9           INITIAL
-                                   This flag indicates that this ticket was
-                                   issued  using  the  AS protocol, and not
-                                   issued  based   on   a   ticket-granting
-                                   ticket.
-
-          10          PRE-AUTHENT
-                                   This flag indicates that during  initial
-                                   authentication, the client was authenti-
-                                   cated by the KDC  before  a  ticket  was
-                                   issued.    The   strength  of  the  pre-
-                                   authentication method is not  indicated,
-                                   but is acceptable to the KDC.
-
-          11          HW-AUTHENT
-                                   This flag indicates  that  the  protocol
-                                   employed   for   initial  authentication
-                                   required the use of hardware expected to
-                                   be possessed solely by the named client.
-                                   The hardware  authentication  method  is
-                                   selected  by the KDC and the strength of
-                                   the method is not indicated.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-          12           TRANSITED   This flag indicates that the KDC for the
-                  POLICY-CHECKED   realm has checked the transited field
-                                   against a realm defined policy for
-                                   trusted certifiers.  If this flag is
-                                   reset (0), then the application server
-                                   must check the transited field itself,
-                                   and if unable to do so it must reject
-                                   the authentication.  If the flag is set
-                                   (1) then the application server may skip
-                                   its own validation of the transited
-                                   field, relying on the validation
-                                   performed by the KDC.  At its option the
-                                   application server may still apply its
-                                   own validation based on a separate
-                                   policy for acceptance.
-
-          13      OK-AS-DELEGATE   This flag indicates that the server (not
-                                   the client) specified in the ticket has
-                                   been determined by policy of the realm
-                                   to be a suitable recipient of
-                                   delegation.  A client can use the
-                                   presence of this flag to help it make a
-                                   decision whether to delegate credentials
-                                   (either grant a proxy or a forwarded
-                                   ticket granting ticket) to this server.
-                                   The client is free to ignore the value
-                                   of this flag.  When setting this flag,
-                                   an administrator should consider the
-                                   Security and placement of the server on
-                                   which the service will run, as well as
-                                   whether the service requires the use of
-                                   delegated credentials.
-
-          14          ANONYMOUS
-                                   This flag indicates that  the  principal
-                                   named in the ticket is a generic princi-
-                                   pal for the realm and does not  identify
-                                   the  individual  using  the ticket.  The
-                                   purpose  of  the  ticket  is   only   to
-                                   securely  distribute  a session key, and
-                                   not to identify  the  user.   Subsequent
-                                   requests  using the same ticket and ses-
-                                   sion may be  considered  as  originating
-                                   from  the  same  user, but requests with
-                                   the same username but a different ticket
-                                   are  likely  to originate from different
-                                   users.
-
-          15-31       RESERVED
-                                   Reserved for future use.
-
-key
-     This field exists in the ticket and the KDC response and is used to
-     pass the session key from Kerberos to the application server and the
-     client. The field's encoding is described in section 6.2.
-crealm
-     This field contains the name of the realm in which the client is
-     registered and in which initial authentication took place.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-cname
-     This field contains the name part of the client's principal identifier.
-transited
-     This field lists the names of the Kerberos realms that took part in
-     authenticating the user to whom this ticket was issued. It does not
-     specify the order in which the realms were transited. See section
-     3.3.3.2 for details on how this field encodes the traversed realms.
-     When the names of CA's are to be embedded inthe transited field (as
-     specified for some extentions to the protocol), the X.500 names of the
-     CA's should be mapped into items in the transited field using the
-     mapping defined by RFC2253.
-authtime
-     This field indicates the time of initial authentication for the named
-     principal. It is the time of issue for the original ticket on which
-     this ticket is based. It is included in the ticket to provide
-     additional information to the end service, and to provide the necessary
-     information for implementation of a `hot list' service at the KDC. An
-     end service that is particularly paranoid could refuse to accept
-     tickets for which the initial authentication occurred "too far" in the
-     past. This field is also returned as part of the response from the KDC.
-     When returned as part of the response to initial authentication
-     (KRB_AS_REP), this is the current time on the Ker- beros server[24].
-starttime
-     This field in the ticket specifies the time after which the ticket is
-     valid. Together with endtime, this field specifies the life of the
-     ticket. If it is absent from the ticket, its value should be treated as
-     that of the authtime field.
-endtime
-     This field contains the time after which the ticket will not be honored
-     (its expiration time). Note that individual services may place their
-     own limits on the life of a ticket and may reject tickets which have
-     not yet expired. As such, this is really an upper bound on the
-     expiration time for the ticket.
-renew-till
-     This field is only present in tickets that have the RENEWABLE flag set
-     in the flags field. It indicates the maximum endtime that may be
-     included in a renewal. It can be thought of as the absolute expiration
-     time for the ticket, including all renewals.
-caddr
-     This field in a ticket contains zero (if omitted) or more (if present)
-     host addresses. These are the addresses from which the ticket can be
-     used. If there are no addresses, the ticket can be used from any
-     location. The decision by the KDC to issue or by the end server to
-     accept zero-address tickets is a policy decision and is left to the
-     Kerberos and end-service administrators; they may refuse to issue or
-     accept such tickets. The suggested and default policy, however, is that
-     such tickets will only be issued or accepted when additional
-     information that can be used to restrict the use of the ticket is
-     included in the authorization_data field. Such a ticket is a
-     capability.
-
-     Network addresses are included in the ticket to make it harder for an
-     attacker to use stolen credentials. Because the session key is not sent
-     over the network in cleartext, credentials can't be stolen simply by
-     listening to the network; an attacker has to gain access to the session
-     key (perhaps through operating system security breaches or a careless
-     user's unattended session) to make use of stolen tickets.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-     It is important to note that the network address from which a
-     connection is received cannot be reliably determined. Even if it could
-     be, an attacker who has compromised the client's workstation could use
-     the credentials from there. Including the network addresses only makes
-     it more difficult, not impossible, for an attacker to walk off with
-     stolen credentials and then use them from a "safe" location.
-authorization-data
-     The authorization-data field is used to pass authorization data from
-     the principal on whose behalf a ticket was issued to the application
-     service. If no authorization data is included, this field will be left
-     out. Experience has shown that the name of this field is confusing, and
-     that a better name for this field would be restrictions. Unfortunately,
-     it is not possible to change the name of this field at this time.
-
-     This field contains restrictions on any authority obtained on the basis
-     of authentication using the ticket. It is possible for any principal in
-     posession of credentials to add entries to the authorization data field
-     since these entries further restrict what can be done with the ticket.
-     Such additions can be made by specifying the additional entries when a
-     new ticket is obtained during the TGS exchange, or they may be added
-     during chained delegation using the authorization data field of the
-     authenticator.
-
-     Because entries may be added to this field by the holder of
-     credentials, it is not allowable for the presence of an entry in the
-     authorization data field of a ticket to amplify the priveleges one
-     would obtain from using a ticket.
-
-     The data in this field may be specific to the end service; the field
-     will contain the names of service specific objects, and the rights to
-     those objects. The format for this field is described in section 5.2.
-     Although Kerberos is not concerned with the format of the contents of
-     the sub-fields, it does carry type information (ad-type).
-
-     By using the authorization_data field, a principal is able to issue a
-     proxy that is valid for a specific purpose. For example, a client
-     wishing to print a file can obtain a file server proxy to be passed to
-     the print server. By specifying the name of the file in the
-     authorization_data field, the file server knows that the print server
-     can only use the client's rights when accessing the particular file to
-     be printed.
-
-     A separate service providing authorization or certifying group
-     membership may be built using the authorization-data field. In this
-     case, the entity granting authorization (not the authorized entity),
-     obtains a ticket in its own name (e.g. the ticket is issued in the name
-     of a privelege server), and this entity adds restrictions on its own
-     authority and delegates the restricted authority through a proxy to the
-     client. The client would then present this authorization credential to
-     the application server separately from the authentication exchange.
-
-     Similarly, if one specifies the authorization-data field of a proxy and
-     leaves the host addresses blank, the resulting ticket and session key
-     can be treated as a capability. See [Neu93] for some suggested uses of
-     this field.
-
-     The authorization-data field is optional and does not have to be
-     included in a ticket.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-5.3.2. Authenticators
-
-An authenticator is a record sent with a ticket to a server to certify the
-client's knowledge of the encryption key in the ticket, to help the server
-detect replays, and to help choose a "true session key" to use with the
-particular session. The encoding is encrypted in the ticket's session key
-shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::= [APPLICATION 2] SEQUENCE  {
-                  authenticator-vno[0]          INTEGER,
-                  crealm[1]                     Realm,
-                  cname[2]                      PrincipalName,
-                  cksum[3]                      Checksum OPTIONAL,
-                  cusec[4]                      INTEGER,
-                  ctime[5]                      KerberosTime,
-                  subkey[6]                     EncryptionKey OPTIONAL,
-                  seq-number[7]                 INTEGER OPTIONAL,
-                  authorization-data[8]         AuthorizationData OPTIONAL
-}
-
-authenticator-vno
-     This field specifies the version number for the format of the
-     authenticator. This document specifies version 5.
-crealm and cname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-cksum
-     This field contains a checksum of the the applica- tion data that
-     accompanies the KRB_AP_REQ.
-cusec
-     This field contains the microsecond part of the client's timestamp. Its
-     value (before encryption) ranges from 0 to 999999. It often appears
-     along with ctime. The two fields are used together to specify a
-     reasonably accurate timestamp.
-ctime
-     This field contains the current time on the client's host.
-subkey
-     This field contains the client's choice for an encryption key which is
-     to be used to protect this specific application session. Unless an
-     application specifies otherwise, if this field is left out the session
-     key from the ticket will be used.
-seq-number
-     This optional field includes the initial sequence number to be used by
-     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
-     detect replays (It may also be used by application specific messages).
-     When included in the authenticator this field specifies the initial
-     sequence number for messages from the client to the server. When
-     included in the AP-REP message, the initial sequence number is that for
-     messages from the server to the client. When used in KRB_PRIV or
-     KRB_SAFE messages, it is incremented by one after each message is sent.
-     Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to
-     zero following the value 2^32 - 1.
-
-     For sequence numbers to adequately support the detection of replays
-     they should be non-repeating, even across connection boundaries. The
-     initial sequence number should be random and uniformly distributed
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-     across the full space of possible sequence numbers, so that it cannot
-     be guessed by an attacker and so that it and the successive sequence
-     numbers do not repeat other sequences.
-authorization-data
-     This field is the same as described for the ticket in section 5.3.1. It
-     is optional and will only appear when additional restrictions are to be
-     placed on the use of a ticket, beyond those carried in the ticket
-     itself.
-
-5.4. Specifications for the AS and TGS exchanges
-
-This section specifies the format of the messages used in the exchange
-between the client and the Kerberos server. The format of possible error
-messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
-KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial
-ticket or an additional ticket. In either case, the message is sent from the
-client to the Authentication Server to request credentials for a service.
-
-The message fields are:
-
-AS-REQ ::=         [APPLICATION 10] KDC-REQ
-TGS-REQ ::=        [APPLICATION 12] KDC-REQ
-
-KDC-REQ ::=        SEQUENCE {
-                   pvno[1]            INTEGER,
-                   msg-type[2]        INTEGER,
-                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
-                   req-body[4]        KDC-REQ-BODY
-}
-
-PA-DATA ::=        SEQUENCE {
-                   padata-type[1]     INTEGER,
-                   padata-value[2]    OCTET STRING,
-                                      -- might be encoded AP-REQ
-}
-
-KDC-REQ-BODY ::=   SEQUENCE {
-                    kdc-options[0]         KDCOptions,
-                    cname[1]               PrincipalName OPTIONAL,
-                                           -- Used only in AS-REQ
-                    realm[2]               Realm, -- Server's realm
-                                           -- Also client's in AS-REQ
-                    sname[3]               PrincipalName OPTIONAL,
-                    from[4]                KerberosTime OPTIONAL,
-                    till[5]                KerberosTime OPTIONAL,
-                    rtime[6]               KerberosTime OPTIONAL,
-                    nonce[7]               INTEGER,
-                    etype[8]               SEQUENCE OF INTEGER,
-                                           -- EncryptionType,
-                                           -- in preference order
-                    addresses[9]           HostAddresses OPTIONAL,
-                enc-authorization-data[10] EncryptedData OPTIONAL,
-                                           -- Encrypted AuthorizationData
-                                           -- encoding
-                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
-}
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-The fields in this message are:
-
-pvno
-     This field is included in each message, and specifies the protocol
-     version number. This document specifies protocol version 5.
-msg-type
-     This field indicates the type of a protocol message. It will almost
-     always be the same as the application identifier associated with a
-     message. It is included to make the identifier more readily accessible
-     to the application. For the KDC-REQ message, this type will be
-     KRB_AS_REQ or KRB_TGS_REQ.
-padata
-     The padata (pre-authentication data) field contains a sequence of
-     authentication information which may be needed before credentials can
-     be issued or decrypted. In the case of requests for additional tickets
-     (KRB_TGS_REQ), this field will include an element with padata-type of
-     PA-TGS-REQ and data of an authentication header (ticket-granting ticket
-     and authenticator). The checksum in the authenticator (which must be
-     collision-proof) is to be computed over the KDC-REQ-BODY encoding. In
-     most requests for initial authentication (KRB_AS_REQ) and most replies
-     (KDC-REP), the padata field will be left out.
-
-     This field may also contain information needed by certain extensions to
-     the Kerberos protocol. For example, it might be used to initially
-     verify the identity of a client before any response is returned. This
-     is accomplished with a padata field with padata-type equal to
-     PA-ENC-TIMESTAMP and padata-value defined as follows:
-
-     padata-type     ::= PA-ENC-TIMESTAMP
-     padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
-
-     PA-ENC-TS-ENC   ::= SEQUENCE {
-                     patimestamp[0]     KerberosTime, -- client's time
-                     pausec[1]          INTEGER OPTIONAL
-     }
-
-     with patimestamp containing the client's time and pausec containing the
-     microseconds which may be omitted if a client will not generate more
-     than one request per second. The ciphertext (padata-value) consists of
-     the PA-ENC-TS-ENC sequence, encrypted using the client's secret key.
-
-     [use-specified-kvno item is here for discussion and may be removed] It
-     may also be used by the client to specify the version of a key that is
-     being used for accompanying preauthentication, and/or which should be
-     used to encrypt the reply from the KDC.
-
-     PA-USE-SPECIFIED-KVNO  ::=  Integer
-
-     The KDC should only accept and abide by the value of the
-     use-specified-kvno preauthentication data field when the specified key
-     is still valid and until use of a new key is confirmed. This situation
-     is likely to occur primarily during the period during which an updated
-     key is propagating to other KDC's in a realm.
-
-     The padata field can also contain information needed to help the KDC or
-     the client select the key needed for generating or decrypting the
-     response. This form of the padata is useful for supporting the use of
-     certain token cards with Kerberos. The details of such extensions are
-     specified in separate documents. See [Pat92] for additional uses of
-     this field.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-padata-type
-     The padata-type element of the padata field indicates the way that the
-     padata-value element is to be interpreted. Negative values of
-     padata-type are reserved for unregistered use; non-negative values are
-     used for a registered interpretation of the element type.
-req-body
-     This field is a placeholder delimiting the extent of the remaining
-     fields. If a checksum is to be calculated over the request, it is
-     calculated over an encoding of the KDC-REQ-BODY sequence which is
-     enclosed within the req-body field.
-kdc-options
-     This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
-     KDC and indicates the flags that the client wants set on the tickets as
-     well as other information that is to modify the behavior of the KDC.
-     Where appropriate, the name of an option may be the same as the flag
-     that is set by that option. Although in most case, the bit in the
-     options field will be the same as that in the flags field, this is not
-     guaranteed, so it is not acceptable to simply copy the options field to
-     the flags field. There are various checks that must be made before
-     honoring an option anyway.
-
-     The kdc_options field is a bit-field, where the selected options are
-     indicated by the bit being set (1), and the unselected options and
-     reserved fields being reset (0). The encoding of the bits is specified
-     in section 5.2. The options are described in more detail above in
-     section 2. The meanings of the options are:
-
-        Bit(s)    Name                Description
-         0        RESERVED
-                                      Reserved for future  expansion  of
-this
-                                      field.
-
-         1        FORWARDABLE
-                                      The FORWARDABLE  option  indicates
-that
-                                      the  ticket  to be issued is to have
-its
-                                      forwardable flag set.  It  may  only
-be
-                                      set on the initial request, or in a
-sub-
-                                      sequent request if  the
-ticket-granting
-                                      ticket on which it is based is also
-for-
-                                      wardable.
-
-         2        FORWARDED
-                                      The FORWARDED option is  only
-specified
-                                      in  a  request  to  the
-ticket-granting
-                                      server and will only be honored  if
-the
-                                      ticket-granting  ticket  in  the
-request
-                                      has  its  FORWARDABLE  bit  set.
-This
-                                      option  indicates that this is a
-request
-                                      for forwarding.  The address(es) of
-the
-                                      host  from which the resulting ticket
-is
-                                      to  be  valid  are   included   in
-the
-                                      addresses field of the request.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-         3        PROXIABLE
-                                      The PROXIABLE option indicates that
-the
-                                      ticket to be issued is to have its
-prox-
-                                      iable flag set.  It may only be  set
-on
-                                      the  initial request, or in a
-subsequent
-                                      request if the ticket-granting ticket
-on
-                                      which it is based is also proxiable.
-
-         4        PROXY
-                                      The PROXY option indicates that this
-is
-                                      a request for a proxy.  This option
-will
-                                      only be honored if  the
-ticket-granting
-                                      ticket  in the request has its
-PROXIABLE
-                                      bit set.  The address(es)  of  the
-host
-                                      from which the resulting ticket is to
-be
-                                       valid  are  included  in  the
-addresses
-                                      field of the request.
-
-         5        ALLOW-POSTDATE
-                                      The ALLOW-POSTDATE option indicates
-that
-                                      the  ticket  to be issued is to have
-its
-                                      MAY-POSTDATE flag set.  It may  only
-be
-                                      set on the initial request, or in a
-sub-
-                                      sequent request if  the
-ticket-granting
-                                      ticket on which it is based also has
-its
-                                      MAY-POSTDATE flag set.
-
-         6        POSTDATED
-                                      The POSTDATED option indicates that
-this
-                                      is  a  request  for  a postdated
-ticket.
-                                      This option will only be honored if
-the
-                                      ticket-granting  ticket  on  which it
-is
-                                      based has  its  MAY-POSTDATE  flag
-set.
-                                      The  resulting ticket will also have
-its
-                                      INVALID flag set, and that flag  may
-be
-                                      reset by a subsequent request to the
-KDC
-                                      after the starttime in  the  ticket
-has
-                                      been reached.
-
-         7        UNUSED
-                                      This option is presently unused.
-
-         8        RENEWABLE
-                                      The RENEWABLE option indicates that
-the
-                                      ticket  to  be  issued  is  to  have
-its
-                                      RENEWABLE flag set.  It may only be
-set
-                                      on  the  initial  request,  or  when
-the
-                                      ticket-granting  ticket  on  which
-the
-                                      request  is based is also renewable.
-If
-                                      this option is requested, then the
-rtime
-                                      field   in   the  request  contains
-the
-                                      desired absolute expiration time for
-the
-                                      ticket.
-
-         9-13     UNUSED
-                                      These options are presently unused.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-         14       REQUEST-ANONYMOUS
-                                      The REQUEST-ANONYMOUS  option
-indicates
-                                      that  the  ticket to be issued is not
-to
-                                      identify  the  user  to  which  it
-was
-                                      issued.  Instead, the principal
-identif-
-                                      ier is to be generic,  as  specified
-by
-                                      the  policy  of  the realm (e.g.
-usually
-                                      anonymous@realm).  The  purpose  of
-the
-                                      ticket  is only to securely distribute
-a
-                                      session key, and  not  to  identify
-the
-                                      user.   The ANONYMOUS flag on the
-ticket
-                                      to be returned should be  set.   If
-the
-                                      local  realms  policy  does  not
-permit
-                                      anonymous credentials, the request is
-to
-                                      be rejected.
-
-         15-25    RESERVED
-                                      Reserved for future use.
-
-         26       DISABLE-TRANSITED-CHECK
-                                      By default the KDC will check the
-                                      transited field of a ticket-granting-
-                                      ticket against the policy of the local
-                                      realm before it will issue derivative
-                                      tickets based on the ticket granting
-                                      ticket.  If this flag is set in the
-                                      request, checking of the transited
-field
-                                      is disabled.  Tickets issued without
-the
-                                      performance of this check will be
-noted
-                                      by the reset (0) value of the
-                                      TRANSITED-POLICY-CHECKED flag,
-                                      indicating to the application server
-                                      that the tranisted field must be
-checked
-                                      locally.  KDC's are encouraged but not
-                                      required to honor the
-                                      DISABLE-TRANSITED-CHECK option.
-
-         27       RENEWABLE-OK
-                                      The RENEWABLE-OK option indicates that
-a
-                                      renewable ticket will be acceptable if
-a
-                                      ticket with the  requested  life
-cannot
-                                      otherwise be provided.  If a ticket
-with
-                                      the requested life cannot  be
-provided,
-                                      then  a  renewable  ticket may be
-issued
-                                      with  a  renew-till  equal  to  the
-the
-                                      requested  endtime.   The  value  of
-the
-                                      renew-till field may still be limited
-by
-                                      local  limits, or limits selected by
-the
-                                      individual principal or server.
-
-         28       ENC-TKT-IN-SKEY
-                                      This option is used only by the
-ticket-
-                                      granting  service.   The
-ENC-TKT-IN-SKEY
-                                      option indicates that the ticket for
-the
-                                      end  server  is  to  be encrypted in
-the
-                                      session key from the additional
-ticket-
-                                      granting ticket provided.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-         29       RESERVED
-                                      Reserved for future use.
-
-         30       RENEW
-                                      This option is used only by the
-ticket-
-                                      granting   service.   The  RENEW
-option
-                                      indicates that the  present  request
-is
-                                      for  a  renewal.  The ticket provided
-is
-                                      encrypted in  the  secret  key  for
-the
-                                      server  on  which  it  is  valid.
-This
-                                      option  will  only  be  honored  if
-the
-                                      ticket  to  be renewed has its
-RENEWABLE
-                                      flag set and if the time in  its
-renew-
-                                      till  field  has not passed.  The
-ticket
-                                      to be renewed is passed  in  the
-padata
-                                      field  as  part  of  the
-authentication
-                                      header.
-
-         31       VALIDATE
-                                      This option is used only by the
-ticket-
-                                      granting  service.   The VALIDATE
-option
-                                      indicates that the request is  to
-vali-
-                                      date  a  postdated ticket.  It will
-only
-                                      be honored if the  ticket  presented
-is
-                                      postdated,  presently  has  its
-INVALID
-                                      flag set, and would be otherwise
-usable
-                                      at  this time.  A ticket cannot be
-vali-
-                                      dated before its starttime.  The
-ticket
-                                      presented for validation is encrypted
-in
-                                      the key of the server for  which  it
-is
-                                      valid  and is passed in the padata
-field
-                                      as part of the authentication header.
-
-cname and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
-     specified. If absent, the name of the server is taken from the name of
-     the client in the ticket passed as additional-tickets.
-enc-authorization-data
-     The enc-authorization-data, if present (and it can only be present in
-     the TGS_REQ form), is an encoding of the desired authorization-data
-     encrypted under the sub-session key if present in the Authenticator, or
-     alternatively from the session key in the ticket-granting ticket, both
-     from the padata field in the KRB_AP_REQ.
-realm
-     This field specifies the realm part of the server's principal
-     identifier. In the AS exchange, this is also the realm part of the
-     client's principal identifier.
-from
-     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-     requests when the requested ticket is to be postdated. It specifies the
-     desired start time for the requested ticket. If this field is omitted
-     then the KDC should use the current time instead.
-till
-     This field contains the expiration date requested by the client in a
-     ticket request. It is optional and if omitted the requested ticket is
-     to have the maximum endtime permitted according to KDC policy for the
-     parties to the authentication exchange as limited by expiration date of
-     the ticket granting ticket or other preauthentication credentials.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-rtime
-     This field is the requested renew-till time sent from a client to the
-     KDC in a ticket request. It is optional.
-nonce
-     This field is part of the KDC request and response. It it intended to
-     hold a random number generated by the client. If the same number is
-     included in the encrypted response from the KDC, it provides evidence
-     that the response is fresh and has not been replayed by an attacker.
-     Nonces must never be re-used. Ideally, it should be generated randomly,
-     but if the correct time is known, it may suffice[25].
-etype
-     This field specifies the desired encryption algorithm to be used in the
-     response.
-addresses
-     This field is included in the initial request for tickets, and
-     optionally included in requests for additional tickets from the
-     ticket-granting server. It specifies the addresses from which the
-     requested ticket is to be valid. Normally it includes the addresses for
-     the client's host. If a proxy is requested, this field will contain
-     other addresses. The contents of this field are usually copied by the
-     KDC into the caddr field of the resulting ticket.
-additional-tickets
-     Additional tickets may be optionally included in a request to the
-     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-     specified, then the session key from the additional ticket will be used
-     in place of the server's key to encrypt the new ticket. If more than
-     one option which requires additional tickets has been specified, then
-     the additional tickets are used in the order specified by the ordering
-     of the options bits (see kdc-options, above).
-
-The application code will be either ten (10) or twelve (12) depending on
-whether the request is for an initial ticket (AS-REQ) or for an additional
-ticket (TGS-REQ).
-
-The optional fields (addresses, authorization-data and additional-tickets)
-are only included if necessary to perform the operation specified in the
-kdc-options field.
-
-It should be noted that in KRB_TGS_REQ, the protocol version number appears
-twice and two different message types appear: the KRB_TGS_REQ message
-contains these fields as does the authentication header (KRB_AP_REQ) that is
-passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-The KRB_KDC_REP message format is used for the reply from the KDC for either
-an initial (AS) request or a subsequent (TGS) request. There is no message
-type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
-KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
-depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
-the client's secret key, and the client's key version number is included in
-the key version number for the encrypted data. For KRB_TGS_REP, the
-ciphertext is encrypted in the sub-session key from the Authenticator, or if
-absent, the session key from the ticket-granting ticket used in the request.
-In that case, no version number will be present in the EncryptedData
-sequence.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-The KRB_KDC_REP message contains the following fields:
-
-AS-REP ::=    [APPLICATION 11] KDC-REP
-TGS-REP ::=   [APPLICATION 13] KDC-REP
-
-KDC-REP ::=   SEQUENCE {
-              pvno[0]                    INTEGER,
-              msg-type[1]                INTEGER,
-              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
-              crealm[3]                  Realm,
-              cname[4]                   PrincipalName,
-              ticket[5]                  Ticket,
-              enc-part[6]                EncryptedData
-}
-
-EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
-EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
-
-EncKDCRepPart ::=   SEQUENCE {
-                    key[0]               EncryptionKey,
-                    last-req[1]          LastReq,
-                    nonce[2]             INTEGER,
-                    key-expiration[3]    KerberosTime OPTIONAL,
-                    flags[4]             TicketFlags,
-                    authtime[5]          KerberosTime,
-                    starttime[6]         KerberosTime OPTIONAL,
-                    endtime[7]           KerberosTime,
-                    renew-till[8]        KerberosTime OPTIONAL,
-                    srealm[9]            Realm,
-                    sname[10]            PrincipalName,
-                    caddr[11]            HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is either
-     KRB_AS_REP or KRB_TGS_REP.
-padata
-     This field is described in detail in section 5.4.1. One possible use
-     for this field is to encode an alternate "mix-in" string to be used
-     with a string-to-key algorithm (such as is described in section 6.3.2).
-     This ability is useful to ease transitions if a realm name needs to
-     change (e.g. when a company is acquired); in such a case all existing
-     password-derived entries in the KDC database would be flagged as
-     needing a special mix-in string until the next password change.
-crealm, cname, srealm and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-ticket
-     The newly-issued ticket, from section 5.3.1.
-enc-part
-     This field is a place holder for the ciphertext and related information
-     that forms the encrypted part of a message. The description of the
-     encrypted part of the message follows each appearance of this field.
-     The encrypted part is encoded as described in section 6.1.
-key
-     This field is the same as described for the ticket in section 5.3.1.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-last-req
-     This field is returned by the KDC and specifies the time(s) of the last
-     request by a principal. Depending on what information is available,
-     this might be the last time that a request for a ticket-granting ticket
-     was made, or the last time that a request based on a ticket-granting
-     ticket was successful. It also might cover all servers for a realm, or
-     just the particular server. Some implementations may display this
-     information to the user to aid in discovering unauthorized use of one's
-     identity. It is similar in spirit to the last login time displayed when
-     logging into timesharing systems.
-nonce
-     This field is described above in section 5.4.1.
-key-expiration
-     The key-expiration field is part of the response from the KDC and
-     specifies the time that the client's secret key is due to expire. The
-     expiration might be the result of password aging or an account
-     expiration. This field will usually be left out of the TGS reply since
-     the response to the TGS request is encrypted in a session key and no
-     client information need be retrieved from the KDC database. It is up to
-     the application client (usually the login program) to take appropriate
-     action (such as notifying the user) if the expiration time is imminent.
-flags, authtime, starttime, endtime, renew-till and caddr
-     These fields are duplicates of those found in the encrypted portion of
-     the attached ticket (see section 5.3.1), provided so the client may
-     verify they match the intended request and to assist in proper ticket
-     caching. If the message is of type KRB_TGS_REP, the caddr field will
-     only be filled in if the request was for a proxy or forwarded ticket,
-     or if the user is substituting a subset of the addresses from the
-     ticket granting ticket. If the client-requested addresses are not
-     present or not used, then the addresses contained in the ticket will be
-     the same as those included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-This section specifies the format of the messages used for the
-authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-The KRB_AP_REQ message contains the Kerberos protocol version number, the
-message type KRB_AP_REQ, an options field to indicate any options in use,
-and the ticket and authenticator themselves. The KRB_AP_REQ message is often
-referred to as the 'authentication header'.
-
-AP-REQ ::=      [APPLICATION 14] SEQUENCE {
-                pvno[0]                       INTEGER,
-                msg-type[1]                   INTEGER,
-                ap-options[2]                 APOptions,
-                ticket[3]                     Ticket,
-                authenticator[4]              EncryptedData
-}
-
-APOptions ::=   BIT STRING {
-                reserved(0),
-                use-session-key(1),
-                mutual-required(2)
-}
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REQ.
-ap-options
-     This field appears in the application request (KRB_AP_REQ) and affects
-     the way the request is processed. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). The encoding of the bits
-     is specified in section 5.2. The meanings of the options are:
-
-         Bit(s)   Name              Description
-
-         0        RESERVED
-                                    Reserved for future  expansion  of  this
-                                    field.
-
-         1        USE-SESSION-KEY
-                                    The  USE-SESSION-KEY  option   indicates
-                                    that the ticket the client is presenting
-                                    to a server is encrypted in the  session
-                                    key  from  the  server's ticket-granting
-                                    ticket.  When this option is not  speci-
-                                    fied,  the  ticket  is  encrypted in the
-                                    server's secret key.
-
-         2        MUTUAL-REQUIRED
-                                    The  MUTUAL-REQUIRED  option  tells  the
-                                    server  that  the client requires mutual
-                                    authentication, and that it must respond
-                                    with a KRB_AP_REP message.
-
-         3-31     RESERVED
-                                    Reserved for future use.
-
-ticket
- This field is a ticket authenticating the client to the server.
-authenticator
- This contains the authenticator, which includes the client's choice of
- a subkey. Its encoding is described in section 5.3.2.
-
-5.5.2. KRB_AP_REP definition
-
-The KRB_AP_REP message contains the Kerberos protocol version number, the
-message type, and an encrypted time- stamp. The message is sent in in
-response to an application request (KRB_AP_REQ) where the mutual
-authentication option has been selected in the ap-options field.
-
-AP-REP ::=         [APPLICATION 15] SEQUENCE {
-                   pvno[0]                           INTEGER,
-                   msg-type[1]                       INTEGER,
-                   enc-part[2]                       EncryptedData
-}
-
-EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
-                   ctime[0]                          KerberosTime,
-                   cusec[1]                          INTEGER,
-                   subkey[2]                         EncryptionKey OPTIONAL,
-                   seq-number[3]                     INTEGER OPTIONAL
-}
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-The encoded EncAPRepPart is encrypted in the shared session key of the
-ticket. The optional subkey field can be used in an application-arranged
-negotiation to choose a per association session key.
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REP.
-enc-part
-     This field is described above in section 5.4.2.
-ctime
-     This field contains the current time on the client's host.
-cusec
-     This field contains the microsecond part of the client's timestamp.
-subkey
-     This field contains an encryption key which is to be used to protect
-     this specific application session. See section 3.2.6 for specifics on
-     how this field is used to negotiate a key. Unless an application
-     specifies otherwise, if this field is left out, the sub-session key
-     from the authenticator, or if also left out, the session key from the
-     ticket will be used.
-
-5.5.3. Error message reply
-
-If an error occurs while processing the application request, the KRB_ERROR
-message will be sent in response. See section 5.9.1 for the format of the
-error message. The cname and crealm fields may be left out if the server
-cannot determine their appropriate values from the corresponding KRB_AP_REQ
-message. If the authenticator was decipherable, the ctime and cusec fields
-will contain the values from it.
-
-5.6. KRB_SAFE message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to send a tamper-proof message to
-its peer. It presumes that a session key has previously been exchanged (for
-example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-The KRB_SAFE message contains user data along with a collision-proof
-checksum keyed with the last encryption key negotiated via subkeys, or the
-session key if no negotiation has occured. The message fields are:
-
-KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
-                    pvno[0]                       INTEGER,
-                    msg-type[1]                   INTEGER,
-                    safe-body[2]                  KRB-SAFE-BODY,
-                    cksum[3]                      Checksum
-}
-
-KRB-SAFE-BODY ::=   SEQUENCE {
-                    user-data[0]                  OCTET STRING,
-                    timestamp[1]                  KerberosTime OPTIONAL,
-                    usec[2]                       INTEGER OPTIONAL,
-                    seq-number[3]                 INTEGER OPTIONAL,
-                    s-address[4]                  HostAddress OPTIONAL,
-                    r-address[5]                  HostAddress OPTIONAL
-}
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_SAFE.
-safe-body
-     This field is a placeholder for the body of the KRB-SAFE message.
-cksum
-     This field contains the checksum of the application data. Checksum
-     details are described in section 6.4. The checksum is computed over the
-     encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the
-     checksum is computed over the encoding of the KRB-SAFE sequence, then
-     the checksum is set to the result of that computation, and finally the
-     KRB-SAFE sequence is encoded again.
-user-data
-     This field is part of the KRB_SAFE and KRB_PRIV messages and contain
-     the application specific data that is being passed from the sender to
-     the recipient.
-timestamp
-     This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
-     are the current time as known by the sender of the message. By checking
-     the timestamp, the recipient of the message is able to make sure that
-     it was recently generated, and is not a replay.
-usec
-     This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
-     the microsecond part of the timestamp.
-seq-number
-     This field is described above in section 5.3.2.
-s-address
-     This field specifies the address in use by the sender of the message.
-     It may be omitted if not required by the application protocol. The
-     application designer considering omission of this field is warned, that
-     the inclusion of this address prevents some kinds of replay attacks
-     (e.g., reflection attacks) and that it is only acceptable to omit this
-     address if there is sufficient information in the integrity protected
-     part of the application message for the recipient to unambiguously
-     determine if it was the intended recipient.
-r-address
-     This field specifies the address in use by the recipient of the
-     message. It may be omitted for some uses (such as broadcast protocols),
-     but the recipient may arbitrarily reject such messages. This field
-     along with s-address can be used to help detect messages which have
-     been incorrectly or maliciously delivered to the wrong recipient.
-
-5.7. KRB_PRIV message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to securely and privately send a
-message to its peer. It presumes that a session key has previously been
-exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-The KRB_PRIV message contains user data encrypted in the Session Key. The
-message fields are:
-
-KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
-                     pvno[0]                           INTEGER,
-                     msg-type[1]                       INTEGER,
-                     enc-part[3]                       EncryptedData
-}
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
-                     user-data[0]        OCTET STRING,
-                     timestamp[1]        KerberosTime OPTIONAL,
-                     usec[2]             INTEGER OPTIONAL,
-                     seq-number[3]       INTEGER OPTIONAL,
-                     s-address[4]        HostAddress OPTIONAL, -- sender's
-addr
-                     r-address[5]        HostAddress OPTIONAL -- recip's
-addr
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_PRIV.
-enc-part
-     This field holds an encoding of the EncKrbPrivPart sequence encrypted
-     under the session key[32]. This encrypted encoding is used for the
-     enc-part field of the KRB-PRIV message. See section 6 for the format of
-     the ciphertext.
-user-data, timestamp, usec, s-address and r-address
-     These fields are described above in section 5.6.1.
-seq-number
-     This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-This section specifies the format of a message that can be used to send
-Kerberos credentials from one principal to another. It is presented here to
-encourage a common mechanism to be used by applications when forwarding
-tickets or providing proxies to subordinate servers. It presumes that a
-session key has already been exchanged perhaps by using the
-KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-The KRB_CRED message contains a sequence of tickets to be sent and
-information needed to use the tickets, including the session key from each.
-The information needed to use the tickets is encrypted under an encryption
-key previously exchanged or transferred alongside the KRB_CRED message. The
-message fields are:
-
-KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
-                 pvno[0]                INTEGER,
-                 msg-type[1]            INTEGER, -- KRB_CRED
-                 tickets[2]             SEQUENCE OF Ticket,
-                 enc-part[3]            EncryptedData
-}
-
-EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
-                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
-                 nonce[1]               INTEGER OPTIONAL,
-                 timestamp[2]           KerberosTime OPTIONAL,
-                 usec[3]                INTEGER OPTIONAL,
-                 s-address[4]           HostAddress OPTIONAL,
-                 r-address[5]           HostAddress OPTIONAL
-}
-
-KrbCredInfo      ::=                    SEQUENCE {
-                 key[0]                 EncryptionKey,
-                 prealm[1]              Realm OPTIONAL,
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                 pname[2]               PrincipalName OPTIONAL,
-                 flags[3]               TicketFlags OPTIONAL,
-                 authtime[4]            KerberosTime OPTIONAL,
-                 starttime[5]           KerberosTime OPTIONAL,
-                 endtime[6]             KerberosTime OPTIONAL
-                 renew-till[7]          KerberosTime OPTIONAL,
-                 srealm[8]              Realm OPTIONAL,
-                 sname[9]               PrincipalName OPTIONAL,
-                 caddr[10]              HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_CRED.
-tickets
-     These are the tickets obtained from the KDC specifically for use by the
-     intended recipient. Successive tickets are paired with the
-     corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
-     message.
-enc-part
-     This field holds an encoding of the EncKrbCredPart sequence encrypted
-     under the session key shared between the sender and the intended
-     recipient. This encrypted encoding is used for the enc-part field of
-     the KRB-CRED message. See section 6 for the format of the ciphertext.
-nonce
-     If practical, an application may require the inclusion of a nonce
-     generated by the recipient of the message. If the same value is
-     included as the nonce in the message, it provides evidence that the
-     message is fresh and has not been replayed by an attacker. A nonce must
-     never be re-used; it should be generated randomly by the recipient of
-     the message and provided to the sender of the message in an application
-     specific manner.
-timestamp and usec
-     These fields specify the time that the KRB-CRED message was generated.
-     The time is used to provide assurance that the message is fresh.
-s-address and r-address
-     These fields are described above in section 5.6.1. They are used
-     optionally to provide additional assurance of the integrity of the
-     KRB-CRED message.
-key
-     This field exists in the corresponding ticket passed by the KRB-CRED
-     message and is used to pass the session key from the sender to the
-     intended recipient. The field's encoding is described in section 6.2.
-
-The following fields are optional. If present, they can be associated with
-the credentials in the remote ticket file. If left out, then it is assumed
-that the recipient of the credentials already knows their value.
-
-prealm and pname
-     The name and realm of the delegated principal identity.
-flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
-     These fields contain the values of the correspond- ing fields from the
-     ticket found in the ticket field. Descriptions of the fields are
-     identical to the descriptions in the KDC-REP message.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-5.9. Error message specification
-
-This section specifies the format for the KRB_ERROR message. The fields
-included in the message are intended to return as much information as
-possible about an error. It is not expected that all the information
-required by the fields will be available for all types of errors. If the
-appropriate information is not available when the message is composed, the
-corresponding field will be left out of the message.
-
-Note that since the KRB_ERROR message is only optionally integrity
-protected, it is quite possible for an intruder to synthesize or modify such
-a message. In particular, this means that unless appropriate integrity
-protection mechanisms have been applied to the KRB_ERROR message, the client
-should not use any fields in this message for security-critical purposes,
-such as setting a system clock or generating a fresh authenticator. The
-message can be useful, however, for advising a user on the reason for some
-failure.
-
-5.9.1. KRB_ERROR definition
-
-The KRB_ERROR message consists of the following fields:
-
-KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
-                pvno[0]                       INTEGER,
-                msg-type[1]                   INTEGER,
-                ctime[2]                      KerberosTime OPTIONAL,
-                cusec[3]                      INTEGER OPTIONAL,
-                stime[4]                      KerberosTime,
-                susec[5]                      INTEGER,
-                error-code[6]                 INTEGER,
-                crealm[7]                     Realm OPTIONAL,
-                cname[8]                      PrincipalName OPTIONAL,
-                realm[9]                      Realm, -- Correct realm
-                sname[10]                     PrincipalName, -- Correct name
-                e-text[11]                    GeneralString OPTIONAL,
-                e-data[12]                    OCTET STRING OPTIONAL,
-                e-cksum[13]                   Checksum OPTIONAL,
-(*REMOVE7/14*)  e-typed-data[14]              SEQUENCE of ETypedData
-OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_ERROR.
-ctime
-     This field is described above in section 5.4.1.
-cusec
-     This field is described above in section 5.5.2.
-stime
-     This field contains the current time on the server. It is of type
-     KerberosTime.
-susec
-     This field contains the microsecond part of the server's timestamp. Its
-     value ranges from 0 to 999999. It appears along with stime. The two
-     fields are used in conjunction to specify a reasonably accurate
-     timestamp.
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-error-code
-     This field contains the error code returned by Kerberos or the server
-     when a request fails. To interpret the value of this field see the list
-     of error codes in section 8. Implementations are encouraged to provide
-     for national language support in the display of error messages.
-crealm, cname, srealm and sname
-     These fields are described above in section 5.3.1.
-e-text
-     This field contains additional text to help explain the error code
-     associated with the failed request (for example, it might include a
-     principal name which was unknown).
-e-data
-     This field contains additional data about the error for use by the
-     application to help it recover from or handle the error. If present,
-     this field will contain the encoding of a sequence of TypedData
-     (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED,
-     in which case it will contain the encoding of a sequence of of padata
-     fields (METHOD-DATA below), each corresponding to an acceptable
-     pre-authentication method and optionally containing data for the
-     method:
-
-     TYPED-DATA   ::=   SEQUENCE of TypeData
-     METHOD-DATA  ::=   SEQUENCE of PA-DATA
-
-     TypedData ::=   SEQUENCE {
-                         data-type[0]   INTEGER,
-                         data-value[1]  OCTET STRING OPTIONAL
-     }
-
-     Note that e-data-types have been reserved for all PA data types defined
-     prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when
-     using new PA data types defined in July 1999 or later, the METHOD-DATA
-     sequence must itself be encapsulated in an TypedData element of type
-     TD-PADATA. All new implementations interpreting the METHOD-DATA field
-     for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of
-     TD-PADATA, extract the typed data field and interpret the use any
-     elements encapsulated in the TD-PADATA elements as if they were present
-     in the METHOD-DATA sequence.
-e-cksum
-     This field contains an optional checksum for the KRB-ERROR message. The
-     checksum is calculated over the Kerberos ASN.1 encoding of the
-     KRB-ERROR message with the checksum absent. The checksum is then added
-     to the KRB-ERROR structure and the message is re-encoded. The Checksum
-     should be calculated using the session key from the ticket granting
-     ticket or service ticket, where available. If the error is in response
-     to a TGS or AP request, the checksum should be calculated uing the the
-     session key from the client's ticket. If the error is in response to an
-     AS request, then the checksum should be calulated using the client's
-     secret key ONLY if there has been suitable preauthentication to prove
-     knowledge of the secret key by the client[33]. If a checksum can not be
-     computed because the key to be used is not available, no checksum will
-     be included.
-e-typed-data
-     [***Will be deleted 7/14***] This field contains optional data that may
-     be used to help the client recover from the indicated error. [This
-     could contain the METHOD-DATA specified since I don't think anyone
-     actually uses it yet. It could also contain the PA-DATA sequence for
-     the preauth required error if we had a clear way to transition to the
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-     use of this field from the use of the untyped e-data field.] For
-     example, this field may specify the key version of the key used to
-     verify preauthentication:
-
-     e-data-type  := 20 -- Key version number
-     e-data-value := Integer -- Key version number used to
-                      verify preauthentication
-
-6. Encryption and Checksum Specifications
-
-The Kerberos protocols described in this document are designed to use stream
-encryption ciphers, which can be simulated using commonly available block
-encryption ciphers, such as the Data Encryption Standard, [DES77] in
-conjunction with block chaining and checksum methods [DESM80]. Encryption is
-used to prove the identities of the network entities participating in
-message exchanges. The Key Distribution Center for each realm is trusted by
-all principals registered in that realm to store a secret key in confidence.
-Proof of knowledge of this secret key is used to verify the authenticity of
-a principal. [*** Discussion above will change to use 3DES as example
-7/14/99 ***]
-
-The KDC uses the principal's secret key (in the AS exchange) or a shared
-session key (in the TGS exchange) to encrypt responses to ticket requests;
-the ability to obtain the secret key or session key implies the knowledge of
-the appropriate keys and the identity of the KDC. The ability of a principal
-to decrypt the KDC response and present a Ticket and a properly formed
-Authenticator (generated with the session key from the KDC response) to a
-service verifies the identity of the principal; likewise the ability of the
-service to extract the session key from the Ticket and prove its knowledge
-thereof in a response verifies the identity of the service.
-
-The Kerberos protocols generally assume that the encryption used is secure
-from cryptanalysis; however, in some cases, the order of fields in the
-encrypted portions of messages are arranged to minimize the effects of
-poorly chosen keys. It is still important to choose good keys. If keys are
-derived from user-typed passwords, those passwords need to be well chosen to
-make brute force attacks more difficult. Poorly chosen keys still make easy
-targets for intruders.
-
-The following sections specify the encryption and checksum mechanisms
-currently defined for Kerberos. The encodings, chaining, and padding
-requirements for each are described. For encryption methods, it is often
-desirable to place random information (often referred to as a confounder) at
-the start of the message. The requirements for a confounder are specified
-with each encryption mechanism.
-
-Some encryption systems use a block-chaining method to improve the the
-security characteristics of the ciphertext. However, these chaining methods
-often don't provide an integrity check upon decryption. Such systems (such
-as DES in CBC mode) must be augmented with a checksum of the plain-text
-which can be verified at decryption and used to detect any tampering or
-damage. Such checksums should be good at detecting burst errors in the
-input. If any damage is detected, the decryption routine is expected to
-return an error indicating the failure of an integrity check. Each
-encryption type is expected to provide and verify an appropriate checksum.
-The specification of each encryption method sets out its checksum
-requirements.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-Finally, where a key is to be derived from a user's password, an algorithm
-for converting the password to a key of the appropriate type is included. It
-is desirable for the string to key function to be one-way, and for the
-mapping to be different in different realms. This is important because users
-who are registered in more than one realm will often use the same password
-in each, and it is desirable that an attacker compromising the Kerberos
-server in one realm not obtain or derive the user's key in another.
-
-For an discussion of the integrity characteristics of the candidate
-encryption and checksum methods considered for Kerberos, the reader is
-referred to [SG92].
-
-6.1. Encryption Specifications
-
-The following ASN.1 definition describes all encrypted messages. The
-enc-part field which appears in the unencrypted part of messages in section
-5 is a sequence consisting of an encryption type, an optional key version
-number, and the ciphertext.
-
-EncryptedData ::=   SEQUENCE {
-                    etype[0]     INTEGER, -- EncryptionType
-                    kvno[1]      INTEGER OPTIONAL,
-                    cipher[2]    OCTET STRING -- ciphertext
-}
-
-etype
-     This field identifies which encryption algorithm was used to encipher
-     the cipher. Detailed specifications for selected encryption types
-     appear later in this section.
-kvno
-     This field contains the version number of the key under which data is
-     encrypted. It is only present in messages encrypted under long lasting
-     keys, such as principals' secret keys.
-cipher
-     This field contains the enciphered text, encoded as an OCTET STRING.
-
-The cipher field is generated by applying the specified encryption algorithm
-to data composed of the message and algorithm-specific inputs. Encryption
-mechanisms defined for use with Kerberos must take sufficient measures to
-guarantee the integrity of the plaintext, and we recommend they also take
-measures to protect against precomputed dictionary attacks. If the
-encryption algorithm is not itself capable of doing so, the protections can
-often be enhanced by adding a checksum and a confounder.
-
-The suggested format for the data to be encrypted includes a confounder, a
-checksum, the encoded plaintext, and any necessary padding. The msg-seq
-field contains the part of the protocol message described in section 5 which
-is to be encrypted. The confounder, checksum, and padding are all untagged
-and untyped, and their length is exactly sufficient to hold the appropriate
-item. The type and length is implicit and specified by the particular
-encryption type being used (etype). The format for the data to be encrypted
-is described in the following diagram:
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-      +-----------+----------+-------------+-----+
-      |confounder |   check  |   msg-seq   | pad |
-      +-----------+----------+-------------+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-CipherText ::=   ENCRYPTED       SEQUENCE {
-            confounder[0]   UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
-            check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
-            msg-seq[2]      MsgSequence,
-            pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
-}
-
-One generates a random confounder of the appropriate length, placing it in
-confounder; zeroes out check; calculates the appropriate checksum over
-confounder, check, and msg-seq, placing the result in check; adds the
-necessary padding; then encrypts using the specified encryption type and the
-appropriate key.
-
-Unless otherwise specified, a definition of an encryption algorithm that
-specifies a checksum, a length for the confounder field, or an octet
-boundary for padding uses this ciphertext format[36]. Those fields which are
-not specified will be omitted.
-
-In the interest of allowing all implementations using a particular
-encryption type to communicate with all others using that type, the
-specification of an encryption type defines any checksum that is needed as
-part of the encryption process. If an alternative checksum is to be used, a
-new encryption type must be defined.
-
-Some cryptosystems require additional information beyond the key and the
-data to be encrypted. For example, DES, when used in cipher-block-chaining
-mode, requires an initialization vector. If required, the description for
-each encryption type must specify the source of such additional information.
-6.2. Encryption Keys
-
-The sequence below shows the encoding of an encryption key:
-
-       EncryptionKey ::=   SEQUENCE {
-                           keytype[0]    INTEGER,
-                           keyvalue[1]   OCTET STRING
-       }
-
-keytype
-     This field specifies the type of encryption that is to be performed
-     using the key that follows in the keyvalue field. It will always
-     correspond to the etype to be used to generate or decode the
-     EncryptedData. In cases when multiple algorithms use a common kind of
-     key (e.g., if the encryption algorithm uses an alternate checksum
-     algorithm for an integrity check, or a different chaining mechanism),
-     the keytype provides information needed to determine which algorithm is
-     to be used.
-keyvalue
-     This field contains the key itself, encoded as an octet string.
-
-All negative values for the encryption key type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpreta- tions.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-6.3. Encryption Systems
-
-6.3.1. The NULL Encryption System (null)
-
-If no encryption is in use, the encryption system is said to be the NULL
-encryption system. In the NULL encryption system there is no checksum,
-confounder or padding. The ciphertext is simply the plaintext. The NULL Key
-is used by the null encryption system and is zero octets in length, with
-keytype zero (0).
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-The des-cbc-crc encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A
-CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the
-confounder and message sequence (msg-seq) and placed in the cksum field. DES
-blocks are 8 bytes. As a result, the data to be encrypted (the concatenation
-of confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption. The details of the encryption of this data are identical
-to those for the des-cbc-md5 encryption mode.
-
-Note that, since the CRC-32 checksum is not collision-proof, an attacker
-could use a probabilistic chosen-plaintext attack to generate a valid
-message even if a confounder is used [SG92]. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat. The use of the CRC-32 as the checksum for ticket or
-authenticator is no longer mandated as an interoperability requirement for
-Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-The des-cbc-md4 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD4 checksum (described in [MD492]) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption. The details of the encryption of this data are identical
-to those for the des-cbc-md5 encryption mode.
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-The des-cbc-md5 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD5 checksum (described in [MD5-92].) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption.
-
-Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are
-concatenated to make the 64-bit inputs for the DES algorithms. The first
-octet supplies the 8 most significant bits (with the octet's MSbit used as
-the DES input block's MSbit, etc.), the second octet the next 8 bits, ...,
-and the eighth octet supplies the 8 least significant bits.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-Encryption under DES using cipher block chaining requires an additional
-input in the form of an initialization vector. Unless otherwise specified,
-zero should be used as the initialization vector. Kerberos' use of DES
-requires an 8 octet confounder.
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for encrypting messages for use in Kerberos. Additionally,
-because of the way that keys are derived for the encryption of checksums,
-keys shall not be used that yield 'weak' or 'semi-weak' keys when
-eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0.
-
-A DES key is 8 octets of data, with keytype one (1). This consists of 56
-bits of key, and 8 parity bits (one per octet). The key is encoded as a
-series of 8 octets written in MSB-first order. The bits within the key are
-also encoded in MSB order. For example, if the encryption key is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity
-bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the
-MSbit). [See the FIPS 81 introduction for reference.]
-
-String to key transformation
-
-To generate a DES key from a text string (password), a "salt" is
-concatenated to the text string, and then padded with ASCII nulls to an 8
-byte boundary. This "salt" is normally the realm and each component of the
-principal's name appended. However, sometimes different salts are used ---
-for example, when a realm is renamed, or if a user changes her username, or
-for compatibility with Kerberos V4 (whose string-to-key algorithm uses a
-null string for the salt). This string is then fan-folded and eXclusive-ORed
-with itself to form an 8 byte DES key. Before eXclusive-ORing a block, every
-byte is shifted one bit to the left to leave the lowest bit zero. The key is
-the "corrected" by correcting the parity on the key, and if the key matches
-a 'weak' or 'semi-weak' key as described in the DES specification, it is
-eXclusive-ORed with the constant 00000000000000F0. This key is then used to
-generate a DES CBC checksum on the initial string (with the salt appended).
-The result of the CBC checksum is the "corrected" as described above to form
-the result which is return as the key. Pseudocode follows:
-
-     name_to_default_salt(realm, name) {
-          s = realm
-          for(each component in name) {
-               s = s + component;
-          }
-          return s;
-     }
-
-     key_correction(key) {
-          fixparity(key);
-          if (is_weak_key_key(key))
-               key = key XOR 0xF0;
-          return(key);
-     }
-
-     string_to_key(string,salt) {
-
-          odd = 1;
-          s = string + salt;
-          tempkey = NULL;
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-          pad(s); /* with nulls to 8 byte boundary */
-          for(8byteblock in s) {
-               if(odd == 0)  {
-                   odd = 1;
-                   reverse(8byteblock)
-               }
-               else odd = 0;
-               left shift every byte in 8byteblock one bit;
-               tempkey = tempkey XOR 8byteblock;
-          }
-          tempkey = key_correction(tempkey);
-          key = key_correction(DES-CBC-check(s,tempkey));
-          return(key);
-     }
-
-6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with Key
-Derivation [Horowitz]
-
-[*** Note that there are several 3DES varients in use in different Kerberos
-implemenations, updates to this section will be sent to the cat list and
-krb-protocol list prior to the Oslo IETF, including the key derivation and
-non-key derivation varients ***] NOTE: This description currently refers to
-documents, the contents of which might be bettered included by value in this
-spec. The description below was provided by Marc Horowitz, and the form in
-which it will finally appear is yet to be determined. This description is
-included in this version of the draft because it does describe the
-implemenation ready for use with the MIT implementation. Note also that the
-encryption identifier has been left unspecified here because the value from
-Marc Horowitz's spec conflicted with some other impmenentations implemented
-based on perevious versions of the specification.
-
-This encryption type is based on the Triple DES cryptosystem, the HMAC-SHA1
-[Krawczyk96] message authentication algorithm, and key derivation for
-Kerberos V5 [HorowitzB96].
-
-The des3-cbc-hmac-sha1 encryption type has been assigned the value ??. The
-hmac-sha1-des3 checksum type has been assigned the value 12.
-
-Encryption Type des3-cbc-hmac-sha1
-
-EncryptedData using this type must be generated as described in
-[Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. The
-keyed hash algorithm is HMAC-SHA1. Unless otherwise specified, a zero IV
-must be used. If the length of the input data is not a multiple of the block
-size, zero octets must be used to pad the plaintext to the next eight-octet
-boundary. The counfounder must be eight random octets (one block).
-
-Checksum Type hmac-sha1-des3
-
-Checksums using this type must be generated as described in [Horowitz96].
-The keyed hash algorithm is HMAC-SHA1.
-
-Common Requirements
-
-The EncryptionKey value is 24 octets long. The 7 most significant bits of
-each octet contain key bits, and the least significant bit is the inverse of
-the xor of the key bits.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-For the purposes of key derivation, the block size is 64 bits, and the key
-size is 168 bits. The 168 bits output by key derivation are converted to an
-EncryptionKey value as follows. First, the 168 bits are divided into three
-groups of 56 bits, which are expanded individually into 64 bits as follows:
-
- 1  2  3  4  5  6  7  p
- 9 10 11 12 13 14 15  p
-17 18 19 20 21 22 23  p
-25 26 27 28 29 30 31  p
-33 34 35 36 37 38 39  p
-41 42 43 44 45 46 47  p
-49 50 51 52 53 54 55  p
-56 48 40 32 24 16  8  p
-
-The "p" bits are parity bits computed over the data bits. The output of the
-three expansions are concatenated to form the EncryptionKey value.
-
-When the HMAC-SHA1 of a string is computed, the key is used in the
-EncryptedKey form.
-
-Key Derivation
-
-In the Kerberos protocol, cryptographic keys are used in a number of places.
-In order to minimize the effect of compromising a key, it is desirable to
-use a different key for each of these places. Key derivation [Horowitz96]
-can be used to construct different keys for each operation from the keys
-transported on the network. For this to be possible, a small change to the
-specification is necessary.
-
-This section specifies a profile for the use of key derivation [Horowitz96]
-with Kerberos. For each place where a key is used, a ``key usage'' must is
-specified for that purpose. The key, key usage, and encryption/checksum type
-together describe the transformation from plaintext to ciphertext, or
-plaintext to checksum.
-
-Key Usage Values
-
-This is a complete list of places keys are used in the kerberos protocol,
-with key usage values and RFC 1510 section numbers:
-
- 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
-    client key (section 5.4.1)
- 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
-    application session key), encrypted with the service key
-    (section 5.4.2)
- 3. AS-REP encrypted part (includes tgs session key or application
-    session key), encrypted with the client key (section 5.4.2)
- 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-    session key (section 5.4.1)
- 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-    authenticator subkey (section 5.4.1)
- 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
-    with the tgs session key (sections 5.3.2, 5.4.1)
- 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
-    authenticator subkey), encrypted with the tgs session key
-    (section 5.3.2)
- 8. TGS-REP encrypted part (includes application session key),
-    encrypted with the tgs session key (section 5.4.2)
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
- 9. TGS-REP encrypted part (includes application session key),
-    encrypted with the tgs authenticator subkey (section 5.4.2)
-10. AP-REQ Authenticator cksum, keyed with the application session
-    key (section 5.3.2)
-11. AP-REQ Authenticator (includes application authenticator
-    subkey), encrypted with the application session key (section
-    5.3.2)
-12. AP-REP encrypted part (includes application session subkey),
-    encrypted with the application session key (section 5.5.2)
-13. KRB-PRIV encrypted part, encrypted with a key chosen by the
-    application (section 5.7.1)
-14. KRB-CRED encrypted part, encrypted with a key chosen by the
-    application (section 5.6.1)
-15. KRB-SAVE cksum, keyed with a key chosen by the application
-    (section 5.8.1)
-18. KRB-ERROR checksum (e-cksum in section 5.9.1)
-19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
-20. Checksum for Mandatory Ticket Extensions (appendix B.6)
-21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
-
-Key usage values between 1024 and 2047 (inclusive) are reserved for
-application use. Applications should use even values for encryption and odd
-values for checksums within this range.
-
-A few of these key usages need a little clarification. A service which
-receives an AP-REQ has no way to know if the enclosed Ticket was part of an
-AS-REP or TGS-REP. Therefore, key usage 2 must always be used for generating
-a Ticket, whether it is in response to an AS- REQ or TGS-REQ.
-
-There might exist other documents which define protocols in terms of the
-RFC1510 encryption types or checksum types. Such documents would not know
-about key usages. In order that these documents continue to be meaningful
-until they are updated, key usages 1024 and 1025 must be used to derive keys
-for encryption and checksums, respectively. New protocols defined in terms
-of the Kerberos encryption and checksum types should use their own key
-usages. Key usages may be registered with IANA to avoid conflicts. Key
-usages must be unsigned 32 bit integers. Zero is not permitted.
-
-Defining Cryptosystems Using Key Derivation
-
-Kerberos requires that the ciphertext component of EncryptedData be
-tamper-resistant as well as confidential. This implies encryption and
-integrity functions, which must each use their own separate keys. So, for
-each key usage, two keys must be generated, one for encryption (Ke), and one
-for integrity (Ki):
-
-      Ke = DK(protocol key, key usage | 0xAA)
-      Ki = DK(protocol key, key usage | 0x55)
-
-where the protocol key is from the EncryptionKey from the wire protocol, and
-the key usage is represented as a 32 bit integer in network byte order. The
-ciphertest must be generated from the plaintext as follows:
-
-   ciphertext = E(Ke, confounder | plaintext | padding) |
-                H(Ki, confounder | plaintext | padding)
-
-The confounder and padding are specific to the encryption algorithm E.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-When generating a checksum only, there is no need for a confounder or
-padding. Again, a new key (Kc) must be used. Checksums must be generated
-from the plaintext as follows:
-
-      Kc = DK(protocol key, key usage | 0x99)
-
-      MAC = H(Kc, plaintext)
-
-Note that each enctype is described by an encryption algorithm E and a keyed
-hash algorithm H, and each checksum type is described by a keyed hash
-algorithm H. HMAC, with an appropriate hash, is recommended for use as H.
-
-Key Derivation from Passwords
-
-The well-known constant for password key derivation must be the byte string
-{0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the
-ASCII encoding for the string "kerberos".
-
-6.4. Checksums
-
-The following is the ASN.1 definition used for a checksum:
-
-         Checksum ::=   SEQUENCE {
-                        cksumtype[0]   INTEGER,
-                        checksum[1]    OCTET STRING
-         }
-
-cksumtype
-     This field indicates the algorithm used to generate the accompanying
-     checksum.
-checksum
-     This field contains the checksum itself, encoded as an octet string.
-
-Detailed specification of selected checksum types appear later in this
-section. Negative values for the checksum type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpretations.
-
-Checksums used by Kerberos can be classified by two properties: whether they
-are collision-proof, and whether they are keyed. It is infeasible to find
-two plaintexts which generate the same checksum value for a collision-proof
-checksum. A key is required to perturb or initialize the algorithm in a
-keyed checksum. To prevent message-stream modification by an active
-attacker, unkeyed checksums should only be used when the checksum and
-message will be subsequently encrypted (e.g. the checksums defined as part
-of the encryption algorithms covered earlier in this section).
-
-Collision-proof checksums can be made tamper-proof if the checksum value is
-encrypted before inclusion in a message. In such cases, the composition of
-the checksum and the encryption algorithm must be considered a separate
-checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum
-algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the
-encrypted forms of unkeyed collision-proof checksums, Kerberos prepends a
-confounder before the checksum is calculated.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-6.4.1. The CRC-32 Checksum (crc32)
-
-The CRC-32 checksum calculates a checksum based on a cyclic redundancy check
-as described in ISO 3309 [ISO3309]. The resulting checksum is four (4)
-octets in length. The CRC-32 is neither keyed nor collision-proof. The use
-of this checksum is not recommended. An attacker using a probabilistic
-chosen-plaintext attack as described in [SG92] might be able to generate an
-alternative message that satisfies the checksum. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat.
-
-6.4.2. The RSA MD4 Checksum (rsa-md4)
-
-The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
-[MD4-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to
-be collision-proof.
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
-
-The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD4
-checksum algorithm, and encrypting the confounder and the checksum using DES
-in cipher-block-chaining (CBC) mode using a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the constant
-F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The
-resulting checksum is 24 octets long (8 octets of which are redundant). This
-checksum is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some weak keys' and 'semi-weak keys'; those
-keys shall not be used for generating RSA-MD4 checksums for use in Kerberos.
-
-The format for the checksum is described in the follow- ing diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-6.4.4. The RSA MD5 Checksum (rsa-md5)
-
-The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm.
-[MD5-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to
-be collision-proof.
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
-
-The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD5
-checksum algorithm, and encrypting the confounder and the checksum using DES
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-in cipher-block-chaining (CBC) mode using a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the hexadecimal constant
-F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
-checksum is 24 octets long (8 octets of which are redundant). This checksum
-is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some 'weak keys' and 'semi-weak keys'; those
-keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-The DES-MAC checksum is computed by prepending an 8 octet confounder to the
-plaintext, performing a DES CBC-mode encryption on the result using the key
-and an initialization vector of zero, taking the last block of the
-ciphertext, prepending the same confounder and encrypting the pair using DES
-in cipher-block-chaining (CBC) mode using a a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the hexadecimal constant
-F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
-checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This
-checksum is tamper-proof and collision-proof.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-|   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                       confounder[0]   UNTAGGED OCTET STRING(8),
-                       check[1]        UNTAGGED OCTET STRING(8)
-}
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for generating DES-MAC checksums for use in Kerberos, nor
-shall a key be used whose variant is 'weak' or 'semi-weak'.
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k)
-
-The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by
-applying the RSA MD4 checksum algorithm and encrypting the results using DES
-in cipher-block-chaining (CBC) mode using a DES key as both key and
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-initialization vector. The resulting checksum is 16 octets long. This
-checksum is tamper-proof and believed to be collision-proof. Note that this
-checksum type is the old method for encoding the RSA-MD4-DES checksum and it
-is no longer recommended.
-
-6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
-
-The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption
-of the plaintext, and using the last block of the ciphertext as the checksum
-value. It is keyed with an encryption key and an initialization vector; any
-uses which do not specify an additional initialization vector will use the
-key as both key and initialization vector. The resulting checksum is 64 bits
-(8 octets) long. This checksum is tamper-proof and collision-proof. Note
-that this checksum type is the old method for encoding the DES-MAC checksum
-and it is no longer recommended. The DES specifications identify some 'weak
-keys' and 'semi-weak keys'; those keys shall not be used for generating
-DES-MAC checksums for use in Kerberos.
-
-7. Naming Constraints
-
-7.1. Realm Names
-
-Although realm names are encoded as GeneralStrings and although a realm can
-technically select any name it chooses, interoperability across realm
-boundaries requires agreement on how realm names are to be assigned, and
-what information they imply.
-
-To enforce these conventions, each realm must conform to the conventions
-itself, and it must require that any realms with which inter-realm keys are
-shared also conform to the conventions and require the same from its
-neighbors.
-
-Kerberos realm names are case sensitive. Realm names that differ only in the
-case of the characters are not equivalent. There are presently four styles
-of realm names: domain, X500, other, and reserved. Examples of each style
-follow:
-
-     domain:   ATHENA.MIT.EDU (example)
-       X500:   C=US/O=OSF (example)
-      other:   NAMETYPE:rest/of.name=without-restrictions (example)
-   reserved:   reserved, but will not conflict with above
-
-Domain names must look like domain names: they consist of components
-separated by periods (.) and they contain neither colons (:) nor slashes
-(/). Domain names must be converted to upper case when used as realm names.
-
-X.500 names contain an equal (=) and cannot contain a colon (:) before the
-equal. The realm names for X.500 names will be string representations of the
-names with components separated by slashes. Leading and trailing slashes
-will not be included.
-
-Names that fall into the other category must begin with a prefix that
-contains no equal (=) or period (.) and the prefix must be followed by a
-colon (:) and the rest of the name. All prefixes must be assigned before
-they may be used. Presently none are assigned.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-The reserved category includes strings which do not fall into the first
-three categories. All names in this category are reserved. It is unlikely
-that names will be assigned to this category unless there is a very strong
-argument for not using the 'other' category.
-
-These rules guarantee that there will be no conflicts between the various
-name styles. The following additional constraints apply to the assignment of
-realm names in the domain and X.500 categories: the name of a realm for the
-domain or X.500 formats must either be used by the organization owning (to
-whom it was assigned) an Internet domain name or X.500 name, or in the case
-that no such names are registered, authority to use a realm name may be
-derived from the authority of the parent realm. For example, if there is no
-domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
-authorize the creation of a realm with that name.
-
-This is acceptable because the organization to which the parent is assigned
-is presumably the organization authorized to assign names to its children in
-the X.500 and domain name systems as well. If the parent assigns a realm
-name without also registering it in the domain name or X.500 hierarchy, it
-is the parent's responsibility to make sure that there will not in the
-future exists a name identical to the realm name of the child unless it is
-assigned to the same entity as the realm name.
-
-7.2. Principal Names
-
-As was the case for realm names, conventions are needed to ensure that all
-agree on what information is implied by a principal name. The name-type
-field that is part of the principal name indicates the kind of information
-implied by the name. The name-type should be treated as a hint. Ignoring the
-name type, no two names can be the same (i.e. at least one of the
-components, or the realm, must be different). The following name types are
-defined:
-
-  name-type      value   meaning
-
-   NT-UNKNOWN        0   Name type not known
-   NT-PRINCIPAL      1   General principal name (e.g. username, or DCE
-principal)
-   NT-SRV-INST       2   Service and other unique instance (krbtgt)
-   NT-SRV-HST        3   Service with host name as instance (telnet,
-rcommands)
-   NT-SRV-XHST       4   Service with slash-separated host name components
-   NT-UID            5   Unique ID
-   NT-X500-PRINCIPAL 6   Encoded X.509 Distingished name [RFC 1779]
-
-When a name implies no information other than its uniqueness at a particular
-time the name type PRINCIPAL should be used. The principal name type should
-be used for users, and it might also be used for a unique server. If the
-name is a unique machine generated ID that is guaranteed never to be
-reassigned then the name type of UID should be used (note that it is
-generally a bad idea to reassign names of any type since stale entries might
-remain in access control lists).
-
-If the first component of a name identifies a service and the remaining
-components identify an instance of the service in a server specified manner,
-then the name type of SRV-INST should be used. An example of this name type
-is the Kerberos ticket-granting service whose name has a first component of
-krbtgt and a second component identifying the realm for which the ticket is
-valid.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-If instance is a single component following the service name and the
-instance identifies the host on which the server is running, then the name
-type SRV-HST should be used. This type is typically used for Internet
-services such as telnet and the Berkeley R commands. If the separate
-components of the host name appear as successive components following the
-name of the service, then the name type SRV-XHST should be used. This type
-might be used to identify servers on hosts with X.500 names where the slash
-(/) might otherwise be ambiguous.
-
-A name type of NT-X500-PRINCIPAL should be used when a name from an X.509
-certificiate is translated into a Kerberos name. The encoding of the X.509
-name as a Kerberos principal shall conform to the encoding rules specified
-in RFC 2253.
-
-A name type of UNKNOWN should be used when the form of the name is not
-known. When comparing names, a name of type UNKNOWN will match principals
-authenticated with names of any type. A principal authenticated with a name
-of type UNKNOWN, however, will only match other names of type UNKNOWN.
-
-Names of any type with an initial component of 'krbtgt' are reserved for the
-Kerberos ticket granting service. See section 8.2.3 for the form of such
-names.
-
-7.2.1. Name of server principals
-
-The principal identifier for a server on a host will generally be composed
-of two parts: (1) the realm of the KDC with which the server is registered,
-and (2) a two-component name of type NT-SRV-HST if the host name is an
-Internet domain name or a multi-component name of type NT-SRV-XHST if the
-name of the host is of a form such as X.500 that allows slash (/)
-separators. The first component of the two- or multi-component name will
-identify the service and the latter components will identify the host. Where
-the name of the host is not case sensitive (for example, with Internet
-domain names) the name of the host must be lower case. If specified by the
-application protocol for services such as telnet and the Berkeley R commands
-which run with system privileges, the first component may be the string
-'host' instead of a service specific identifier. When a host has an official
-name and one or more aliases, the official name of the host must be used
-when constructing the name of the server principal.
-
-8. Constants and other defined values
-
-8.1. Host address types
-
-All negative values for the host address type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpretations.
-
-The values of the types for the following addresses are chosen to match the
-defined address family constants in the Berkeley Standard Distributions of
-Unix. They can be found in with symbolic names AF_xxx (where xxx is an
-abbreviation of the address family name).
-
-Internet (IPv4) Addresses
-
-Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB
-order. The type of IPv4 addresses is two (2).
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-Internet (IPv6) Addresses [Westerlund]
-
-IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
-type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The
-following addresses (see [RFC1884]) MUST not appear in any Kerberos packet:
-
-   * the Unspecified Address
-   * the Loopback Address
-   * Link-Local addresses
-
-IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-CHAOSnet addresses
-
-CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order.
-The type of CHAOSnet addresses is five (5).
-
-ISO addresses
-
-ISO addresses are variable-length. The type of ISO addresses is seven (7).
-
-Xerox Network Services (XNS) addresses
-
-XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The
-type of XNS addresses is six (6).
-
-AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network
-number. The first octet of the address is the node number; the remaining two
-octets encode the network number in MSB order. The type of AppleTalk DDP
-addresses is sixteen (16).
-
-DECnet Phase IV addresses
-
-DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The
-type of DECnet Phase IV addresses is twelve (12).
-
-Netbios addresses
-
-Netbios addresses are 16-octet addresses typically composed of 1 to 15
-characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0.
-The type of Netbios addresses is 20 (0x14).
-
-8.2. KDC messages
-
-8.2.1. UDP/IP transport
-
-When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP
-IP transport, the client shall send a UDP datagram containing only an
-encoding of the request to port 88 (decimal) at the KDC's IP address; the
-KDC will respond with a reply datagram containing only an encoding of the
-reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at
-the sender's IP address. Kerberos servers supporting IP transport must
-accept UDP requests on port 88 (decimal). The response to a request made
-through UDP/IP transport must also use UDP/IP transport.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-8.2.2. TCP/IP transport [Westerlund,Danielsson]
-
-Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) and
-clients should support the sending of TCP requests on port 88 (decimal).
-When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new
-connection will be established for each authentication exchange (request and
-response). The KRB_KDC_REP or KRB_ERROR message will be returned to the
-client on the same TCP stream that was established for the request. The
-response to a request made through TCP/IP transport must also use TCP/IP
-transport. Implementors should note that some extentions to the Kerberos
-protocol will not work if any implementation not supporting the TCP
-transport is involved (client or KDC). Implementors are strongly urged to
-support the TCP transport on both the client and server and are advised that
-the current notation of "should" support will likely change in the future to
-must support. The KDC may close the TCP stream after sending a response, but
-may leave the stream open if it expects a followup - in which case it may
-close the stream at any time if resource constratints or other factors make
-it desirable to do so. Care must be taken in managing TCP/IP connections
-with the KDC to prevent denial of service attacks based on the number of
-TCP/IP connections with the KDC that remain open. If multiple exchanges with
-the KDC are needed for certain forms of preauthentication, multiple TCP
-connections may be required. A client may close the stream after receiving
-response, and should close the stream if it does not expect to send followup
-messages. The client must be prepared to have the stream closed by the KDC
-at anytime, in which case it must simply connect again when it is ready to
-send subsequent messages.
-
-The first four octets of the TCP stream used to transmit the request request
-will encode in network byte order the length of the request (KRB_KDC_REQ),
-and the length will be followed by the request itself. The response will
-similarly be preceeded by a 4 octet encoding in network byte order of the
-length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by
-the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is set on the
-integer represented by the first 4 octets, then the next 4 octets will be
-read, extending the length of the field by another 4 octets (less the sign
-bit which is reserved for future expansion).
-
-8.2.3. OSI transport
-
-During authentication of an OSI client to an OSI server, the mutual
-authentication of an OSI server to an OSI client, the transfer of
-credentials from an OSI client to an OSI server, or during exchange of
-private or integrity checked messages, Kerberos protocol messages may be
-treated as opaque objects and the type of the authentication mechanism will
-be:
-
-OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1),
-                      security(5),kerberosv5(2)}
-
-Depending on the situation, the opaque object will be an authentication
-header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message
-(KRB_SAFE), a private message (KRB_PRIV), or a credentials message
-(KRB_CRED). The opaque data contains an application code as specified in the
-ASN.1 description for each message. The application code may be used by
-Kerberos to determine the message type.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-8.2.3. Name of the TGS
-
-The principal identifier of the ticket-granting service shall be composed of
-three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part
-name of type NT-SRV-INST, with the first part "krbtgt" and the second part
-the name of the realm which will accept the ticket-granting ticket. For
-example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be
-used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier
-of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A
-ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get
-tickets from the MIT.EDU realm has a principal identifier of
-"ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name).
-
-8.3. Protocol constants and associated values
-
-The following tables list constants used in the protocol and defines their
-meanings. Ranges are specified in the "specification" section that limit the
-values of constants for which values are defined here. This allows
-implementations to make assumptions about the maximum values that will be
-received for these constants. Implementation receiving values outside the
-range specified in the "specification" section may reject the request, but
-they must recover cleanly.
-
-Encryption type       etype value block size  minimum pad size  confounder
-size
-NULL                           0     1           0                 0
-des-cbc-crc                    1     8           4                 8
-des-cbc-md4                    2     8           0                 8
-des-cbc-md5                    3     8           0                 8
-                     4
-des3-cbc-md5                   5     8           0                 8
-                     6
-des3-cbc-sha1                  7     8           0                 8
-sign-dsa-generate              8
-(old-pkinit-will-remove)
-dsaWithSHA1-CmsOID             9                                 (pkinit)
-md5WithRSAEncryption-CmsOID   10                                 (pkinit)
-sha1WithRSAEncryption-CmsOID  11                                 (pkinit)
-rc2CBC-EnvOID                 12                                 (pkinit)
-rsaEncryption-EnvOID          13                      (pkinit from PKCS#1
-v1.5)
-rsaES-OAEP-ENV-OID            14                      (pkinit from PKCS#1
-v2.0)
-des-ede3-cbc-Env-OID          15                                 (pkinit)
-des3kd-cbc-sha1               ??     8                 0                 8
-ENCTYPE_PK_CROSS              48                      (reserved for pkcross)
-       0x8003
-
-Checksum type              sumtype value       checksum size
-CRC32                      1                   4
-rsa-md4                    2                   16
-rsa-md4-des                3                   24
-des-mac                    4                   16
-des-mac-k                  5                   8
-rsa-md4-des-k              6                   16
-rsa-md5                    7                   16
-rsa-md5-des                8                   24
-rsa-md5-des3               9                   24
-hmac-sha1-des3             12                  20  (I had this as 10, is it
-12)
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-padata type                     padata-type value
-
-PA-TGS-REQ                      1
-PA-ENC-TIMESTAMP                2
-PA-PW-SALT                      3
-                      4
-PA-ENC-UNIX-TIME                5
-PA-SANDIA-SECUREID              6
-PA-SESAME                       7
-PA-OSF-DCE                      8
-PA-CYBERSAFE-SECUREID           9
-PA-AFS3-SALT                    10
-PA-ETYPE-INFO                   11
-SAM-CHALLENGE                   12                  (sam/otp)
-SAM-RESPONSE                    13                  (sam/otp)
-PA-PK-AS-REQ                    14                  (pkinit)
-PA-PK-AS-REP                    15                  (pkinit)
-PA-PK-AS-SIGN                   16                  (***remove on 7/14***)
-PA-PK-KEY-REQ                   17                  (***remove on 7/14***)
-PA-PK-KEY-REP                   18                  (***remove on 7/14***)
-PA-USE-SPECIFIED-KVNO           20
-SAM-REDIRECT                    21                  (sam/otp)
-PA-GET-FROM-TYPED-DATA          22
-
-data-type                     value    form of typed-data
-
-                      1-21
-TD-PADATA                       22
-TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
-TD-KRB-PRINCIPAL                102
-TD-KRB-REALM                    103
-TD-TRUSTED-CERTIFIERS           104
-TD-CERTIFICATE-INDEX            105
-
-authorization data type         ad-type value
-AD-IF-RELEVANT                     1
-AD-INTENDED-FOR-SERVER             2
-AD-INTENDED-FOR-APPLICATION-CLASS  3
-AD-KDC-ISSUED                      4
-AD-OR                              5
-AD-MANDATORY-TICKET-EXTENSIONS     6
-AD-IN-TICKET-EXTENSIONS            7
-reserved values                    8-63
-OSF-DCE                            64
-SESAME                             65
-
-Ticket Extension Types
-
-TE-TYPE-NULL                  0      Null ticket extension
-TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
-                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
-TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
-TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
-                    5      TE-TYPE-DEST-HOST (I have reservations)
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-alternate authentication type   method-type value
-reserved values                 0-63
-ATT-CHALLENGE-RESPONSE          64
-
-transited encoding type         tr-type value
-DOMAIN-X500-COMPRESS            1
-reserved values                 all others
-
-Label               Value   Meaning or MIT code
-
-pvno                    5   current Kerberos protocol version number
-
-message types
-
-KRB_AS_REQ             10   Request for initial authentication
-KRB_AS_REP             11   Response to KRB_AS_REQ request
-KRB_TGS_REQ            12   Request for authentication based on TGT
-KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-KRB_AP_REQ             14   application request to server
-KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-KRB_SAFE               20   Safe (checksummed) application message
-KRB_PRIV               21   Private (encrypted) application message
-KRB_CRED               22   Private (encrypted) message to forward
-credentials
-KRB_ERROR              30   Error response
-
-name types
-
-KRB_NT_UNKNOWN        0  Name type not known
-KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for
-users
-KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
-KRB_NT_SRV_HST        3  Service with host name as instance (telnet,
-rcommands)
-KRB_NT_SRV_XHST       4  Service with host as remaining components
-KRB_NT_UID            5  Unique ID
-KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-
-error codes
-
-KDC_ERR_NONE                    0   No error
-KDC_ERR_NAME_EXP                1   Client's entry in database has expired
-KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
-KDC_ERR_BAD_PVNO                3   Requested protocol version # not
-supported
-KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
-KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
-KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
-KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
-KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
-KDC_ERR_NULL_KEY                9   The client or server has a null key
-KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-KDC_ERR_NEVER_VALID            11   Requested start time is later than end
-time
-KDC_ERR_POLICY                 12   KDC policy rejects request
-KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
-KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
-KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
-KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
-KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
-KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
-KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
-KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
-KDC_ERR_KEY_EXPIRED            23   Password has expired - change password
-KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was
-invalid
-KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired
-[40]
-KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
-KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user
-only
-KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
-KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field
-failed
-KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-KRB_AP_ERR_REPEAT              34   Request is a replay
-KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
-KRB_AP_ERR_SKEW                37   Clock skew too great
-KRB_AP_ERR_BADADDR             38   Incorrect net address
-KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-KRB_AP_ERR_MODIFIED            41   Message stream modified
-KRB_AP_ERR_BADORDER            42   Message out of order
-KRB_AP_ERR_BADKEYVER           44   Specified version of key is not
-available
-KRB_AP_ERR_NOKEY               45   Service key not available
-KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-KRB_AP_ERR_METHOD              48   Alternative authentication method
-required
-KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
-KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in
-message
-KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
-KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
-KRB_ERR_GENERIC                60   Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG          61   Field is too long for this
-implementation
-KDC_ERROR_CLIENT_NOT_TRUSTED            62 (pkinit)
-KDC_ERROR_KDC_NOT_TRUSTED               63 (pkinit)
-KDC_ERROR_INVALID_SIG                   64 (pkinit)
-KDC_ERR_KEY_TOO_WEAK                    65 (pkinit)
-KDC_ERR_CERTIFICATE_MISMATCH            66 (pkinit)
-KRB_AP_ERR_NO_TGT                       67 (user-to-user)
-KDC_ERR_WRONG_REALM                     68 (user-to-user)
-KRB_AP_ERR_USER_TO_USER_REQUIRED        69 (user-to-user)
-KDC_ERR_CANT_VERIFY_CERTIFICATE         70 (pkinit)
-KDC_ERR_INVALID_CERTIFICATE             71 (pkinit)
-KDC_ERR_REVOKED_CERTIFICATE             72 (pkinit)
-KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 (pkinit)
-KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 (pkinit)
-KDC_ERR_CLIENT_NAME_MISMATCH            75 (pkinit)
-KDC_ERR_KDC_NAME_MISMATCH               76 (pkinit)
-
-9. Interoperability requirements
-
-Version 5 of the Kerberos protocol supports a myriad of options. Among these
-are multiple encryption and checksum types, alternative encoding schemes for
-the transited field, optional mechanisms for pre-authentication, the
-handling of tickets with no addresses, options for mutual authentication,
-user to user authentication, support for proxies, forwarding, postdating,
-and renewing tickets, the format of realm names, and the handling of
-authorization data.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-In order to ensure the interoperability of realms, it is necessary to define
-a minimal configuration which must be supported by all implementations. This
-minimal configuration is subject to change as technology does. For example,
-if at some later date it is discovered that one of the required encryption
-or checksum algorithms is not secure, it will be replaced.
-
-9.1. Specification 2
-
-This section defines the second specification of these options.
-Implementations which are configured in this way can be said to support
-Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may
-be found in RFC1510.
-
-Transport
-
-TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance
-to specification 2. Kerberos clients claiming conformance to specification 2
-must support UDP/IP transport for messages with the KDC and should support
-TCP/IP transport.
-
-Encryption and checksum methods
-
-The following encryption and checksum mechanisms must be supported.
-Implementations may support other mechanisms as well, but the additional
-mechanisms may only be used when communicating with principals known to also
-support them: This list is to be determined. [***This section will change,
-and alternatives will be sent to the cat and krb-protocol list prior to the
-Oslo IETF - change will be made 7/14/99 ***]
-
-Encryption: DES-CBC-MD5
-Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-Realm Names
-
-All implementations must understand hierarchical realms in both the Internet
-Domain and the X.500 style. When a ticket granting ticket for an unknown
-realm is requested, the KDC must be able to determine the names of the
-intermediate realms between the KDCs realm and the requested realm.
-
-Transited field encoding
-
-DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
-Alternative encodings may be supported, but they may be used only when that
-encoding is supported by ALL intermediate realms.
-
-Pre-authentication methods
-
-The TGS-REQ method must be supported. The TGS-REQ method is not used on the
-initial request. The PA-ENC-TIMESTAMP method must be supported by clients
-but whether it is enabled by default may be determined on a realm by realm
-basis. If not used in the initial request and the error
-KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
-acceptable method, the client should retry the initial request using the
-PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
-PA-ENC-TIMESTAMP method, but if not supported the server should ignore the
-presence of PA-ENC-TIMESTAMP pre-authentication in a request.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-Mutual authentication
-
-Mutual authentication (via the KRB_AP_REP message) must be supported.
-
-Ticket addresses and flags
-
-All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
-contains no addresses, the KDC will return derivative tickets), but each
-realm may set its own policy for issuing such tickets, and each application
-server will set its own policy with respect to accepting them.
-
-Proxies and forwarded tickets must be supported. Individual realms and
-application servers can set their own policy on when such tickets will be
-accepted.
-
-All implementations must recognize renewable and postdated tickets, but need
-not actually implement them. If these options are not supported, the
-starttime and endtime in the ticket shall specify a ticket's entire useful
-life. When a postdated ticket is decoded by a server, all implementations
-shall make the presence of the postdated flag visible to the calling server.
-
-User-to-user authentication
-
-Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option)
-must be provided by implementations, but individual realms may decide as a
-matter of policy to reject such requests on a per-principal or realm-wide
-basis.
-
-Authorization data
-
-Implementations must pass all authorization data subfields from
-ticket-granting tickets to any derivative tickets unless directed to
-suppress a subfield as part of the definition of that registered subfield
-type (it is never incorrect to pass on a subfield, and no registered
-subfield types presently specify suppression at the KDC).
-
-Implementations must make the contents of any authorization data subfields
-available to the server when a ticket is used. Implementations are not
-required to allow clients to specify the contents of the authorization data
-fields.
-
-Constant ranges
-
-All protocol constants are constrained to 32 bit (signed) values unless
-further constrained by the protocol definition. This limit is provided to
-allow implementations to make assumptions about the maximum values that will
-be received for these constants. Implementation receiving values outside
-this range may reject the request, but they must recover cleanly.
-
-9.2. Recommended KDC values
-
-Following is a list of recommended values for a KDC implementation, based on
-the list of suggested configuration constants (see section 4.4).
-
-minimum lifetime              5 minutes
-maximum renewable lifetime    1 week
-maximum ticket lifetime       1 day
-empty addresses               only when suitable  restrictions  appear
-                              in authorization data
-proxiable, etc.               Allowed.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-10. REFERENCES
-
-[NT94]    B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
-          cation  Service for Computer Networks," IEEE Communica-
-          tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
-
-[MNSS87]  S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
-          Saltzer,  Section  E.2.1:  Kerberos  Authentication and
-          Authorization System, M.I.T. Project Athena, Cambridge,
-          Massachusetts (December 21, 1987).
-
-[SNS88]   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
-          beros:  An Authentication Service for Open Network Sys-
-          tems," pp. 191-202 in  Usenix  Conference  Proceedings,
-          Dallas, Texas (February, 1988).
-
-[NS78]    Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
-          Encryption for Authentication in Large Networks of Com-
-          puters,"  Communications  of  the  ACM,  Vol.   21(12),
-          pp. 993-999 (December, 1978).
-
-[DS81]    Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
-          stamps  in  Key Distribution Protocols," Communications
-          of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-[KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
-          "The Evolution of the Kerberos Authentication Service,"
-          in an IEEE Computer Society Text soon to  be  published
-          (June 1992).
-
-[Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
-          Accounting  for Distributed Systems," in Proceedings of
-          the 13th International Conference on  Distributed  Com-
-          puting Systems, Pittsburgh, PA (May, 1993).
-
-[DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
-          Kerberos  Authentication  at Project Athena," Technical
-          Memorandum TM-424,  MIT Laboratory for Computer Science
-          (February 1990).
-
-[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
-          merfeld,  and  K. Raeburn, Section E.1: Service Manage-
-          ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
-          sachusetts (1987).
-
-[X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
-          tion Framework, December 1988.
-
-[Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
-          Guessing  Attacks, Open Software Foundation DCE Request
-          for Comments 26 (December 1992).
-
-[DES77]   National Bureau of Standards, U.S. Department  of  Com-
-          merce,  "Data Encryption Standard," Federal Information
-          Processing Standards Publication  46,   Washington,  DC
-          (1977).
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-[DESM80]  National Bureau of Standards, U.S. Department  of  Com-
-          merce,  "DES  Modes  of Operation," Federal Information
-          Processing Standards Publication 81,   Springfield,  VA
-          (December 1980).
-
-[SG92]    Stuart G. Stubblebine and Virgil D. Gligor, "On Message
-          Integrity  in  Cryptographic Protocols," in Proceedings
-          of the IEEE  Symposium  on  Research  in  Security  and
-          Privacy, Oakland, California (May 1992).
-
-[IS3309]  International Organization  for  Standardization,  "ISO
-          Information  Processing  Systems - Data Communication -
-          High-Level Data Link Control Procedure -  Frame  Struc-
-          ture," IS 3309 (October 1984).  3rd Edition.
-
-[MD4-92]  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
-          1320,   MIT  Laboratory  for  Computer  Science  (April
-          1992).
-
-[MD5-92]  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
-          1321,   MIT  Laboratory  for  Computer  Science  (April
-          1992).
-
-[KBC96]   H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
-          Hashing  for  Message  Authentication,"  Working  Draft
-          draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
-
-[Horowitz96] Horowitz, M., "Key Derivation for Authentication,
-          Integrity, and Privacy", draft-horowitz-key-derivation-02.txt,
-          August 1998.
-
-[HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
-          horowitz-kerb-key-derivation-01.txt, September 1998.
-
-[Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
-          Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
-          md5-01.txt, August, 1996.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A. Pseudo-code for protocol processing
-
-This appendix provides pseudo-code describing how the messages are to be
-constructed and interpreted by clients and servers.
-
-A.1. KRB_AS_REQ generation
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_AS_REQ */
-
-        if(pa_enc_timestamp_required) then
-                request.padata.padata-type = PA-ENC-TIMESTAMP;
-                get system_time;
-                padata-body.patimestamp,pausec = system_time;
-                encrypt padata-body into request.padata.padata-value
-                        using client.key; /* derived from password */
-        endif
-
-        body.kdc-options := users's preferences;
-        body.cname := user's name;
-        body.realm := user's realm;
-        body.sname := service's name; /* usually "krbtgt",  "localrealm" */
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-        omit body.enc-authorization-data;
-        request.req-body := body;
-
-        kerberos := lookup(name of local kerberos server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A.2. KRB_AS_REQ verification and KRB_AS_REP generation
-
-        decode message into req;
-
-        client := lookup(req.cname,req.realm);
-        server := lookup(req.sname,req.realm);
-
-        get system_time;
-        kdc_time := system_time.seconds;
-
-        if (!client) then
-                /* no client in Database */
-                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
-        endif
-        if (!server) then
-                /* no server in Database */
-                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-        endif
-
-        if(client.pa_enc_timestamp_required and
-           pa_enc_timestamp not present) then
-                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
-        endif
-
-        if(pa_enc_timestamp present) then
-                decrypt req.padata-value into decrypted_enc_timestamp
-                        using client.key;
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                if(decrypted_enc_timestamp is not within allowable skew)
-then
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                if(decrypted_enc_timestamp and usec is replay)
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                add decrypted_enc_timestamp and usec to replay cache;
-        endif
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := req.srealm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        if (req.kdc-options.FORWARDABLE is set) then
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.PROXIABLE is set) then
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                set new_tkt.flags.PROXIABLE;
-        endif
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if ((req.kdc-options.RENEW is set) or
-            (req.kdc-options.VALIDATE is set) or
-            (req.kdc-options.PROXY is set) or
-            (req.kdc-options.FORWARDED is set) or
-            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.session := random_session_key();
-        new_tkt.cname := req.cname;
-        new_tkt.crealm := req.crealm;
-        new_tkt.transited := empty_transited_field();
-
-        new_tkt.authtime := kdc_time;
-
-        if (req.kdc-options.POSTDATED is set) then
-           if (against_postdate_policy(req.from)) then
-                error_out(KDC_ERR_POLICY);
-           endif
-           set new_tkt.flags.POSTDATED;
-           set new_tkt.flags.INVALID;
-           new_tkt.starttime := req.from;
-        else
-           omit new_tkt.starttime; /* treated as authtime when omitted */
-        endif
-        if (req.till = 0) then
-                till := infinity;
-        else
-                till := req.till;
-        endif
-
-        new_tkt.endtime := min(till,
-                              new_tkt.starttime+client.max_life,
-                              new_tkt.starttime+server.max_life,
-                              new_tkt.starttime+max_life_for_realm);
-
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (new_tkt.endtime < req.till)) then
-                /* we set the RENEWABLE option for later processing */
-                set req.kdc-options.RENEWABLE;
-                req.rtime := req.till;
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if (req.kdc-options.RENEWABLE is set) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                                     new_tkt.starttime+client.max_rlife,
-                                     new_tkt.starttime+server.max_rlife,
-                                     new_tkt.starttime+max_rlife_for_realm);
-        else
-                omit new_tkt.renew-till; /* only present if RENEWABLE */
-        endif
-
-        if (req.addresses) then
-                new_tkt.caddr := req.addresses;
-        else
-                omit new_tkt.caddr;
-        endif
-
-        new_tkt.authorization_data := empty_authorization_data();
-
-        encode to-be-encrypted part of ticket into OCTET STRING;
-        new_tkt.enc-part := encrypt OCTET STRING
-                using etype_for_key(server.key), server.key, server.p_kvno;
-
-        /* Start processing the response */
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_AS_REP;
-        resp.cname := req.cname;
-        resp.crealm := req.realm;
-        resp.ticket := new_tkt;
-
-        resp.key := new_tkt.session;
-        resp.last-req := fetch_last_request_info(client);
-        resp.nonce := req.nonce;
-        resp.key-expiration := client.expiration;
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        resp.realm := new_tkt.realm;
-        resp.sname := new_tkt.sname;
-
-        resp.caddr := new_tkt.caddr;
-
-        encode body of reply into OCTET STRING;
-
-        resp.enc-part := encrypt OCTET STRING
-                         using use_etype, client.key, client.p_kvno;
-        send(resp);
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A.3. KRB_AS_REP verification
-
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
-                        set pa_enc_timestamp_required;
-                        goto KRB_AS_REQ;
-                endif
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key */
-        /* from the response immediately */
-
-        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
-                                 resp.padata);
-        unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and key;
-        zero(key);
-
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        if near(resp.princ_exp) then
-                print(warning message);
-        endif
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.4. KRB_AS_REP and KRB_TGS_REP common checks
-
-        if (decryption_error() or
-            (req.cname != resp.cname) or
-            (req.realm != resp.crealm) or
-            (req.sname != resp.sname) or
-            (req.realm != resp.realm) or
-            (req.nonce != resp.nonce) or
-            (req.addresses != resp.caddr)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        /* make sure no flags are set that shouldn't be, and that all that
-*/
-        /* should be are set
-*/
-        if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.from = 0) and
-            (resp.starttime is not within allowable skew)) then
-                destroy resp.key;
-                return KRB_AP_ERR_SKEW;
-        endif
-        if ((req.from != 0) and (req.from != resp.starttime)) then
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.till != 0) and (resp.endtime > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (req.rtime != 0) and (resp.renew-till > req.rtime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (resp.flags.RENEWABLE) and
-            (req.till != 0) and
-            (resp.renew-till > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-A.5. KRB_TGS_REQ generation
-
-        /* Note that make_application_request might have to recursivly
-*/
-        /* call this routine to get the appropriate ticket-granting ticket
-*/
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_TGS_REQ */
-
-        body.kdc-options := users's preferences;
-        /* If the TGT is not for the realm of the end-server  */
-        /* then the sname will be for a TGT for the end-realm */
-        /* and the realm of the requested ticket (body.realm) */
-        /* will be that of the TGS to which the TGT we are    */
-        /* sending applies                                    */
-        body.sname := service's name;
-        body.realm := service's realm;
-
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-
-        body.enc-authorization-data := user-supplied data;
-        if (body.kdc-options.ENC-TKT-IN-SKEY) then
-                body.additional-tickets_ticket := second TGT;
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-        endif
-
-        request.req-body := body;
-        check := generate_checksum (req.body,checksumtype);
-
-        request.padata[0].padata-type := PA-TGS-REQ;
-        request.padata[0].padata-value := create a KRB_AP_REQ using
-                                      the TGT and checksum
-
-        /* add in any other padata as required/supplied */
-
-        kerberos := lookup(name of local kerberose server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
-
-        /* note that reading the application request requires first
-        determining the server for which a ticket was issued, and choosing
-the
-        correct key for decryption.  The name of the server appears in the
-        plaintext part of the ticket. */
-
-        if (no KRB_AP_REQ in req.padata) then
-                error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
-        endif
-        verify KRB_AP_REQ in req.padata;
-
-        /* Note that the realm in which the Kerberos server is operating is
-        determined by the instance from the ticket-granting ticket.  The
-realm
-        in the ticket-granting ticket is the realm under which the ticket
-        granting ticket was issued.  It is possible for a single Kerberos
-        server to support more than one realm. */
-
-        auth_hdr := KRB_AP_REQ;
-        tgt := auth_hdr.ticket;
-
-        if (tgt.sname is not a TGT for local realm and is not req.sname)
-then
-                error_out(KRB_AP_ERR_NOT_US);
-
-        realm := realm_tgt_is_for(tgt);
-
-        decode remainder of request;
-
-        if (auth_hdr.authenticator.cksum is missing) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-        if (auth_hdr.authenticator.cksum type is not supported) then
-                error_out(KDC_ERR_SUMTYPE_NOSUPP);
-        endif
-        if (auth_hdr.authenticator.cksum is not both collision-proof and
-            keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-        set computed_checksum := checksum(req);
-        if (computed_checksum != auth_hdr.authenticatory.cksum) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        server := lookup(req.sname,realm);
-
-        if (!server) then
-                if (is_foreign_tgt_name(req.sname)) then
-                        server := best_intermediate_tgs(req.sname);
-                else
-                        /* no server in Database */
-                        error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-                endif
-        endif
-
-        session := generate_random_session_key();
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := realm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        new_tkt.caddr := tgt.caddr;
-        resp.caddr := NULL; /* We only include this if they change */
-        if (req.kdc-options.FORWARDABLE is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.FORWARDED is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDED;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-        if (tgt.flags.FORWARDED is set) then
-                set new_tkt.flags.FORWARDED;
-        endif
-
-        if (req.kdc-options.PROXIABLE is set) then
-                if (tgt.flags.PROXIABLE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                set new_tkt.flags.PROXIABLE;
-        endif
-        if (req.kdc-options.PROXY is set) then
-                if (tgt.flags.PROXIABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXY;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                if (tgt.flags.MAY-POSTDATE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if (req.kdc-options.POSTDATED is set) then
-                if (tgt.flags.MAY-POSTDATE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.POSTDATED;
-                set new_tkt.flags.INVALID;
-                if (against_postdate_policy(req.from)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                new_tkt.starttime := req.from;
-        endif
-
-        if (req.kdc-options.VALIDATE is set) then
-                if (tgt.flags.INVALID is reset) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                if (tgt.starttime > kdc_time) then
-                        error_out(KRB_AP_ERR_NYV);
-                endif
-                if (check_hot_list(tgt)) then
-                        error_out(KRB_AP_ERR_REPEAT);
-                endif
-                tkt := tgt;
-                reset new_tkt.flags.INVALID;
-        endif
-
-        if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
-                             and those already processed) is set) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.authtime := tgt.authtime;
-
-        if (req.kdc-options.RENEW is set) then
-          /* Note that if the endtime has already passed, the ticket would
-*/
-          /* have been rejected in the initial authentication stage, so
-*/
-          /* there is no need to check again here
-*/
-                if (tgt.flags.RENEWABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                if (tgt.renew-till < kdc_time) then
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                        error_out(KRB_AP_ERR_TKT_EXPIRED);
-                endif
-                tkt := tgt;
-                new_tkt.starttime := kdc_time;
-                old_life := tgt.endttime - tgt.starttime;
-                new_tkt.endtime := min(tgt.renew-till,
-                                       new_tkt.starttime + old_life);
-        else
-                new_tkt.starttime := kdc_time;
-                if (req.till = 0) then
-                        till := infinity;
-                else
-                        till := req.till;
-                endif
-                new_tkt.endtime := min(till,
-                                       new_tkt.starttime+client.max_life,
-                                       new_tkt.starttime+server.max_life,
-                                       new_tkt.starttime+max_life_for_realm,
-                                       tgt.endtime);
-
-                if ((req.kdc-options.RENEWABLE-OK is set) and
-                    (new_tkt.endtime < req.till) and
-                    (tgt.flags.RENEWABLE is set) then
-                        /* we set the RENEWABLE option for later processing
-*/
-                        set req.kdc-options.RENEWABLE;
-                        req.rtime := min(req.till, tgt.renew-till);
-                endif
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (tgt.flags.RENEWABLE is set)) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-                                      new_tkt.starttime+client.max_rlife,
-                                      new_tkt.starttime+server.max_rlife,
-                                      new_tkt.starttime+max_rlife_for_realm,
-                                      tgt.renew-till);
-        else
-              new_tkt.renew-till := OMIT; /* leave the renew-till field out
-*/
-        endif
-        if (req.enc-authorization-data is present) then
-          decrypt req.enc-authorization-data into
-decrypted_authorization_data
-                  using auth_hdr.authenticator.subkey;
-          if (decrypt_error()) then
-                  error_out(KRB_AP_ERR_BAD_INTEGRITY);
-          endif
-        endif
-        new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data
-+
-                                 decrypted_authorization_data;
-
-        new_tkt.key := session;
-        new_tkt.crealm := tgt.crealm;
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-        new_tkt.cname := req.auth_hdr.ticket.cname;
-
-        if (realm_tgt_is_for(tgt) := tgt.realm) then
-                /* tgt issued by local realm */
-                new_tkt.transited := tgt.transited;
-        else
-                /* was issued for this realm by some other realm */
-                if (tgt.transited.tr-type not supported) then
-                        error_out(KDC_ERR_TRTYPE_NOSUPP);
-                endif
-            new_tkt.transited := compress_transited(tgt.transited +
-tgt.realm)
-                /* Don't check tranited field if TGT for foreign realm,
-                 * or requested not to check */
-                if (is_not_foreign_tgt_name(new_tkt.server)
-                   && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then
-                        /* Check it, so end-server does not have to
-                         * but don't fail, end-server may still accept it */
-                        if (check_transited_field(new_tkt.transited) == OK)
-                              set new_tkt.flags.TRANSITED-POLICY-CHECKED;
-                        endif
-                endif
-        endif
-
-        encode encrypted part of new_tkt into OCTET STRING;
-        if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
-                if (server not specified) then
-                        server = req.second_ticket.client;
-                endif
-                if ((req.second_ticket is not a TGT) or
-                    (req.second_ticket.client != server)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-
-                new_tkt.enc-part := encrypt OCTET STRING using
-                 using etype_for_key(second-ticket.key), second-ticket.key;
-        else
-                new_tkt.enc-part := encrypt OCTET STRING
-                 using etype_for_key(server.key), server.key, server.p_kvno;
-        endif
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_TGS_REP;
-        resp.crealm := tgt.crealm;
-        resp.cname := tgt.cname;
-        resp.ticket := new_tkt;
-
-        resp.key := session;
-        resp.nonce := req.nonce;
-        resp.last-req := fetch_last_request_info(client);
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        omit resp.key-expiration;
-
-        resp.sname := new_tkt.sname;
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-        resp.realm := new_tkt.realm;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        encode body of reply into OCTET STRING;
-
-        if (req.padata.authenticator.subkey)
-                resp.enc-part := encrypt OCTET STRING using use_etype,
-                        req.padata.authenticator.subkey;
-        else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
-
-        send(resp);
-
-A.7. KRB_TGS_REP verification
-
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key from
-        the response immediately */
-
-        if (req.padata.authenticator.subkey)
-                unencrypted part of resp := decode of decrypt of
-resp.enc-part
-                        using resp.enc-part.etype and subkey;
-        else unencrypted part of resp := decode of decrypt of resp.enc-part
-                            using resp.enc-part.etype and tgt's session key;
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        check authorization_data as necessary;
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.8. Authenticator generation
-
-        body.authenticator-vno := authenticator vno; /* = 5 */
-        body.cname, body.crealm := client name;
-        if (supplying checksum) then
-                body.cksum := checksum;
-        endif
-        get system_time;
-        body.ctime, body.cusec := system_time;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A.9. KRB_AP_REQ generation
-
-        obtain ticket and session_key from cache;
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REQ */
-
-        if (desired(MUTUAL_AUTHENTICATION)) then
-                set packet.ap-options.MUTUAL-REQUIRED;
-        else
-                reset packet.ap-options.MUTUAL-REQUIRED;
-        endif
-        if (using session key for ticket) then
-                set packet.ap-options.USE-SESSION-KEY;
-        else
-                reset packet.ap-options.USE-SESSION-KEY;
-        endif
-        packet.ticket := ticket; /* ticket */
-        generate authenticator;
-        encode authenticator into OCTET STRING;
-        encrypt OCTET STRING into packet.authenticator using session_key;
-
-A.10. KRB_AP_REQ verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REQ) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.ticket.tkt_vno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.ap_options.USE-SESSION-KEY is set) then
-                retrieve session key from ticket-granting ticket for
-                 packet.ticket.{sname,srealm,enc-part.etype};
-        else
-                retrieve service key for
-                 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
-        endif
-        if (no_key_available) then
-                if (cannot_find_specified_skvno) then
-                        error_out(KRB_AP_ERR_BADKEYVER);
-                else
-                        error_out(KRB_AP_ERR_NOKEY);
-                endif
-        endif
-        decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        decrypt packet.authenticator into decr_authenticator
-                using decr_ticket.key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-        endif
-        if (decr_authenticator.{cname,crealm} !=
-            decr_ticket.{cname,crealm}) then
-                error_out(KRB_AP_ERR_BADMATCH);
-        endif
-        if (decr_ticket.caddr is present) then
-                if (sender_address(packet) is not in decr_ticket.caddr) then
-                        error_out(KRB_AP_ERR_BADADDR);
-                endif
-        elseif (application requires addresses) then
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(decr_authenticator.ctime,
-                              decr_authenticator.cusec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
-        get system_time;
-        if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
-            (decr_ticket.flags.INVALID is set)) then
-                /* it hasn't yet become valid */
-                error_out(KRB_AP_ERR_TKT_NYV);
-        endif
-        if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
-                error_out(KRB_AP_ERR_TKT_EXPIRED);
-        endif
-        if (decr_ticket.transited) then
-            /* caller may ignore the TRANSITED-POLICY-CHECKED and do
-             * check anyway */
-            if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then
-                 if (check_transited_field(decr_ticket.transited) then
-                      error_out(KDC_AP_PATH_NOT_ACCPETED);
-                 endif
-            endif
-        endif
-        /* caller must check decr_ticket.flags for any pertinent details */
-        return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A.11. KRB_AP_REP generation
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REP */
-
-        body.ctime := packet.ctime;
-        body.cusec := packet.cusec;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part;
-
-A.12. KRB_AP_REP verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REP) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        cleartext := decrypt(packet.enc-part) using ticket's session key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (cleartext.ctime != authenticator.ctime) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.cusec != authenticator.cusec) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.subkey is present) then
-                save cleartext.subkey for future use;
-        endif
-        if (cleartext.seq-number is present) then
-                save cleartext.seq-number for future verifications;
-        endif
-        return(AUTHENTICATION_SUCCEEDED);
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A.13. KRB_SAFE generation
-
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_SAFE */
-
-        body.user-data := buffer; /* DATA */
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-        checksum.cksumtype := checksum type;
-        compute checksum over body;
-        checksum.checksum := checksum value; /* checksum.checksum */
-        packet.cksum := checksum;
-        packet.safe-body := body;
-
-A.14. KRB_SAFE verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_SAFE) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.checksum.cksumtype is not both collision-proof
-              and keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-        if (safe_priv_common_checks_ok(packet)) then
-                set computed_checksum := checksum(packet.body);
-                if (computed_checksum != packet.checksum) then
-                        error_out(KRB_AP_ERR_MODIFIED);
-                endif
-                return (packet, PACKET_IS_GENUINE);
-        else
-                return common_checks_error;
-        endif
-
-A.15. KRB_SAFE and KRB_PRIV common checks
-
-        if (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (((packet.timestamp is present) and
-             (not in_clock_skew(packet.timestamp,packet.usec))) or
-            (packet.timestamp is not present and timestamp expected)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-
-        if (((packet.seq-number is present) and
-             ((not in_sequence(packet.seq-number)))) or
-            (packet.seq-number is not present and sequence expected)) then
-                error_out(KRB_AP_ERR_BADORDER);
-        endif
-        if (packet.timestamp not present and packet.seq-number
-              not present) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        save_identifier(packet.{timestamp,usec,s-address},
-                        sender_principal(packet));
-
-        return PACKET_IS_OK;
-
-A.16. KRB_PRIV generation
-
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_PRIV */
-
-        packet.enc-part.etype := encryption type;
-
-        body.user-data := buffer;
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher;
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A.17. KRB_PRIV verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_PRIV) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-
-        if (safe_priv_common_checks_ok(cleartext)) then
-                return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
-        else
-                return common_checks_error;
-        endif
-
-A.18. KRB_CRED generation
-
-        invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_CRED */
-
-        for (tickets[n] in tickets to be forwarded) do
-                packet.tickets[n] = tickets[n].ticket;
-        done
-
-        packet.enc-part.etype := encryption type;
-
-        for (ticket[n] in tickets to be forwarded) do
-                body.ticket-info[n].key = tickets[n].session;
-                body.ticket-info[n].prealm = tickets[n].crealm;
-                body.ticket-info[n].pname = tickets[n].cname;
-                body.ticket-info[n].flags = tickets[n].flags;
-                body.ticket-info[n].authtime = tickets[n].authtime;
-                body.ticket-info[n].starttime = tickets[n].starttime;
-                body.ticket-info[n].endtime = tickets[n].endtime;
-                body.ticket-info[n].renew-till = tickets[n].renew-till;
-                body.ticket-info[n].srealm = tickets[n].srealm;
-                body.ticket-info[n].sname = tickets[n].sname;
-                body.ticket-info[n].caddr = tickets[n].caddr;
-        done
-
-        get system_time;
-        body.timestamp, body.usec := system_time;
-
-        if (using nonce) then
-                body.nonce := nonce;
-        endif
-
-        if (using s-address) then
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-                body.s-address := sender host addresses;
-        endif
-        if (limited recipients) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher
-               using negotiated encryption key;
-
-A.19. KRB_CRED verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_CRED) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if ((packet.r-address is present or required) and
-           (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(packet.timestamp,packet.usec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        if (packet.nonce is required or present) and
-           (packet.nonce != expected-nonce) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        for (ticket[n] in tickets that were forwarded) do
-                save_for_later(ticket[n],key[n],principal[n],
-                               server[n],times[n],flags[n]);
-        return
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-A.20. KRB_ERROR generation
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_ERROR */
-
-        get system_time;
-        packet.stime, packet.susec := system_time;
-        packet.realm, packet.sname := server name;
-
-        if (client time available) then
-                packet.ctime, packet.cusec := client_time;
-        endif
-        packet.error-code := error code;
-        if (client name available) then
-                packet.cname, packet.crealm := client name;
-        endif
-        if (error text available) then
-                packet.e-text := error text;
-        endif
-        if (error data available) then
-                packet.e-data := error data;
-        endif
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-B. Definition of common authorization data elements
-
-This appendix contains the definitions of common authorization data
-elements. These common authorization data elements are recursivly defined,
-meaning the ad-data for these types will itself contain a sequence of
-authorization data whose interpretation is affected by the encapsulating
-element. Depending on the meaning of the encapsulating element, the
-encapsulated elements may be ignored, might be interpreted as issued
-directly by the KDC, or they might be stored in a separate plaintext part of
-the ticket. The types of the encapsulating elements are specified as part of
-the Kerberos specification because the behavior based on these values should
-be understood across implementations whereas other elements need only be
-understood by the applications which they affect.
-
-In the definitions that follow, the value of the ad-type for the element
-will be specified in the subsection number, and the value of the ad-data
-will be as shown in the ASN.1 structure that follows the subsection heading.
-
-B.1. If relevant
-
-AD-IF-RELEVANT   AuthorizationData
-
-AD elements encapsulated within the if-relevant element are intended for
-interpretation only by application servers that understand the particular
-ad-type of the embedded element. Application servers that do not understand
-the type of an element embedded within the if-relevant element may ignore
-the uninterpretable element. This element promotes interoperability across
-implementations which may have local extensions for authorization.
-
-B.2. Intended for server
-
-AD-INTENDED-FOR-SERVER   SEQUENCE {
-         intended-server[0]     SEQUENCE OF PrincipalName
-         elements[1]            AuthorizationData
-}
-
-AD elements encapsulated within the intended-for-server element may be
-ignored if the application server is not in the list of principal names of
-intended servers. Further, a KDC issuing a ticket for an application server
-can remove this element if the application server is not in the list of
-intended servers.
-
-Application servers should check for their principal name in the
-intended-server field of this element. If their principal name is not found,
-this element should be ignored. If found, then the encapsulated elements
-should be evaluated in the same manner as if they were present in the top
-level authorization data field. Applications and application servers that do
-not implement this element should reject tickets that contain authorization
-data elements of this type.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-B.3. Intended for application class
-
-AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0]
-SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements
-encapsulated within the intended-for-application-class element may be
-ignored if the application server is not in one of the named classes of
-application servers. Examples of application server classes include
-"FILESYSTEM", and other kinds of servers.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-B.4. KDC Issued
-
-AD-KDCIssued   SEQUENCE {
-               ad-checksum[0]    Checksum,
-                i-realm[1]       Realm OPTIONAL,
-                i-sname[2]       PrincipalName OPTIONAL,
-               elements[3]       AuthorizationData.
-}
-
-ad-checksum
-     A checksum over the elements field using a cryptographic checksum
-     method that is identical to the checksum used to protect the ticket
-     itself (i.e. using the same hash function and the same encryption
-     algorithm used to encrypt the ticket) and using a key derived from the
-     same key used to protect the ticket.
-i-realm, i-sname
-     The name of the issuing principal if different from the KDC itself.
-     This field would be used when the KDC can verify the authenticity of
-     elements signed by the issuing principal and it allows this KDC to
-     notify the application server of the validity of those elements.
-elements
-     A sequence of authorization data elements issued by the KDC.
-
-The KDC-issued ad-data field is intended to provide a means for Kerberos
-principal credentials to embed within themselves privilege attributes and
-other mechanisms for positive authorization, amplifying the priveleges of
-the principal beyond what can be done using a credentials without such an
-a-data element.
-
-This can not be provided without this element because the definition of the
-authorization-data field allows elements to be added at will by the bearer
-of a TGT at the time that they request service tickets and elements may also
-be added to a delegated ticket by inclusion in the authenticator.
-
-For KDC-issued elements this is prevented because the elements are signed by
-the KDC by including a checksum encrypted using the server's key (the same
-key used to encrypt the ticket - or a key derived from that key). Elements
-encapsulated with in the KDC-issued element will be ignored by the
-application server if this "signature" is not present. Further, elements
-encapsulated within this element from a ticket granting ticket may be
-interpreted by the KDC, and used as a basis according to policy for
-including new signed elements within derivative tickets, but they will not
-be copied to a derivative ticket directly. If they are copied directly to a
-derivative ticket by a KDC that is not aware of this element, the signature
-will not be correct for the application ticket elements, and the field will
-be ignored by the application server.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-B.5. And-Or
-
-AD-AND-OR           SEQUENCE {
-                        condition-count[0]    INTEGER,
-                        elements[1]           AuthorizationData
-}
-
-When restrictive AD elements encapsulated within the and-or element are
-encountered, only the number specified in condition-count of the
-encapsulated conditions must be met in order to satisfy this element. This
-element may be used to implement an "or" operation by setting the
-condition-count field to 1, and it may specify an "and" operation by setting
-the condition count to the number of embedded elements. Application servers
-that do not implement this element must reject tickets that contain
-authorization data elements of this type.
-
-B.6. Mandatory ticket extensions
-
-AD-Mandatory-Ticket-Extensions   Checksum
-
-An authorization data element of type mandatory-ticket-extensions specifies
-a collision-proof checksum using the same hash algorithm used to protect the
-integrity of the ticket itself. This checksum will be calculated over an
-individual extension field. If there are more than one extension, multiple
-Mandatory-Ticket-Extensions authorization data elements may be present, each
-with a checksum for a different extension field. This restriction indicates
-that the ticket should not be accepted if a ticket extension is not present
-in the ticket for which the checksum does not match that checksum specified
-in the authorization data element. Application servers that do not implement
-this element must reject tickets that contain authorization data elements of
-this type.
-
-B.7. Authorization Data in ticket extensions
-
-AD-IN-Ticket-Extensions   Checksum
-
-An authorization data element of type in-ticket-extensions specifies a
-collision-proof checksum using the same hash algorithm used to protect the
-integrity of the ticket itself. This checksum is calculated over a separate
-external AuthorizationData field carried in the ticket extensions.
-Application servers that do not implement this element must reject tickets
-that contain authorization data elements of this type. Application servers
-that do implement this element will search the ticket extensions for
-authorization data fields, calculate the specified checksum over each
-authorization data field and look for one matching the checksum in this
-in-ticket-extensions element. If not found, then the ticket must be
-rejected. If found, the corresponding authorization data elements will be
-interpreted in the same manner as if they were contained in the top level
-authorization data field.
-
-Note that if multiple external authorization data fields are present in a
-ticket, each will have a corresponding element of type in-ticket-extensions
-in the top level authorization data field, and the external entries will be
-linked to the corresponding element by their checksums.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-C. Definition of common ticket extensions
-
-This appendix contains the definitions of common ticket extensions. Support
-for these extensions is optional. However, certain extensions have
-associated authorization data elements that may require rejection of a
-ticket containing an extension by application servers that do not implement
-the particular extension. Other extensions have been defined beyond those
-described in this specification. Such extensions are described elswhere and
-for some of those extensions the reserved number may be found in the list of
-constants.
-
-It is known that older versions of Kerberos did not support this field, and
-that some clients will strip this field from a ticket when they parse and
-then reassemble a ticket as it is passed to the application servers. The
-presence of the extension will not break such clients, but any functionaly
-dependent on the extensions will not work when such tickets are handled by
-old clients. In such situations, some implementation may use alternate
-methods to transmit the information in the extensions field.
-
-C.1. Null ticket extension
-
-TE-NullExtension   OctetString -- The empty Octet String
-
-The te-data field in the null ticket extension is an octet string of lenght
-zero. This extension may be included in a ticket granting ticket so that the
-KDC can determine on presentation of the ticket granting ticket whether the
-client software will strip the extensions field.
-
-C.2. External Authorization Data
-
-TE-ExternalAuthorizationData   AuthorizationData
-
-The te-data field in the external authorization data ticket extension is
-field of type AuthorizationData containing one or more authorization data
-elements. If present, a corresponding authorization data element will be
-present in the primary authorization data for the ticket and that element
-will contain a checksum of the external authorization data ticket extension.
-  ------------------------------------------------------------------------
-[TM] Project Athena, Athena, and Kerberos are trademarks of the
-Massachusetts Institute of Technology (MIT). No commercial use of these
-trademarks may be made without prior written permission of MIT.
-
-[1] Note, however, that many applications use Kerberos' functions only upon
-the initiation of a stream-based network connection. Unless an application
-subsequently provides integrity protection for the data stream, the identity
-verification applies only to the initiation of the connection, and does not
-guarantee that subsequent messages on the connection originate from the same
-principal.
-
-[2] Secret and private are often used interchangeably in the literature. In
-our usage, it takes two (or more) to share a secret, thus a shared DES key
-is a secret key. Something is only private when no one but its owner knows
-it. Thus, in public key cryptosystems, one has a public and a private key.
-
-[3] Of course, with appropriate permission the client could arrange
-registration of a separately-named prin- cipal in a remote realm, and engage
-in normal exchanges with that realm's services. However, for even small
-numbers of clients this becomes cumbersome, and more automatic methods as
-described here are necessary.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-[4] Though it is permissible to request or issue tick- ets with no network
-addresses specified.
-
-[5] The password-changing request must not be honored unless the requester
-can provide the old password (the user's current secret key). Otherwise, it
-would be possible for someone to walk up to an unattended ses- sion and
-change another user's password.
-
-[6] To authenticate a user logging on to a local system, the credentials
-obtained in the AS exchange may first be used in a TGS exchange to obtain
-credentials for a local server. Those credentials must then be verified by a
-local server through successful completion of the Client/Server exchange.
-
-[7] "Random" means that, among other things, it should be impossible to
-guess the next session key based on knowledge of past session keys. This can
-only be achieved in a pseudo-random number generator if it is based on
-cryptographic principles. It is more desirable to use a truly random number
-generator, such as one based on measurements of random physical phenomena.
-
-[8] Tickets contain both an encrypted and unencrypted portion, so cleartext
-here refers to the entire unit, which can be copied from one message and
-replayed in another without any cryptographic skill.
-
-[9] Note that this can make applications based on unreliable transports
-difficult to code correctly. If the transport might deliver duplicated
-messages, either a new authenticator must be generated for each retry, or
-the application server must match requests and replies and replay the first
-reply in response to a detected duplicate.
-
-[10] This is used for user-to-user authentication as described in [8].
-
-[11] Note that the rejection here is restricted to authenticators from the
-same principal to the same server. Other client principals communicating
-with the same server principal should not be have their authenticators
-rejected if the time and microsecond fields happen to match some other
-client's authenticator.
-
-[12] In the Kerberos version 4 protocol, the timestamp in the reply was the
-client's timestamp plus one. This is not necessary in version 5 because
-version 5 messages are formatted in such a way that it is not possible to
-create the reply by judicious message surgery (even in encrypted form)
-without knowledge of the appropriate encryption keys.
-
-[13] Note that for encrypting the KRB_AP_REP message, the sub-session key is
-not used, even if present in the Authenticator.
-
-[14] Implementations of the protocol may wish to provide routines to choose
-subkeys based on session keys and random numbers and to generate a
-negotiated key to be returned in the KRB_AP_REP message.
-
-[15]This can be accomplished in several ways. It might be known beforehand
-(since the realm is part of the principal identifier), it might be stored in
-a nameserver, or it might be obtained from a configura- tion file. If the
-realm to be used is obtained from a nameserver, there is a danger of being
-spoofed if the nameservice providing the realm name is not authenti- cated.
-This might result in the use of a realm which has been compromised, and
-would result in an attacker's ability to compromise the authentication of
-the application server to the client.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-[16] If the client selects a sub-session key, care must be taken to ensure
-the randomness of the selected sub- session key. One approach would be to
-generate a random number and XOR it with the session key from the
-ticket-granting ticket.
-
-[17] This allows easy implementation of user-to-user authentication [8],
-which uses ticket-granting ticket session keys in lieu of secret server keys
-in situa- tions where such secret keys could be easily comprom- ised.
-
-[18] For the purpose of appending, the realm preceding the first listed
-realm is considered to be the null realm ("").
-
-[19] For the purpose of interpreting null subfields, the client's realm is
-considered to precede those in the transited field, and the server's realm
-is considered to follow them.
-
-[20] This means that a client and server running on the same host and
-communicating with one another using the KRB_SAFE messages should not share
-a common replay cache to detect KRB_SAFE replays.
-
-[21] The implementation of the Kerberos server need not combine the database
-and the server on the same machine; it is feasible to store the principal
-database in, say, a network name service, as long as the entries stored
-therein are protected from disclosure to and modification by unauthorized
-parties. However, we recommend against such strategies, as they can make
-system management and threat analysis quite complex.
-
-[22] See the discussion of the padata field in section 5.4.2 for details on
-why this can be useful.
-
-[23] Warning for implementations that unpack and repack data structures
-during the generation and verification of embedded checksums: Because any
-checksums applied to data structures must be checked against the original
-data the length of bit strings must be preserved within a data structure
-between the time that a checksum is generated through transmission to the
-time that the checksum is verified.
-
-[24] It is NOT recommended that this time value be used to adjust the
-workstation's clock since the workstation cannot reliably determine that
-such a KRB_AS_REP actually came from the proper KDC in a timely manner.
-
-[25] Note, however, that if the time is used as the nonce, one must make
-sure that the workstation time is monotonically increasing. If the time is
-ever reset backwards, there is a small, but finite, probability that a nonce
-will be reused.
-
-[27] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[29] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[31] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 25 December,
-1999
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-04          June 25,
-1999
-
-[32] If supported by the encryption method in use, an initialization vector
-may be passed to the encryption procedure, in order to achieve proper cipher
-chaining. The initialization vector might come from the last block of the
-ciphertext from the previous KRB_PRIV message, but it is the application's
-choice whether or not to use such an initialization vector. If left out, the
-default initialization vector for the encryption algorithm will be used.
-
-[33] This prevents an attacker who generates an incorrect AS request from
-obtaining verifiable plaintext for use in an off-line password guessing
-attack.
-
-[35] In the above specification, UNTAGGED OCTET STRING(length) is the
-notation for an octet string with its tag and length removed. It is not a
-valid ASN.1 type. The tag bits and length must be removed from the
-confounder since the purpose of the confounder is so that the message starts
-with random data, but the tag and its length are fixed. For other fields,
-the length and tag would be redundant if they were included because they are
-specified by the encryption type. [36] The ordering of the fields in the
-CipherText is important. Additionally, messages encoded in this format must
-include a length as part of the msg-seq field. This allows the recipient to
-verify that the message has not been truncated. Without a length, an
-attacker could use a chosen plaintext attack to generate a message which
-could be truncated, while leaving the checksum intact. Note that if the
-msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length
-is part of that encoding.
-
-[37] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[38] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[39] A variant of the key is used to limit the use of a key to a particular
-function, separating the functions of generating a checksum from other
-encryption performed using the session key. The constant F0F0F0F0F0F0F0F0
-was chosen because it maintains key parity. The properties of DES precluded
-the use of the complement. The same constant is used for similar purpose in
-the Message Integrity Check in the Privacy Enhanced Mail standard.
-
-[40] This error carries additional information in the e- data field. The
-contents of the e-data field for this message is described in section 5.9.1.
diff --git a/crypto/heimdal/kadmin/kadmin.cat8 b/crypto/heimdal/kadmin/kadmin.cat8
deleted file mode 100644
index 31885a7ba67b..000000000000
--- a/crypto/heimdal/kadmin/kadmin.cat8
+++ /dev/null
@@ -1,123 +0,0 @@
-
-KADMIN(8)                UNIX System Manager's Manual                KADMIN(8)
-
-NNAAMMEE
-     kkaaddmmiinn - Kerberos administration utility
-
-SSYYNNOOPPSSIISS
-     kkaaddmmiinn [--pp _s_t_r_i_n_g | ----pprriinncciippaall==_s_t_r_i_n_g] [--KK _s_t_r_i_n_g | ----kkeeyyttaabb==_s_t_r_i_n_g] [--cc
-     _f_i_l_e | ----ccoonnffiigg--ffiillee==_f_i_l_e] [--kk _f_i_l_e | ----kkeeyy--ffiillee==_f_i_l_e] [--rr _r_e_a_l_m |
-     ----rreeaallmm==_r_e_a_l_m] [--aa _h_o_s_t | ----aaddmmiinn--sseerrvveerr==_h_o_s_t] [--ss _p_o_r_t _n_u_m_b_e_r |
-     ----sseerrvveerr--ppoorrtt==_p_o_r_t _n_u_m_b_e_r] [--ll | ----llooccaall] [--hh | ----hheellpp] [--vv | ----vveerrssiioonn]
-     [_c_o_m_m_a_n_d]
-
-DDEESSCCRRIIPPTTIIOONN
-     The kkaaddmmiinn program is used to make modification to the Kerberos database,
-     either remotely via the kadmind(8) daemon, or locally (with the --ll op-
-     tion).
-
-     Supported options:
-
-     --pp _s_t_r_i_n_g, ----pprriinncciippaall==_s_t_r_i_n_g
-             principal to authenticate as
-
-     --KK _s_t_r_i_n_g, ----kkeeyyttaabb==_s_t_r_i_n_g
-             keytab for authentication pricipal
-
-     --cc _f_i_l_e, ----ccoonnffiigg--ffiillee==_f_i_l_e
-             location of config file
-
-     --kk _f_i_l_e, ----kkeeyy--ffiillee==_f_i_l_e
-             location of master key file
-
-     --rr _r_e_a_l_m, ----rreeaallmm==_r_e_a_l_m
-             realm to use
-
-     --aa _h_o_s_t, ----aaddmmiinn--sseerrvveerr==_h_o_s_t
-             server to contact
-
-     --ss _p_o_r_t _n_u_m_b_e_r, ----sseerrvveerr--ppoorrtt==_p_o_r_t _n_u_m_b_e_r
-             port to use
-
-     --ll, ----llooccaall
-             local admin mode
-
-     If no _c_o_m_m_a_n_d is given on the command line, kkaaddmmiinn will prompt for com-
-     mands to process. Commands include:
-
-           aadddd [--rr | ----rraannddoomm--kkeeyy] [----rraannddoomm--ppaasssswwoorrdd] [--pp _s_t_r_i_n_g |
-           ----ppaasssswwoorrdd==_s_t_r_i_n_g] [----kkeeyy==_s_t_r_i_n_g] [----mmaaxx--ttiicckkeett--lliiffee==_l_i_f_e_t_i_m_e]
-           [----mmaaxx--rreenneewwaabbllee--lliiffee==_l_i_f_e_t_i_m_e] [----aattttrriibbuutteess==_a_t_t_r_i_b_u_t_e_s]
-           [----eexxppiirraattiioonn--ttiimmee==_t_i_m_e] [----ppww--eexxppiirraattiioonn--ttiimmee==_t_i_m_e] _p_r_i_n_c_i_p_a_l_._._.
-
-                 creates a new principal
-
-           ppaasssswwdd [--rr | ----rraannddoomm--kkeeyy] [----rraannddoomm--ppaasssswwoorrdd] [--pp _s_t_r_i_n_g |
-           ----ppaasssswwoorrdd==_s_t_r_i_n_g] [----kkeeyy==_s_t_r_i_n_g] _p_r_i_n_c_i_p_a_l_._._.
-
-                 changes the password of an existing principal
-
-           ddeelleettee _p_r_i_n_c_i_p_a_l_._._.
-
-                 removes a principal
-
-           ddeell__eennccttyyppee _p_r_i_n_c_i_p_a_l _e_n_c_t_y_p_e_s_._._.
-
-
-                 removes some enctypes from a principal, this can be useful
-                 the service belonging to the principal is known to not handle
-                 certain enctypes
-
-           eexxtt__kkeeyyttaabb [--kk _s_t_r_i_n_g | ----kkeeyyttaabb==_s_t_r_i_n_g] _p_r_i_n_c_i_p_a_l_._._.
-
-                 creates a keytab with the keys of the specified principals
-
-           ggeett [--ll | ----lloonngg] [--ss | ----sshhoorrtt] [--tt | ----tteerrssee] _e_x_p_r_e_s_s_i_o_n_._._.
-
-                 lists the principals that match the expressions (which are
-                 shell glob like), long format gives more information, and
-                 terse just prints the names
-
-           rreennaammee _f_r_o_m _t_o
-
-                 renames a principal
-
-           mmooddiiffyy [--aa _a_t_t_r_i_b_u_t_e_s | ----aattttrriibbuutteess==_a_t_t_r_i_b_u_t_e_s]
-           [----mmaaxx--ttiicckkeett--lliiffee==_l_i_f_e_t_i_m_e] [----mmaaxx--rreenneewwaabbllee--lliiffee==_l_i_f_e_t_i_m_e]
-           [----eexxppiirraattiioonn--ttiimmee==_t_i_m_e] [----ppww--eexxppiirraattiioonn--ttiimmee==_t_i_m_e]
-           [----kkvvnnoo==_n_u_m_b_e_r] _p_r_i_n_c_i_p_a_l
-
-                 modifies certain attributes of a principal
-
-           pprriivviilleeggeess
-
-                 lists the operations you are allowd to perform
-
-     When running in local mode, the following commands can also be used.
-
-           dduummpp [--dd | ----ddeeccrryypptt] [_d_u_m_p_-_f_i_l_e]
-
-                 writes the database in ``human readable'' form to the speci-
-                 fied file, or standard out
-
-           iinniitt [----rreeaallmm--mmaaxx--ttiicckkeett--lliiffee==_s_t_r_i_n_g]
-           [----rreeaallmm--mmaaxx--rreenneewwaabbllee--lliiffee==_s_t_r_i_n_g] _r_e_a_l_m
-
-                 initialises the Kerberos database with entries for a new
-                 realm, it's possible to have more than one realm served by
-                 one server
-
-           llooaadd _f_i_l_e
-
-                 reads a previously dumped database, and re-creates that
-                 database from scratch
-
-           mmeerrggee _f_i_l_e
-
-                 similar to lliisstt but just modifies the database with the en-
-                 tries in the dump file
-
-SSEEEE AALLSSOO
-     kadmind(8),  kdc(8)
-
- HEIMDAL                      September 10, 2000                             2
diff --git a/crypto/heimdal/kadmin/kadmind.cat8 b/crypto/heimdal/kadmin/kadmind.cat8
deleted file mode 100644
index c03ae18ea4e5..000000000000
--- a/crypto/heimdal/kadmin/kadmind.cat8
+++ /dev/null
@@ -1,93 +0,0 @@
-
-KADMIND(8)               UNIX System Manager's Manual               KADMIND(8)
-
-NNAAMMEE
-     kkaaddmmiinndd - server for administrative access to kerberos database
-
-SSYYNNOOPPSSIISS
-     kkaaddmmiinndd [--cc _f_i_l_e | ----ccoonnffiigg--ffiillee==_f_i_l_e] [--kk _f_i_l_e | ----kkeeyy--ffiillee==_f_i_l_e]
-     [----kkeeyyttaabb==_k_e_y_t_a_b] [--rr _r_e_a_l_m | ----rreeaallmm==_r_e_a_l_m] [--dd | ----ddeebbuugg] [--pp _p_o_r_t |
-     ----ppoorrttss==_p_o_r_t]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkaaddmmiinndd listens for requests for changes to the Kerberos database and
-     performs these, subject to permissions.  When starting, if stdin is a
-     socket it assumes that it has been started by inetd(8),  otherwise it be-
-     haves as a daemon, forking processes for each new connection. The ----ddeebbuugg
-     option causes kkaaddmmiinndd to accept exactly one connection, which is useful
-     for debugging.
-
-     If built with krb4 support, it implements both the Heimdal Kerberos 5 ad-
-     ministrative protocol and the Kerberos 4 protocol. Password changes via
-     the Kerberos 4 protocol are also performed by kkaaddmmiinndd, but the kpass-
-     wdd(8) daemon is responsible for the Kerberos 5 password changing proto-
-     col (used by kpasswd(1))
-
-     This daemon should only be run on ther master server, and not on any
-     slaves.
-
-     Principals are always allowed to change their own password and list their
-     own principals.  Apart from that, doing any operation requires permission
-     explicitly added in the ACL file _/_v_a_r_/_h_e_i_m_d_a_l_/_k_a_d_m_i_n_d_._a_c_l. The format of
-     this file is:
-
-     _p_r_i_n_c_i_p_a_l _r_i_g_h_t_s [_p_r_i_n_c_i_p_a_l_-_p_a_t_t_e_r_n]
-
-     Where rights is any combination of:
-
-     ++oo   change-password | cpw
-
-     ++oo   list
-
-     ++oo   delete
-
-     ++oo   modify
-
-     ++oo   add
-
-     ++oo   get
-
-     ++oo   all
-
-     And the optional _p_r_i_n_c_i_p_a_l_-_p_a_t_t_e_r_n restricts the rights to principals
-     that match the glob-style pattern.
-
-     Supported options:
-
-     --cc _f_i_l_e, ----ccoonnffiigg--ffiillee==_f_i_l_e
-             location of config file
-
-     --kk _f_i_l_e, ----kkeeyy--ffiillee==_f_i_l_e
-             location of master key file
-
-     ----kkeeyyttaabb==_k_e_y_t_a_b
-
-
-             what keytab to use
-
-     --rr _r_e_a_l_m, ----rreeaallmm==_r_e_a_l_m
-             realm to use
-
-     --dd, ----ddeebbuugg
-             enable debugging
-
-     --pp _p_o_r_t, ----ppoorrttss==_p_o_r_t
-             ports to listen to. By default, if run as a daemon, it listen to
-             ports 749, and 751 (if built with Kerberos 4 support), but you
-             can add any number of ports with this option. The port string is
-             a whitespace separated list of port specifications, with the spe-
-             cial string ``+'' representing the default set of ports.
-
-FFIILLEESS
-     _/_v_a_r_/_h_e_i_m_d_a_l_/_k_a_d_m_i_n_d_._a_c_l
-
-EEXXAAMMPPLLEESS
-     This will cause kadmind to listen to port 4711 in addition to any com-
-     piled in defaults:
-
-           # kadmind --ports="+ 4711" &
-
-SSEEEE AALLSSOO
-     kdc(8),  kadmin(1),  kpasswdd(8),  kpasswd(1)
-
- HEIMDAL                         June 7, 2000                                2
diff --git a/crypto/heimdal/kdc/hprop-common.c b/crypto/heimdal/kdc/hprop-common.c
deleted file mode 100644
index 660725f68883..000000000000
--- a/crypto/heimdal/kdc/hprop-common.c
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
- * Copyright (c) 1997, 1998 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-#include "hprop.h"
-
-RCSID("$Id: hprop-common.c,v 1.7 1999/12/02 17:04:59 joda Exp $");
-
-krb5_error_code 
-send_priv(krb5_context context, krb5_auth_context ac,
-	  krb5_data *data, int fd)
-{
-    krb5_data packet;
-    krb5_error_code ret;
-
-    ret = krb5_mk_priv (context,
-			ac,
-			data,
-			&packet,
-			NULL);
-    if (ret)
-	return ret;
-    
-    ret = krb5_write_message (context, &fd, &packet);
-    krb5_data_free(&packet);
-    return ret;
-}
-
-krb5_error_code
-recv_priv(krb5_context context, krb5_auth_context ac, int fd, krb5_data *out)
-{
-    krb5_error_code ret;
-    krb5_data data;
-
-    ret = krb5_read_message (context, &fd, &data);
-    if (ret)
-	return ret;
-
-    ret = krb5_rd_priv(context, ac, &data, out, NULL);
-    krb5_data_free (&data);
-    return ret;
-}
-
-krb5_error_code
-send_clear(krb5_context context, int fd, krb5_data data)
-{
-    return krb5_write_message (context, &fd, &data);
-}
-
-krb5_error_code
-recv_clear(krb5_context context, int fd, krb5_data *out)
-{
-    return krb5_read_message (context, &fd, out);
-}
diff --git a/crypto/heimdal/kdc/hprop.cat8 b/crypto/heimdal/kdc/hprop.cat8
deleted file mode 100644
index f6c70b4ca62c..000000000000
--- a/crypto/heimdal/kdc/hprop.cat8
+++ /dev/null
@@ -1,103 +0,0 @@
-
-HPROP(8)                 UNIX System Manager's Manual                 HPROP(8)
-
-NNAAMMEE
-     hhpprroopp - propagate the KDC database
-
-SSYYNNOOPPSSIISS
-     hhpprroopp [--mm _f_i_l_e | ----mmaasstteerr--kkeeyy==_f_i_l_e] [--dd _f_i_l_e | ----ddaattaabbaassee==_f_i_l_e]
-     [----ssoouurrccee==_h_e_i_m_d_a_l_|_m_i_t_-_d_u_m_p_|_k_r_b_4_-_d_b_|_k_r_b_4_-_d_u_m_p] [--44 | ----vv44--ddbb] [--KK |
-     ----kkaa--ddbb] [--cc _c_e_l_l | ----cceellll==_c_e_l_l] [--SS | ----kkaassppeecciiaallss] [--rr _s_t_r_i_n_g |
-     ----vv44--rreeaallmm==_s_t_r_i_n_g] [--kk _k_e_y_t_a_b | ----kkeeyyttaabb==_k_e_y_t_a_b] [--RR _s_t_r_i_n_g |
-     ----vv55--rreeaallmm==_s_t_r_i_n_g] [--DD | ----ddeeccrryypptt] [--EE | ----eennccrryypptt] [--nn | ----ssttddoouutt] [--vv
-     | ----vveerrbboossee] [----vveerrssiioonn] [--hh | ----hheellpp] _h_o_s_t[:_p_o_r_t] _._._.
-
-DDEESSCCRRIIPPTTIIOONN
-     hhpprroopp takes a principal database in a specified format and converts it
-     into a stream of Heimdal database records. This stream can either be
-     written to standard out, or (more commonly) be propagated to a hpropd(8)
-     server running on a different machine.
-
-     If propagating, it connects to all _h_o_s_t_s specified on the command by
-     opening a TCP connection to port 754 (service hprop) and sends the
-     database in encrypted form.
-
-     Supported options:
-
-     --mm _f_i_l_e, ----mmaasstteerr--kkeeyy==_f_i_l_e
-             Where to find the master key to encrypt or decrypt keys with.
-
-     --dd _f_i_l_e, ----ddaattaabbaassee==_f_i_l_e
-             The database to be propagated.
-
-     ----ssoouurrccee==_h_e_i_m_d_a_l_|_m_i_t_-_d_u_m_p_|_k_r_b_4_-_d_b_|_k_r_b_4_-_d_u_m_p
-             Specifies the type of the source database. Alternatives include:
-
-             heimdal    a Heimdal database
-
-             mit-dump   a MIT Kerberos 5 dump file
-
-             krb4-db    a Kerberos 4 database
-
-             krb4-dump  a Kerberos 4 dump file
-
-             kaserver   a Transarc kaserver database
-
-     --kk _k_e_y_t_a_b, ----kkeeyyttaabb==_k_e_y_t_a_b
-             The keytab to use for fetching the key to be used for authenti-
-             cating to the propagation daemon(s). The key _k_a_d_m_i_n_/_h_p_r_o_p is used
-             from this keytab.  The default is to fetch the key from the KDC
-             database.
-
-     --RR _s_t_r_i_n_g, ----vv55--rreeaallmm==_s_t_r_i_n_g
-             Local realm override.
-
-     --DD, ----ddeeccrryypptt
-             The encryption keys in the database can either be in clear, or
-             encrypted with a master key. This option thansmits the database
-             with unencrypted keys.
-
-     --EE, ----eennccrryypptt
-             This option thansmits the database with encrypted keys.
-
-     --nn, ----ssttddoouutt
-             Dump the database on stdout, in a format that can be fed to
-             hpropd.
-
-     The following options are only valid if hhpprroopp is compiled with support
-     for Kerberos 4 (kaserver).
-
-     --rr _s_t_r_i_n_g, ----vv44--rreeaallmm==_s_t_r_i_n_g
-             v4 realm to use
-
-     --cc _c_e_l_l, ----cceellll==_c_e_l_l
-             The AFS cell name, used if reading a kaserver database.
-
-     --SS, ----kkaassppeecciiaallss
-             Also dump the principals marked as special in the kaserver
-             database.
-
-     --44, ----vv44--ddbb
-             Deprecated, identical to `--source=krb4-db'.
-
-     --KK, ----kkaa--ddbb
-             Deprecated, identical to `--source=kaserver'.
-
-EEXXAAMMPPLLEESS
-     The following will propagate a database to another machine (which should
-     run hpropd(8):)
-
-           $ hprop slave-1 slave-2
-
-     Copy a Kerberos 4 database to a Kerberos 5 slave:
-
-           $ hprop --source=krb4-db -E krb5-slave
-
-     Convert a Kerberos 4 dump-file for use with a Heimdal KDC:
-
-           $ hprop -n --source=krb4-dump -d /var/kerberos/principal.dump -E | hpropd -n
-
-SSEEEE AALLSSOO
-     hpropd(8)
-
- HEIMDAL                         June 19, 2000                               2
diff --git a/crypto/heimdal/kdc/hpropd.cat8 b/crypto/heimdal/kdc/hpropd.cat8
deleted file mode 100644
index 5218e6d12d55..000000000000
--- a/crypto/heimdal/kdc/hpropd.cat8
+++ /dev/null
@@ -1,43 +0,0 @@
-
-HPROPD(8)                UNIX System Manager's Manual                HPROPD(8)
-
-NNAAMMEE
-     hhpprrooppdd - receive a propagated database
-
-SSYYNNOOPPSSIISS
-     hhpprrooppdd [--dd _f_i_l_e | ----ddaattaabbaassee==_f_i_l_e] [--nn | ----ssttddiinn] [----pprriinntt] [--ii |
-     ----nnoo--iinneettdd] [--kk _k_e_y_t_a_b | ----kkeeyyttaabb==_k_e_y_t_a_b] [--44 | ----vv44dduummpp]
-
-DDEESSCCRRIIPPTTIIOONN
-     hhpprrooppdd receives databases sent by hhpprroopp. and writes it as a local
-     database.
-
-     By default, hhpprrooppdd expects to be started from iinneettdd if stdin is a socket
-     and expects to receive the dumped database over stdin otherwise.  If the
-     database is sent over the network, it is authenticated and encrypted.
-     Only connections from kadmin/hprop are accepted.
-
-     Options supported:
-
-     --dd _f_i_l_e, ----ddaattaabbaassee==_f_i_l_e
-             database
-
-     --nn, ----ssttddiinn
-             read from stdin
-
-     ----pprriinntt
-             print dump to stdout
-
-     --ii, ----nnoo--iinneettdd
-             Not started from inetd
-
-     --kk _k_e_y_t_a_b, ----kkeeyyttaabb==_k_e_y_t_a_b
-             keytab to use for authentication
-
-     --44, ----vv44dduummpp
-             create v4 type DB
-
-SSEEEE AALLSSOO
-     hprop(8)
-
- HEIMDAL                        August 27, 1997                              1
diff --git a/crypto/heimdal/kdc/kdc.cat8 b/crypto/heimdal/kdc/kdc.cat8
deleted file mode 100644
index 234b76dc97b5..000000000000
--- a/crypto/heimdal/kdc/kdc.cat8
+++ /dev/null
@@ -1,118 +0,0 @@
-
-KDC(8)                   UNIX System Manager's Manual                   KDC(8)
-
-NNAAMMEE
-     kkddcc - Kerberos 5 server
-
-SSYYNNOOPPSSIISS
-     kkddcc [--cc _f_i_l_e | ----ccoonnffiigg--ffiillee==_f_i_l_e] [--pp | ----nnoo--rreeqquuiirree--pprreeaauutthh]
-     [----mmaaxx--rreeqquueesstt==_s_i_z_e] [--HH | ----eennaabbllee--hhttttpp] [--rr _s_t_r_i_n_g | ----vv44--rreeaallmm==_s_t_r_i_n_g]
-     [--KK | ----nnoo--kkaasseerrvveerr] [--rr _r_e_a_l_m] [----vv44--rreeaallmm==_r_e_a_l_m] [--PP _s_t_r_i_n_g |
-     ----ppoorrttss==_s_t_r_i_n_g] [----aaddddrreesssseess==_l_i_s_t _o_f _a_d_d_r_e_s_s_e_s]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkddcc serves requests for tickets. When it starts, it first checks the
-     flags passed, any options that are not specified with a command line flag
-     is taken from a config file, or from a default compiled-in value.
-
-     Options supported:
-
-     --cc _f_i_l_e
-
-     ----ccoonnffiigg--ffiillee==_f_i_l_e
-             Specifies the location of the config file, the default is
-             _/_v_a_r_/_h_e_i_m_d_a_l_/_k_d_c_._c_o_n_f. This is the only value that can't be spec-
-             ified in the config file.
-
-     --pp
-
-     ----nnoo--rreeqquuiirree--pprreeaauutthh
-             Turn off the requirement for pre-autentication in the initial AS-
-             REQ for all principals. The use of pre-authentication makes it
-             more difficult to do offline password attacks. You might want to
-             turn it off if you have clients that doesn't do pre-authentica-
-             tion. Since the version 4 protocol doesn't support any pre-au-
-             thentication, so serving version 4 clients is just about the same
-             as not requiring pre-athentication. The default is to require
-             pre-authentication. Adding the require-preauth per principal is a
-             more flexible way of handling this.
-
-     ----mmaaxx--rreeqquueesstt==_s_i_z_e
-             Gives an upper limit on the size of the requests that the kdc is
-             willing to handle.
-
-     --HH, ----eennaabbllee--hhttttpp
-             Makes the kdc listen on port 80 and handle requests encapsulated
-             in HTTP.
-
-     --KK, ----nnoo--kkaasseerrvveerr
-             Disables kaserver emulation (in case it's compiled in).
-
-     --rr _r_e_a_l_m
-
-     ----vv44--rreeaallmm==_r_e_a_l_m
-             What realm this server should act as when dealing with version 4
-             requests. The database can contain any number of realms, but
-             since the version 4 protocol doesn't contain a realm for the
-             server, it must be explicitly specified. The default is whatever
-             is returned by kkrrbb__ggeett__llrreeaallmm().  This option is only availabe if
-             the KDC has been compiled with version 4 support.
-
-     --PP _s_t_r_i_n_g, ----ppoorrttss==_s_t_r_i_n_g
-             Specifies the set of ports the KDC should listen on.  It is given
-             as a white-space separated list of services or port numbers.
-
-     ----aaddddrreesssseess==_l_i_s_t _o_f _a_d_d_r_e_s_s_e_s
-             The list of addresses to listen for requests on.  By default, the
-             kdc will listen on all the locally configured addresses.  If only
-             a subset is desired, or the automatic detection fails, this op-
-             tion might be used.
-
-     All activities , are logged to one or more destinations, see
-     krb5.conf(5),  and krb5_openlog(3).  The entity used for logging is kkddcc.
-
-CCOONNFFIIGGUURRAATTIIOONN FFIILLEE
-     The configuration file has the same syntax as the _k_r_b_5_._c_o_n_f file (you can
-     actually put the configuration in _/_e_t_c_/_k_r_b_5_._c_o_n_f, and then start the KDC
-     with ----ccoonnffiigg--ffiillee==_/_e_t_c_/_k_r_b_5_._c_o_n_f). All options should be in a section
-     called ``kdc''. All the command-line options can preferably be added in
-     the configuration file.  The only difference is the pre-authentication
-     flag, that has to be specified as:
-
-           require-preauth = no
-
-     (in fact you can specify the option as ----rreeqquuiirree--pprreeaauutthh==nnoo).
-
-     And there are some configuration options which do not have command-line
-     equivalents:
-
-           check-ticket-addresses = _b_o_o_l_e_a_n
-                Check the addresses in the ticket when processing TGS re-
-                quests.  The default is FALSE.
-
-           allow-null-ticket-addresses = _b_o_o_l_e_a_n
-                Permit tickets with no addresses.  This option is only rele-
-                vant when check-ticket-addresses is TRUE.
-
-           allow-anonymous = _b_o_o_l_e_a_n
-                Permit anonymous tickets with no addresses.
-
-           encode_as_rep_as_tgs_rep = _b_o_o_l_e_a_n
-                Encode AS-Rep as TGS-Rep to be bug-compatible with old DCE
-                code.  The Heimdal clients allow both.
-
-           kdc_warn_pwexpire = _t_i_m_e
-                How long before password/principal expiration the KDC should
-                start sending out warning messages.
-
-     An example of a config file:
-
-           [kdc]
-                   require-preauth = no
-                   v4-realm = FOO.SE
-                   key-file = /key-file
-
-SSEEEE AALLSSOO
-     kinit(1)
-
- HEIMDAL                         July 27, 1997                               2
diff --git a/crypto/heimdal/kdc/kerberos4.h b/crypto/heimdal/kdc/kerberos4.h
deleted file mode 100644
index 5bf3c2bc5502..000000000000
--- a/crypto/heimdal/kdc/kerberos4.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * Copyright (c) 1997 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-/* $Id: kerberos4.h,v 1.2 1999/12/02 17:04:59 joda Exp $ */
-
-#ifndef __KERBEROS4_H__
-#define __KERBEROS4_H__
-
-hdb_entry* db_fetch4(const char *name,
-		     const char *instance,
-		     const char *realm);
-
-#endif /* __KERBEROS4_H__ */
diff --git a/crypto/heimdal/kdc/kstash.cat8 b/crypto/heimdal/kdc/kstash.cat8
deleted file mode 100644
index 7dd2c7a7c75b..000000000000
--- a/crypto/heimdal/kdc/kstash.cat8
+++ /dev/null
@@ -1,34 +0,0 @@
-
-KSTASH(8)                UNIX System Manager's Manual                KSTASH(8)
-
-NNAAMMEE
-     kkssttaasshh - store the KDC master password in a file
-
-SSYYNNOOPPSSIISS
-     kkssttaasshh [--ee _s_t_r_i_n_g | ----eennccttyyppee==_s_t_r_i_n_g] [--kk _f_i_l_e | ----kkeeyy--ffiillee==_f_i_l_e]
-     [----ccoonnvveerrtt--ffiillee] [----mmaasstteerr--kkeeyy--ffdd==_f_d] [--hh | ----hheellpp] [----vveerrssiioonn]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkssttaasshh reads the Kerberos master key and stores it in a file that will be
-     used by the KDC.
-
-     Supported options:
-
-     --ee _s_t_r_i_n_g, ----eennccttyyppee==_s_t_r_i_n_g
-             the encryption type to use, defaults to DES3-CBC-SHA1
-
-     --kk _f_i_l_e, ----kkeeyy--ffiillee==_f_i_l_e
-             the name of the master key file
-
-     ----ccoonnvveerrtt--ffiillee
-             don't ask for a new master key, just read an old master key file,
-             and writes it back in the new keyfile format
-
-     ----mmaasstteerr--kkeeyy--ffdd==_f_d
-             filedescriptor to read passphrase from, if not specified the
-             passphrase will be read from the terminal
-
-SSEEEE AALLSSOO
-     kdc(8)
-
- HEIMDAL                       September 1, 2000                             1
diff --git a/crypto/heimdal/kdc/string2key.cat8 b/crypto/heimdal/kdc/string2key.cat8
deleted file mode 100644
index d70e150b50b5..000000000000
--- a/crypto/heimdal/kdc/string2key.cat8
+++ /dev/null
@@ -1,42 +0,0 @@
-
-STRING2KEY(8)            UNIX System Manager's Manual            STRING2KEY(8)
-
-NNAAMMEE
-     ssttrriinngg22kkeeyy - map a password into a key
-
-SSYYNNOOPPSSIISS
-     ssttrriinngg22kkeeyy [--55 | ----vveerrssiioonn55] [--44 | ----vveerrssiioonn44] [--aa | ----aaffss] [--cc _c_e_l_l |
-     ----cceellll==_c_e_l_l] [--ww _p_a_s_s_w_o_r_d | ----ppaasssswwoorrdd==_p_a_s_s_w_o_r_d] [--pp _p_r_i_n_c_i_p_a_l |
-     ----pprriinncciippaall==_p_r_i_n_c_i_p_a_l] [--kk _s_t_r_i_n_g | ----kkeeyyttyyppee==_s_t_r_i_n_g] _p_a_s_s_w_o_r_d
-
-DDEESSCCRRIIPPTTIIOONN
-     ssttrriinngg22kkeeyy performs the string-to-key function.  This is useful when you
-     want to handle the raw key instead of the password.  Supported options:
-
-     --55, ----vveerrssiioonn55
-             Output Kerberos v5 string-to-key
-
-     --44, ----vveerrssiioonn44
-             Output Kerberos v4 string-to-key
-
-     --aa, ----aaffss
-             Output AFS string-to-key
-
-     --cc _c_e_l_l, ----cceellll==_c_e_l_l
-             AFS cell to use
-
-     --ww _p_a_s_s_w_o_r_d, ----ppaasssswwoorrdd==_p_a_s_s_w_o_r_d
-             Password to use
-
-     --pp _p_r_i_n_c_i_p_a_l, ----pprriinncciippaall==_p_r_i_n_c_i_p_a_l
-             Kerberos v5 principal to use
-
-     --kk _s_t_r_i_n_g, ----kkeeyyttyyppee==_s_t_r_i_n_g
-             Keytype
-
-     ----vveerrssiioonn
-             print version
-
-     ----hheellpp
-
- HEIMDAL                         March 4, 2000                               1
diff --git a/crypto/heimdal/kpasswd/kpasswd.cat1 b/crypto/heimdal/kpasswd/kpasswd.cat1
deleted file mode 100644
index 874fb22fd340..000000000000
--- a/crypto/heimdal/kpasswd/kpasswd.cat1
+++ /dev/null
@@ -1,20 +0,0 @@
-
-KPASSWD(1)                   UNIX Reference Manual                  KPASSWD(1)
-
-NNAAMMEE
-     kkppaasssswwdd - Kerberos 5 password changing program
-
-SSYYNNOOPPSSIISS
-     kkppaasssswwdd [_p_r_i_n_c_i_p_a_l]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkppaasssswwdd is the client for changing passwords.
-
-DDIIAAGGNNOOSSTTIICCSS
-     If the password quality check fails or some other error occurs, an expla-
-     nation is printed.
-
-SSEEEE AALLSSOO
-     kpasswdd(8)
-
- HEIMDAL                         Aug 27, 1997                                1
diff --git a/crypto/heimdal/kpasswd/kpasswdd.cat8 b/crypto/heimdal/kpasswd/kpasswdd.cat8
deleted file mode 100644
index b7d2e8dc91f8..000000000000
--- a/crypto/heimdal/kpasswd/kpasswdd.cat8
+++ /dev/null
@@ -1,54 +0,0 @@
-
-KPASSWDD(8)              UNIX System Manager's Manual              KPASSWDD(8)
-
-NNAAMMEE
-     kkppaasssswwdddd - Kerberos 5 password changing server
-
-SSYYNNOOPPSSIISS
-     kkppaasssswwdddd [----cchheecckk--lliibbrraarryy==_l_i_b_r_a_r_y] [----cchheecckk--ffuunnccttiioonn==_f_u_n_c_t_i_o_n] [--kk _k_s_p_e_c
-     | ----kkeeyyttaabb==_k_s_p_e_c] [--rr _r_e_a_l_m | ----rreeaallmm==_r_e_a_l_m] [--pp _s_t_r_i_n_g | ----ppoorrtt==_s_t_r_i_n_g]
-     [----vveerrssiioonn] [----hheellpp]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkppaasssswwdddd serves request for password changes. It listens on UDP port 464
-     (service kpasswd) and processes requests when they arrive. It changes the
-     database directly and should thus only run on the master KDC.
-
-     Supported options:
-
-     ----cchheecckk--lliibbrraarryy==_l_i_b_r_a_r_y
-             If your system has support for dynamic loading of shared li-
-             braries, you can use an external function to check password qual-
-             ity. This option specifies which library to load.
-
-     ----cchheecckk--ffuunnccttiioonn==_f_u_n_c_t_i_o_n
-             This is the function to call in the loaded library. The function
-             should look like this:
-
-             _c_o_n_s_t _c_h_a_r _* ppaasssswwdd__cchheecckk(_k_r_b_5___c_o_n_t_e_x_t _c_o_n_t_e_x_t, _k_r_b_5___p_r_i_n_c_i_p_a_l
-             _p_r_i_n_c_i_p_a_l, _k_r_b_5___d_a_t_a _*_p_a_s_s_w_o_r_d)
-
-             _c_o_n_t_e_x_t is an initialized context; _p_r_i_n_c_i_p_a_l is the one who tries
-             to change passwords, and _p_a_s_s_w_o_r_d is the new password. Note that
-             the password (in _p_a_s_s_w_o_r_d_-_>_d_a_t_a) is not zero terminated.
-
-     --kk _k_s_p_e_c, ----kkeeyyttaabb==_k_s_p_e_c
-             keytab to get authentication key from
-
-     --rr _r_e_a_l_m, ----rreeaallmm==_r_e_a_l_m
-             default realm
-
-     --pp _s_t_r_i_n_g, ----ppoorrtt==_s_t_r_i_n_g
-             port to listen on (default service kpasswd - 464).
-
-DDIIAAGGNNOOSSTTIICCSS
-     If an error occurs, the error message is returned to the user and/or
-     logged to syslog.
-
-BBUUGGSS
-     The default password quality checks are too basic.
-
-SSEEEE AALLSSOO
-     kdc(8),  kpasswd(1)
-
- HEIMDAL                        April 19, 1999                               1
diff --git a/crypto/heimdal/kuser/kdestroy.cat1 b/crypto/heimdal/kuser/kdestroy.cat1
deleted file mode 100644
index 0949f9687bcc..000000000000
--- a/crypto/heimdal/kuser/kdestroy.cat1
+++ /dev/null
@@ -1,30 +0,0 @@
-
-KDESTROY(1)                  UNIX Reference Manual                 KDESTROY(1)
-
-NNAAMMEE
-     kkddeessttrrooyy - destroy the current ticket file
-
-SSYYNNOOPPSSIISS
-     kkddeessttrrooyy [--cc _c_a_c_h_e_f_i_l_e] [----ccaacchhee==_c_a_c_h_e_f_i_l_e] [----nnoo--uunnlloogg] [----nnoo--ddeelleettee--vv44]
-     [----vveerrssiioonn] [----hheellpp]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkddeessttrrooyy remove the current set of tickets.
-
-     Supported options:
-
-     --cc _c_a_c_h_e_f_i_l_e
-
-     --ccaacchhee==_c_a_c_h_e_f_i_l_e
-             The cache file to remove.
-
-     ----nnoo--uunnlloogg
-             Do not remove AFS tokens.
-
-     ----nnoo--ddeelleettee--vv44
-             Do not remove v4 tickets.
-
-SSEEEE AALLSSOO
-     kinit(1),  klist(1)
-
- HEIMDAL                        August 27, 1997                              1
diff --git a/crypto/heimdal/kuser/kgetcred.cat1 b/crypto/heimdal/kuser/kgetcred.cat1
deleted file mode 100644
index 63a6c983a747..000000000000
--- a/crypto/heimdal/kuser/kgetcred.cat1
+++ /dev/null
@@ -1,27 +0,0 @@
-
-KGETCRED(1)                  UNIX Reference Manual                 KGETCRED(1)
-
-NNAAMMEE
-     kkggeettccrreedd - get a ticket for a particular service
-
-SSYYNNOOPPSSIISS
-     kkggeettccrreedd [--ee _e_n_c_t_y_p_e | ----eennccttyyppee==_e_n_c_t_y_p_e] [----vveerrssiioonn] [----hheellpp] _s_e_r_v_i_c_e
-
-DDEESSCCRRIIPPTTIIOONN
-     kkggeettccrreedd obtains a ticket for a service.  Usually tickets for services
-     are obtained automatically when needed but sometimes for some odd reason
-     you want to obtain a particular ticket or of a special type.
-
-     Supported options:
-
-     --ee _e_n_c_t_y_p_e, ----eennccttyyppee==_e_n_c_t_y_p_e
-             encryption type to use
-
-     ----vveerrssiioonn
-
-     ----hheellpp
-
-SSEEEE AALLSSOO
-     kinit(1),  klist(1)
-
- HEIMDAL                         May 14, 1999                                1
diff --git a/crypto/heimdal/kuser/kinit.cat1 b/crypto/heimdal/kuser/kinit.cat1
deleted file mode 100644
index 350738568291..000000000000
--- a/crypto/heimdal/kuser/kinit.cat1
+++ /dev/null
@@ -1,119 +0,0 @@
-
-KINIT(1)                     UNIX Reference Manual                    KINIT(1)
-
-NNAAMMEE
-     kkiinniitt, kkaauutthh - acquire initial tickets
-
-SSYYNNOOPPSSIISS
-     kkiinniitt [--44 | ----552244iinniitt] [----aaffsslloogg] [--cc _c_a_c_h_e_n_a_m_e | ----ccaacchhee==_c_a_c_h_e_n_a_m_e] [--ff
-           | ----ffoorrwwaarrddaabbllee] [--tt _k_e_y_t_a_b_n_a_m_e | ----kkeeyyttaabb==_k_e_y_t_a_b_n_a_m_e] [--ll _t_i_m_e |
-           ----lliiffeettiimmee==_t_i_m_e] [--pp | ----pprrooxxiiaabbllee] [--RR | ----rreenneeww] [----rreenneewwaabbllee]
-           [--rr _t_i_m_e | ----rreenneewwaabbllee--lliiffee==_t_i_m_e] [--SS _p_r_i_n_c_i_p_a_l |
-           ----sseerrvveerr==_p_r_i_n_c_i_p_a_l] [--ss _t_i_m_e | ----ssttaarrtt--ttiimmee==_t_i_m_e] [--kk |
-           ----uussee--kkeeyyttaabb] [--vv | ----vvaalliiddaattee] [--ee _e_n_c_t_y_p_e | ----eennccttyyppeess==_e_n_c_t_y_p_e]
-           [----ffccaacchhee--vveerrssiioonn==_i_n_t_e_g_e_r] [----nnoo--aaddddrreesssseess] [----aannoonnyymmoouuss]
-           [----vveerrssiioonn] [----hheellpp] [_p_r_i_n_c_i_p_a_l [_c_o_m_m_a_n_d]]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkiinniitt is used to authenticate to the kerberos server as _p_r_i_n_c_i_p_a_l, or if
-     none is given, a system generated default (typically your login name at
-     the default realm), and acquire a ticket granting ticket that can later
-     be used to obtain tickets for other services.
-
-     If you have compiled kinit with Kerberos 4 support and you have a Ker-
-     beros 4 server, kkiinniitt will detect this and get you Kerberos 4 tickets.
-
-     Supported options:
-
-     --cc _c_a_c_h_e_n_a_m_e ----ccaacchhee==_c_a_c_h_e_n_a_m_e
-             The credentials cache to put the acquired ticket in, if other
-             than default.
-
-     --ff, ----ffoorrwwaarrddaabbllee
-             Get ticket that can be forwarded to another host.
-
-     --tt _k_e_y_t_a_b_n_a_m_e, ----kkeeyyttaabb==_k_e_y_t_a_b_n_a_m_e
-             Don't ask for a password, but instead get the key from the speci-
-             fied keytab.
-
-     --ll _t_i_m_e, ----lliiffeettiimmee==_t_i_m_e
-             Specifies the lifetime of the ticket. The argument can either be
-             in seconds, or a more human readable string like `1h'.
-
-     --pp, ----pprrooxxiiaabbllee
-             Request tickets with the proxiable flag set.
-
-     --RR, ----rreenneeww
-             Try to renew ticket. The ticket must have the `renewable' flag
-             set, and must not be expired.
-
-     ----rreenneewwaabbllee
-             The same as ----rreenneewwaabbllee--lliiffee, with an infinite time.
-
-     --rr _t_i_m_e, ----rreenneewwaabbllee--lliiffee==_t_i_m_e
-             The max renewable ticket life.
-
-     --SS _p_r_i_n_c_i_p_a_l, ----sseerrvveerr==_p_r_i_n_c_i_p_a_l
-             Get a ticket for a service other than krbtgt/LOCAL.REALM.
-
-     --ss _t_i_m_e, ----ssttaarrtt--ttiimmee==_t_i_m_e
-             Obtain a ticket that starts to be valid _t_i_m_e (which can really be
-             a generic time specification, like `1h') seconds into the future.
-
-     --kk, ----uussee--kkeeyyttaabb
-             The same as ----kkeeyyttaabb, but with the default keytab name (normally
-
-             _F_I_L_E_:_/_e_t_c_/_k_r_b_5_._k_e_y_t_a_b).
-
-     --vv, ----vvaalliiddaattee
-             Try to validate an invalid ticket.
-
-     --ee, ----eennccttyyppeess==_e_n_c_t_y_p_e_s
-             Request tickets with this particular enctype.
-
-     ----ffccaacchhee--vveerrssiioonn==_v_e_r_s_i_o_n
-             Create a credentials cache of version vveerrssiioonn.
-
-     ----nnoo--aaddddrreesssseess
-             Request a ticket with no addresses.
-
-     ----aannoonnyymmoouuss
-             Request an anonymous ticket (which means that the ticket will be
-             issued to an anonymous principal, typically ``anonymous@REALM).''
-
-     The following options are only available if kkiinniitt has been compiled with
-     support for Kerberos 4. The kkaauutthh program is identical to kkiinniitt, but has
-     these options enabled by default.
-
-     --44, ----552244iinniitt
-             Try to convert the obtained Kerberos 5 krbtgt to a version 4 com-
-             patible ticket. It will store this ticket in the default Kerberos
-             4 ticket file.
-
-     ----aaffsslloogg
-             Gets AFS tickets, converts them to version 4 format, and stores
-             them in the kernel. Only useful if you have AFS.
-
-     The _f_o_r_w_a_r_d_a_b_l_e, _p_r_o_x_i_a_b_l_e, _t_i_c_k_e_t___l_i_f_e, and _r_e_n_e_w_a_b_l_e___l_i_f_e options can
-     be set to a default value from the appdefaults section in krb5.conf, see
-     krb5_appdefault(3).
-
-     If  a _c_o_m_m_a_n_d is given, kkiinniitt will setup new credentials caches, and AFS
-     PAG, and then run the given command. When it finishes the credentials
-     will be removed.
-
-EENNVVIIRROONNMMEENNTT
-     KRB5CCNAME
-             Specifies the default cache file.
-
-     KRB5_CONFIG
-             The directory where the _k_r_b_5_._c_o_n_f can be found, default is _/_e_t_c.
-
-     KRBTKFILE
-             Specifies the Kerberos 4 ticket file to store version 4 tickets
-             in.
-
-SSEEEE AALLSSOO
-     kdestroy(1),  klist(1),  krb5.conf(5),  krb5_appdefault(3)
-
- HEIMDAL                         May 29, 1998                                2
diff --git a/crypto/heimdal/kuser/klist.cat1 b/crypto/heimdal/kuser/klist.cat1
deleted file mode 100644
index 20f2c33d695a..000000000000
--- a/crypto/heimdal/kuser/klist.cat1
+++ /dev/null
@@ -1,89 +0,0 @@
-
-KLIST(1)                     UNIX Reference Manual                    KLIST(1)
-
-NNAAMMEE
-     kklliisstt - list Kerberos credentials
-
-SSYYNNOOPPSSIISS
-     kklliisstt [--cc _c_a_c_h_e | ----ccaacchhee==_c_a_c_h_e] [--ss | --tt | ----tteesstt] [--44 | ----vv44] [--TT |
-     ----ttookkeennss] [--55 | ----vv55] [--vv | ----vveerrbboossee] [--ff] [----vveerrssiioonn] [----hheellpp]
-
-DDEESSCCRRIIPPTTIIOONN
-     kklliisstt reads and displays the current tickets in the crential cache (also
-     known as the ticket file).
-
-     Options supported:
-
-     --cc _c_a_c_h_e, ----ccaacchhee==_c_a_c_h_e
-             credentials cache to list
-
-     --ss, --tt, ----tteesstt
-             Test for there being an active and valid TGT for the local realm
-             of the user in the credential cache.
-
-     --44, ----vv44
-             display v4 tickets
-
-     --TT, ----ttookkeennss
-             display AFS tokens
-
-     --55, ----vv55
-             display v5 cred cache (this is the default)
-
-     --ff      Include ticket flags in short form, each charcted stands for a
-             specific flag, as follows:
-                   F    forwardable
-                   f    forwarded
-                   P    proxiable
-                   p    proxied
-                   D    postdate-able
-                   d    postdated
-                   R    renewable
-                   I    initial
-                   i    invalid
-                   A    pre-authenticated
-                   H    hardware authenticated
-
-             This information is also output with the ----vveerrbboossee option, but in
-             a more verbose way.
-
-     --vv, ----vveerrbboossee
-             Verbose output. Include all possible information:
-
-                   Server
-                         the princial the ticket is for
-
-                   Ticket etype
-                         the encryption type use in the ticket, followed by
-                         the key version of the ticket, if it is available
-
-                   Session key
-                         the encryption type of the session key, if it's dif-
-                         ferent from the encryption type of the ticket
-
-                   Auth time
-
-                         the time the authentication exchange took place
-
-                   Start time
-                         the time that this tickets is valid from (only print-
-                         ed if it's different from the auth time)
-
-                   End time
-                         when the ticket expires, if it has already expired
-                         this is also noted
-
-                   Renew till
-                         the maximum possible end time of any ticket derived
-                         from this one
-
-                   Ticket flags
-                         the flags set on the ticket
-
-                   Addresses
-                         the set of addresses from which this ticket is valid
-
-SSEEEE AALLSSOO
-     kinit(1),  kdestroy(1)
-
- HEIMDAL                         July 8, 2000                                2
diff --git a/crypto/heimdal/lib/asn1/libasn1.h b/crypto/heimdal/lib/asn1/libasn1.h
deleted file mode 100644
index 8a4994a20c76..000000000000
--- a/crypto/heimdal/lib/asn1/libasn1.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (c) 1997 - 2001 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-/* $Id: libasn1.h,v 1.9 2001/04/18 13:10:24 joda Exp $ */
-
-#ifndef __LIBASN1_H__
-#define __LIBASN1_H__
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#include <stdlib.h>
-#include <string.h>
-#include <errno.h>
-#include "krb5_asn1.h"
-#include "der.h"
-#include "asn1_err.h"
-#include <parse_units.h>
-
-#endif /* __LIBASN1_H__ */
diff --git a/crypto/heimdal/lib/editline/editline.cat3 b/crypto/heimdal/lib/editline/editline.cat3
deleted file mode 100644
index 6e7e63ede192..000000000000
--- a/crypto/heimdal/lib/editline/editline.cat3
+++ /dev/null
@@ -1,198 +0,0 @@
-
-
-
-EDITLINE(3)                                                       EDITLINE(3)
-
-
-
-NAME
-  editline - command-line editing library with history
-
-SYNOPSIS
-  cchhaarr **
-  rreeaaddlliinnee((pprroommpptt))
-       cchhaarr       **pprroommpptt;;
-
-  vvooiidd
-  aadddd__hhiissttoorryy((lliinnee))
-      cchhaarr        **lliinnee;;
-
-DESCRIPTION
-  _E_d_i_t_l_i_n_e is a library that provides an line-editing interface with text
-  recall.  It is intended to be compatible with the _r_e_a_d_l_i_n_e library provided
-  by the Free Software Foundation, but much smaller.  The bulk of this manual
-  page describes the user interface.
-
-  The _r_e_a_d_l_i_n_e routine returns a line of text with the trailing newline
-  removed.  The data is returned in a buffer allocated with _m_a_l_l_o_c(3), so the
-  space should be released with _f_r_e_e(3) when the calling program is done with
-  it.  Before accepting input from the user, the specified _p_r_o_m_p_t is dis-
-  played on the terminal.
-
-  The _a_d_d___h_i_s_t_o_r_y routine makes a copy of the specified _l_i_n_e and adds it to
-  the internal history list.
-
-  User Interface
-
-  A program that uses this library provides a simple emacs-like editing
-  interface to its users.  A line may be edited before it is sent to the
-  calling program by typing either control characters or escape sequences.  A
-  control character, shown as a caret followed by a letter, is typed by hold-
-  ing down the ``control'' key while the letter is typed.  For example,
-  ``^A'' is a control-A.  An escape sequence is entered by typing the
-  ``escape'' key followed by one or more characters.  The escape key is
-  abbreviated as ``ESC.''  Note that unlike control keys, case matters in
-  escape sequences; ``ESC F'' is not the same as ``ESC f''.
-
-  An editing command may be typed anywhere on the line, not just at the
-  beginning.  In addition, a return may also be typed anywhere on the line,
-  not just at the end.
-
-  Most editing commands may be given a repeat count, _n, where _n is a number.
-  To enter a repeat count, type the escape key, the number, and then the com-
-  mand to execute.  For example, ``ESC 4 ^f'' moves forward four characters.
-  If a command may be given a repeat count then the text ``[n]'' is given at
-  the end of its description.
-
-  The following control characters are accepted:
-       ^A       Move to the beginning of the line
-       ^B       Move left (backwards) [n]
-       ^D       Delete character [n]
-       ^E       Move to end of line
-       ^F       Move right (forwards) [n]
-       ^G       Ring the bell
-       ^H       Delete character before cursor (backspace key) [n]
-       ^I       Complete filename (tab key); see below
-       ^J       Done with line (return key)
-       ^K       Kill to end of line (or column [n])
-       ^L       Redisplay line
-       ^M       Done with line (alternate return key)
-       ^N       Get next line from history [n]
-       ^P       Get previous line from history [n]
-       ^R       Search backward (forward if [n]) through history for text;
-                must start line if text begins with an uparrow
-       ^T       Transpose characters
-       ^V       Insert next character, even if it is an edit command
-       ^W       Wipe to the mark
-       ^X^X     Exchange current location and mark
-       ^Y       Yank back last killed text
-       ^[       Start an escape sequence (escape key)
-       ^]c      Move forward to next character ``c''
-       ^?       Delete character before cursor (delete key) [n]
-
-  The following escape sequences are provided.
-       ESC ^H   Delete previous word (backspace key) [n]
-       ESC DEL  Delete previous word (delete key) [n]
-       ESC SP   Set the mark (space key); see ^X^X and ^Y above
-       ESC .    Get the last (or [n]'th) word from previous line
-       ESC ?    Show possible completions; see below
-       ESC <    Move to start of history
-       ESC >    Move to end of history
-       ESC b    Move backward a word [n]
-       ESC d    Delete word under cursor [n]
-       ESC f    Move forward a word [n]
-       ESC l    Make word lowercase [n]
-       ESC u    Make word uppercase [n]
-       ESC y    Yank back last killed text
-       ESC v    Show library version
-       ESC w    Make area up to mark yankable
-       ESC nn   Set repeat count to the number nn
-       ESC C    Read from environment variable ``_C_'', where C is
-                an uppercase letter
-
-  The _e_d_i_t_l_i_n_e library has a small macro facility.  If you type the escape
-  key followed by an uppercase letter, _C, then the contents of the environ-
-  ment variable ___C__ are read in as if you had typed them at the keyboard.
-  For example, if the variable ___L__ contains the following:
-       ^A^Kecho '^V^[[H^V^[[2J'^M
-  Then typing ``ESC L'' will move to the beginning of the line, kill the
-  entire line, enter the echo command needed to clear the terminal (if your
-  terminal is like a VT-100), and send the line back to the shell.
-
-  The _e_d_i_t_l_i_n_e library also does filename completion.  Suppose the root
-  directory has the following files in it:
-       bin    vmunix
-       core   vmunix.old
-  If you type ``rm /v'' and then the tab key.  _E_d_i_t_l_i_n_e will then finish off
-  as much of the name as possible by adding ``munix''.  Because the name is
-  not unique, it will then beep.  If you type the escape key and a question
-  mark, it will display the two choices.  If you then type a period and a
-  tab, the library will finish off the filename for you:
-       rm /v[TAB]_m_u_n_i_x.TAB_o_l_d
-  The tab key is shown by ``[TAB]'' and the automatically-entered text is
-  shown in italics.
-
-
-
-BUGS AND LIMITATIONS
-  Cannot handle lines more than 80 columns.
-
-
-
-
-AUTHORS
-  Simmule R. Turner <uunet.uu.net!capitol!sysgo!simmy> and Rich $alz
-  <rsalz@osf.org>.  Original manual page by DaviD W. Sanderson
-  <dws@ssec.wisc.edu>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/crypto/heimdal/lib/hdb/libasn1.h b/crypto/heimdal/lib/hdb/libasn1.h
deleted file mode 100644
index ef02d7c7e7ae..000000000000
--- a/crypto/heimdal/lib/hdb/libasn1.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (c) 1997, 2001 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-/* $Id: libasn1.h,v 1.5 2001/04/18 16:21:33 joda Exp $ */
-
-#ifndef __LIBASN1_H__
-#define __LIBASN1_H__
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#include <stdlib.h>
-#include <errno.h>
-#include <krb5_asn1.h>
-#include <der.h>
-#include "hdb_asn1.h"
-#include <asn1_err.h>
-#include <parse_units.h>
-
-#endif /* __LIBASN1_H__ */
diff --git a/crypto/heimdal/lib/kafs/kafs.cat3 b/crypto/heimdal/lib/kafs/kafs.cat3
deleted file mode 100644
index 78f5bd531ab9..000000000000
--- a/crypto/heimdal/lib/kafs/kafs.cat3
+++ /dev/null
@@ -1,95 +0,0 @@
-
-KAFS(3)                    UNIX Programmer's Manual                    KAFS(3)
-
-NNAAMMEE
-     kk__hhaassaaffss, kk__ppiiooccttll, kk__uunnlloogg, kk__sseettppaagg, kk__aaffss__cceellll__ooff__ffiillee, kkrrbb__aaffsslloogg,
-     kkrrbb__aaffsslloogg__uuiidd - AFS library
-
-SSYYNNOOPPSSIISS
-     ##iinncclluuddee <<kkaaffss..hh>>
-
-     _i_n_t
-     kk__aaffss__cceellll__ooff__ffiillee(_c_o_n_s_t _c_h_a_r _*_p_a_t_h, _c_h_a_r _*_c_e_l_l, _i_n_t _l_e_n)
-
-     _i_n_t
-     kk__hhaassaaffss()
-
-     _i_n_t
-     kk__ppiiooccttll(_c_h_a_r _*_a___p_a_t_h, _i_n_t _o___o_p_c_o_d_e, _s_t_r_u_c_t _V_i_c_e_I_o_c_t_l _*_a___p_a_r_a_m_s_P,
-             _i_n_t _a___f_o_l_l_o_w_S_y_m_l_i_n_k_s)
-
-     _i_n_t
-     kk__sseettppaagg()
-
-     _i_n_t
-     kk__uunnlloogg()
-
-     _i_n_t
-     kkrrbb__aaffsslloogg(_c_h_a_r _*_c_e_l_l, _c_h_a_r _*_r_e_a_l_m)
-
-     _i_n_t
-     kkrrbb__aaffsslloogg__uuiidd(_c_h_a_r _*_c_e_l_l, _c_h_a_r _*_r_e_a_l_m, _u_i_d___t _u_i_d)
-
-DDEESSCCRRIIPPTTIIOONN
-     kk__hhaassaaffss() initializes some library internal structures, and tests for
-     the presense of AFS in the kernel, none of the other functions should be
-     called before kk__hhaassaaffss() is called, or if it fails.
-
-     kkrrbb__aaffsslloogg(), and kkrrbb__aaffsslloogg__uuiidd() obtains new tokens (and possibly tick-
-     ets) for the specified _c_e_l_l and _r_e_a_l_m. If _c_e_l_l is NULL, the local cell is
-     used. If _r_e_a_l_m is NULL, the function tries to guess what realm to use.
-     Unless you  have some good knowledge of what cell or realm to use, you
-     should pass NULL. kkrrbb__aaffsslloogg() will use the real user-id for the ViceId
-     field in the token, kkrrbb__aaffsslloogg__uuiidd() will use _u_i_d.
-
-     kk__aaffss__cceellll__ooff__ffiillee() will in _c_e_l_l return the cell of a specified file, no
-     more than _l_e_n characters is put in _c_e_l_l.
-
-     kk__ppiiooccttll() does a ppiiooccttll() syscall with the specified arguments. This
-     function is equivalent to llppiiooccttll().
-
-     kk__sseettppaagg() initializes a new PAG.
-
-     kk__uunnlloogg() removes destroys all tokens in the current PAG.
-
-EENNVVIIRROONNMMEENNTT
-     The following environment variable affect the mode of operation of kkaaffss:
-
-     AFS_SYSCALL  Normally, kkaaffss will try to figure out the correct system
-                  call(s) that are used by AFS by itself.  If it does not man-
-                  age to do that, or does it incorrectly, you can set this
-                  variable to the system call number or list of system call
-                  numbers that should be used.
-
-RREETTUURRNN VVAALLUUEESS
-     kk__hhaassaaffss() returns 1 if AFS is present in the kernel, 0 otherwise.
-     kkrrbb__aaffsslloogg() and kkrrbb__aaffsslloogg__uuiidd() returns 0 on success, or a kerberos er-
-     ror number on failure.  kk__aaffss__cceellll__ooff__ffiillee(), kk__ppiiooccttll(), kk__sseettppaagg(), and
-     kk__uunnlloogg() all return the value of the underlaying system call, 0 on suc-
-     cess.
-
-EEXXAAMMPPLLEESS
-     The following code from llooggiinn will obtain a new PAG and tokens for the
-     local cell and the cell of the users home directory.
-
-     if (k_hasafs()) {
-             char cell[64];
-             k_setpag();
-             if(k_afs_cell_of_file(pwd->pw_dir, cell, sizeof(cell)) == 0)
-                     krb_afslog(cell, NULL);
-             krb_afslog(NULL, NULL);
-     }
-
-EERRRROORRSS
-     If any of these functions (appart from kk__hhaassaaffss()) is called without AFS
-     beeing present in the kernel, the process will usually (depending on the
-     operating system) receive a SIGSYS signal.
-
-SSEEEE AALLSSOO
-     Transarc Corporation, "File Server/Cache Manager Interface", _A_F_S_-_3
-     _P_r_o_g_r_a_m_m_e_r_'_s _R_e_f_e_r_e_n_c_e, 1991.
-
-BBUUGGSS
-     AFS_SYSCALL has no effect under AIX.
-
- KTH-KRB                          May 7, 1997                                2
diff --git a/crypto/heimdal/lib/krb5/address.c b/crypto/heimdal/lib/krb5/address.c
deleted file mode 100644
index 5dc756ae4122..000000000000
--- a/crypto/heimdal/lib/krb5/address.c
+++ /dev/null
@@ -1,203 +0,0 @@
-/*
- * Copyright (c) 1997 - 2001 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-#include "krb5_locl.h"
-
-RCSID("$Id: address.c,v 1.15 2001/05/14 06:14:44 assar Exp $");
-
-#if 0
-/* This is the supposedly MIT-api version */
-
-krb5_boolean
-krb5_address_search(krb5_context context,
-		    const krb5_address *addr,
-		    krb5_address *const *addrlist)
-{
-  krb5_address *a;
-
-  while((a = *addrlist++))
-    if (krb5_address_compare (context, addr, a))
-      return TRUE;
-  return FALSE;
-}
-#endif
-
-krb5_boolean
-krb5_address_search(krb5_context context,
-		    const krb5_address *addr,
-		    const krb5_addresses *addrlist)
-{
-    int i;
-
-    for (i = 0; i < addrlist->len; ++i)
-	if (krb5_address_compare (context, addr, &addrlist->val[i]))
-	    return TRUE;
-    return FALSE;
-}
-
-int
-krb5_address_order(krb5_context context,
-		   const krb5_address *addr1,
-		   const krb5_address *addr2)
-{
-    return (addr1->addr_type - addr2->addr_type)
-	|| memcmp (addr1->address.data,
-		   addr2->address.data,
-		   addr1->address.length);
-}
-
-krb5_boolean
-krb5_address_compare(krb5_context context,
-		     const krb5_address *addr1,
-		     const krb5_address *addr2)
-{
-    return krb5_address_order (context, addr1, addr2) == 0;
-}
-
-krb5_error_code
-krb5_copy_address(krb5_context context,
-		  const krb5_address *inaddr,
-		  krb5_address *outaddr)
-{
-    copy_HostAddress(inaddr, outaddr);
-    return 0;
-}
-
-krb5_error_code
-krb5_copy_addresses(krb5_context context,
-		    const krb5_addresses *inaddr,
-		    krb5_addresses *outaddr)
-{
-    copy_HostAddresses(inaddr, outaddr);
-    return 0;
-}
-
-krb5_error_code
-krb5_free_address(krb5_context context,
-		  krb5_address *address)
-{
-    krb5_data_free (&address->address);
-    return 0;
-}
-
-krb5_error_code
-krb5_free_addresses(krb5_context context,
-		    krb5_addresses *addresses)
-{
-    free_HostAddresses(addresses);
-    return 0;
-}
-
-krb5_error_code
-krb5_append_addresses(krb5_context context,
-		      krb5_addresses *dest,
-		      const krb5_addresses *source)
-{
-    krb5_address *tmp;
-    krb5_error_code ret;
-    int i;
-    if(source->len > 0) {
-	tmp = realloc(dest->val, (dest->len + source->len) * sizeof(*tmp));
-	if(tmp == NULL) {
-	    krb5_set_error_string(context, "realloc: out of memory");
-	    return ENOMEM;
-	}
-	dest->val = tmp;
-	for(i = 0; i < source->len; i++) {
-	    /* skip duplicates */
-	    if(krb5_address_search(context, &source->val[i], dest))
-		continue;
-	    ret = krb5_copy_address(context, 
-				    &source->val[i], 
-				    &dest->val[dest->len]);
-	    if(ret)
-		return ret;
-	    dest->len++;
-	}
-    }
-    return 0;
-}
-
-/*
- * Create an address of type KRB5_ADDRESS_ADDRPORT from (addr, port)
- */
-
-krb5_error_code
-krb5_make_addrport (krb5_context context,
-		    krb5_address **res, const krb5_address *addr, int16_t port)
-{
-    krb5_error_code ret;
-    size_t len = addr->address.length + 2 + 4 * 4;
-    u_char *p;
-
-    *res = malloc (sizeof(**res));
-    if (*res == NULL) {
-	krb5_set_error_string(context, "malloc: out of memory");
-	return ENOMEM;
-    }
-    (*res)->addr_type = KRB5_ADDRESS_ADDRPORT;
-    ret = krb5_data_alloc (&(*res)->address, len);
-    if (ret) {
-	krb5_set_error_string(context, "malloc: out of memory");
-	free (*res);
-	return ret;
-    }
-    p = (*res)->address.data;
-    *p++ = 0;
-    *p++ = 0;
-    *p++ = (addr->addr_type     ) & 0xFF;
-    *p++ = (addr->addr_type >> 8) & 0xFF;
-
-    *p++ = (addr->address.length      ) & 0xFF;
-    *p++ = (addr->address.length >>  8) & 0xFF;
-    *p++ = (addr->address.length >> 16) & 0xFF;
-    *p++ = (addr->address.length >> 24) & 0xFF;
-
-    memcpy (p, addr->address.data, addr->address.length);
-    p += addr->address.length;
-
-    *p++ = 0;
-    *p++ = 0;
-    *p++ = (KRB5_ADDRESS_IPPORT     ) & 0xFF;
-    *p++ = (KRB5_ADDRESS_IPPORT >> 8) & 0xFF;
-
-    *p++ = (2      ) & 0xFF;
-    *p++ = (2 >>  8) & 0xFF;
-    *p++ = (2 >> 16) & 0xFF;
-    *p++ = (2 >> 24) & 0xFF;
-
-    memcpy (p, &port, 2);
-    p += 2;
-
-    return 0;
-}
diff --git a/crypto/heimdal/lib/roken/err.h b/crypto/heimdal/lib/roken/err.h
deleted file mode 100644
index b0b649f92b46..000000000000
--- a/crypto/heimdal/lib/roken/err.h
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * Copyright (c) 1995, 1996, 1997 Kungliga Tekniska Högskolan 
- * (Royal Institute of Technology, Stockholm, Sweden).  
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 
- * 3. Neither the name of the Institute nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/* $Id: err.h,v 1.15 1999/12/02 16:58:45 joda Exp $ */
-
-#ifndef __ERR_H__
-#define __ERR_H__
-
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <stdarg.h>
-
-extern const char *__progname;
-
-#if !defined(__GNUC__) && !defined(__attribute__)
-#define __attribute__(x)
-#endif
-
-void warnerr(int doerrno, const char *fmt, va_list ap)
-     __attribute__ ((format (printf, 2, 0)));
-
-void verr(int eval, const char *fmt, va_list ap)
-     __attribute__ ((noreturn, format (printf, 2, 0)));
-void err(int eval, const char *fmt, ...)
-     __attribute__ ((noreturn, format (printf, 2, 3)));
-void verrx(int eval, const char *fmt, va_list ap)
-     __attribute__ ((noreturn, format (printf, 2, 0)));
-void errx(int eval, const char *fmt, ...)
-     __attribute__ ((noreturn, format (printf, 2, 3)));
-void vwarn(const char *fmt, va_list ap)
-     __attribute__ ((format (printf, 1, 0)));
-void warn(const char *fmt, ...)
-     __attribute__ ((format (printf, 1, 2)));
-void vwarnx(const char *fmt, va_list ap)
-     __attribute__ ((format (printf, 1, 0)));
-void warnx(const char *fmt, ...)
-     __attribute__ ((format (printf, 1, 2)));
-
-#endif /* __ERR_H__ */
diff --git a/crypto/heimdal/lib/roken/fnmatch.h b/crypto/heimdal/lib/roken/fnmatch.h
deleted file mode 100644
index 95c91d600b64..000000000000
--- a/crypto/heimdal/lib/roken/fnmatch.h
+++ /dev/null
@@ -1,49 +0,0 @@
-/*	$NetBSD: fnmatch.h,v 1.5 1994/10/26 00:55:53 cgd Exp $	*/
-
-/*-
- * Copyright (c) 1992, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- *	@(#)fnmatch.h	8.1 (Berkeley) 6/2/93
- */
-
-#ifndef	_FNMATCH_H_
-#define	_FNMATCH_H_
-
-#define	FNM_NOMATCH	1	/* Match failed. */
-
-#define	FNM_NOESCAPE	0x01	/* Disable backslash escaping. */
-#define	FNM_PATHNAME	0x02	/* Slash must be matched by slash. */
-#define	FNM_PERIOD	0x04	/* Period must be matched by period. */
-
-int	 fnmatch (const char *, const char *, int);
-
-#endif /* !_FNMATCH_H_ */
diff --git a/crypto/heimdal/lib/roken/glob.h b/crypto/heimdal/lib/roken/glob.h
deleted file mode 100644
index bece48a89cd7..000000000000
--- a/crypto/heimdal/lib/roken/glob.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/*
- * Copyright (c) 1989, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * This code is derived from software contributed to Berkeley by
- * Guido van Rossum.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- *	@(#)glob.h	8.1 (Berkeley) 6/2/93
- */
-
-#ifndef _GLOB_H_
-#define	_GLOB_H_
-
-struct stat;
-typedef struct {
-	int gl_pathc;		/* Count of total paths so far. */
-	int gl_matchc;		/* Count of paths matching pattern. */
-	int gl_offs;		/* Reserved at beginning of gl_pathv. */
-	int gl_flags;		/* Copy of flags parameter to glob. */
-	char **gl_pathv;	/* List of paths matching pattern. */
-				/* Copy of errfunc parameter to glob. */
-	int (*gl_errfunc) (const char *, int);
-
-	/*
-	 * Alternate filesystem access methods for glob; replacement
-	 * versions of closedir(3), readdir(3), opendir(3), stat(2)
-	 * and lstat(2).
-	 */
-	void (*gl_closedir) (void *);
-	struct dirent *(*gl_readdir) (void *);	
-	void *(*gl_opendir) (const char *);
-	int (*gl_lstat) (const char *, struct stat *);
-	int (*gl_stat) (const char *, struct stat *);
-} glob_t;
-
-#define	GLOB_APPEND	0x0001	/* Append to output from previous call. */
-#define	GLOB_DOOFFS	0x0002	/* Use gl_offs. */
-#define	GLOB_ERR	0x0004	/* Return on error. */
-#define	GLOB_MARK	0x0008	/* Append / to matching directories. */
-#define	GLOB_NOCHECK	0x0010	/* Return pattern itself if nothing matches. */
-#define	GLOB_NOSORT	0x0020	/* Don't sort. */
-
-#define	GLOB_ALTDIRFUNC	0x0040	/* Use alternately specified directory funcs. */
-#define	GLOB_BRACE	0x0080	/* Expand braces ala csh. */
-#define	GLOB_MAGCHAR	0x0100	/* Pattern had globbing characters. */
-#define	GLOB_NOMAGIC	0x0200	/* GLOB_NOCHECK without magic chars (csh). */
-#define	GLOB_QUOTE	0x0400	/* Quote special chars with \. */
-#define	GLOB_TILDE	0x0800	/* Expand tilde names from the passwd file. */
-
-#define	GLOB_NOSPACE	(-1)	/* Malloc call failed. */
-#define	GLOB_ABEND	(-2)	/* Unignored error. */
-
-int	glob (const char *, int, int (*)(const char *, int), glob_t *);
-void	globfree (glob_t *);
-
-#endif /* !_GLOB_H_ */
diff --git a/crypto/heimdal/lib/roken/make-print-version.c b/crypto/heimdal/lib/roken/make-print-version.c
deleted file mode 100644
index b29cf3134064..000000000000
--- a/crypto/heimdal/lib/roken/make-print-version.c
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * Copyright (c) 1998 - 2000 Kungliga Tekniska Högskolan
- * (Royal Institute of Technology, Stockholm, Sweden). 
- * All rights reserved. 
- *
- * Redistribution and use in source and binary forms, with or without 
- * modification, are permitted provided that the following conditions 
- * are met: 
- *
- * 1. Redistributions of source code must retain the above copyright 
- *    notice, this list of conditions and the following disclaimer. 
- *
- * 2. Redistributions in binary form must reproduce the above copyright 
- *    notice, this list of conditions and the following disclaimer in the 
- *    documentation and/or other materials provided with the distribution. 
- *
- * 3. Neither the name of the Institute nor the names of its contributors 
- *    may be used to endorse or promote products derived from this software 
- *    without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
- * SUCH DAMAGE. 
- */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-RCSID("$Id: make-print-version.c,v 1.3 2000/08/16 11:30:04 assar Exp $");
-#endif
-
-#include <stdio.h>
-
-#ifdef KRB5
-extern const char *heimdal_version;
-#endif
-#ifdef KRB4
-extern char *krb4_version;
-#endif
-#include <version.h>
-
-int
-main(int argc, char **argv)
-{
-    FILE *f;
-    if(argc != 2)
-	return 1;
-    f = fopen(argv[1], "w");
-    if(f == NULL)
-	return 1;
-    fprintf(f, "#define VERSIONLIST { ");
-#ifdef KRB5
-    fprintf(f, "\"%s\", ", heimdal_version);
-#endif
-#ifdef KRB4
-    fprintf(f, "\"%s\", ", krb4_version);
-#endif
-    fprintf(f, "}\n");
-    fclose(f);
-    return 0;
-}
diff --git a/crypto/heimdal/lib/roken/roken.def b/crypto/heimdal/lib/roken/roken.def
deleted file mode 100644
index f9b0369dd1dd..000000000000
--- a/crypto/heimdal/lib/roken/roken.def
+++ /dev/null
@@ -1,17 +0,0 @@
-LIBRARY roken BASE=0x68f0000
-EXPORTS
-	gettimeofday
-	strcasecmp
-	strtok_r
-	snprintf
-	asprintf
-	vsnprintf
-	base64_decode
-	base64_encode
-	roken_concat
-	roken_vconcat
-	roken_vmconcat
-	roken_mconcat
-	getuid
-	dns_free_data
-	dns_lookup
diff --git a/crypto/heimdal/lib/roken/roken.dsp b/crypto/heimdal/lib/roken/roken.dsp
deleted file mode 100644
index d84854e3d30d..000000000000
--- a/crypto/heimdal/lib/roken/roken.dsp
+++ /dev/null
@@ -1,156 +0,0 @@
-# Microsoft Developer Studio Project File - Name="roken" - Package Owner=<4>
-# Microsoft Developer Studio Generated Build File, Format Version 5.00
-# ** DO NOT EDIT **
-
-# TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102
-
-CFG=roken - Win32 Release
-!MESSAGE This is not a valid makefile. To build this project using NMAKE,
-!MESSAGE use the Export Makefile command and run
-!MESSAGE 
-!MESSAGE NMAKE /f "roken.mak".
-!MESSAGE 
-!MESSAGE You can specify a configuration when running NMAKE
-!MESSAGE by defining the macro CFG on the command line. For example:
-!MESSAGE 
-!MESSAGE NMAKE /f "roken.mak" CFG="roken - Win32 Release"
-!MESSAGE 
-!MESSAGE Possible choices for configuration are:
-!MESSAGE 
-!MESSAGE "roken - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library")
-!MESSAGE "roken - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library")
-!MESSAGE 
-
-# Begin Project
-# PROP Scc_ProjName ""
-# PROP Scc_LocalPath ""
-CPP=cl.exe
-MTL=midl.exe
-RSC=rc.exe
-
-!IF  "$(CFG)" == "roken - Win32 Release"
-
-# PROP BASE Use_MFC 0
-# PROP BASE Use_Debug_Libraries 0
-# PROP BASE Output_Dir ".\Release"
-# PROP BASE Intermediate_Dir ".\Release"
-# PROP BASE Target_Dir ""
-# PROP Use_MFC 0
-# PROP Use_Debug_Libraries 0
-# PROP Output_Dir ".\Release"
-# PROP Intermediate_Dir ".\Release"
-# PROP Ignore_Export_Lib 0
-# PROP Target_Dir ""
-# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /c
-# ADD CPP /nologo /MT /GX /O2 /I "..\krb" /I "..\des" /I "..\..\include" /I "..\..\include\win32" /I "." /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_CONFIG_H" /YX /FD /c
-# ADD BASE MTL /nologo /D "NDEBUG" /win32
-# ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32
-# ADD BASE RSC /l 0x409 /d "NDEBUG"
-# ADD RSC /l 0x409 /d "NDEBUG"
-BSC32=bscmake.exe
-# ADD BASE BSC32 /nologo
-# ADD BSC32 /nologo
-LINK32=link.exe
-# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:windows /dll /machine:I386
-# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /base:"0x68e7780" /subsystem:windows /dll /machine:I386
-
-!ELSEIF  "$(CFG)" == "roken - Win32 Debug"
-
-# PROP BASE Use_MFC 0
-# PROP BASE Use_Debug_Libraries 1
-# PROP BASE Output_Dir ".\Debug"
-# PROP BASE Intermediate_Dir ".\Debug"
-# PROP BASE Target_Dir ""
-# PROP Use_MFC 0
-# PROP Use_Debug_Libraries 1
-# PROP Output_Dir ".\Debug"
-# PROP Intermediate_Dir ".\Debug"
-# PROP Ignore_Export_Lib 0
-# PROP Target_Dir ""
-# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /YX /c
-# ADD CPP /nologo /MDd /Gm /GX /Zi /Od /I "..\krb" /I "..\des" /I "..\..\include" /I "..\..\include\win32" /I "." /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_CONFIG_H" /YX /FD /c
-# ADD BASE MTL /nologo /D "_DEBUG" /win32
-# ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32
-# ADD BASE RSC /l 0x409 /d "_DEBUG"
-# ADD RSC /l 0x409 /d "_DEBUG"
-BSC32=bscmake.exe
-# ADD BASE BSC32 /nologo
-# ADD BSC32 /nologo
-LINK32=link.exe
-# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:windows /dll /debug /machine:I386
-# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /subsystem:windows /dll /debug /machine:I386 /def:".\roken.def"
-# SUBTRACT LINK32 /pdb:none
-
-!ENDIF 
-
-# Begin Target
-
-# Name "roken - Win32 Release"
-# Name "roken - Win32 Debug"
-# Begin Group "Source Files"
-
-# PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;hpj;bat;for;f90"
-# Begin Source File
-
-SOURCE=.\base64.c
-# End Source File
-# Begin Source File
-
-SOURCE=.\concat.c
-# End Source File
-# Begin Source File
-
-SOURCE=.\gettimeofday.c
-# End Source File
-# Begin Source File
-
-SOURCE=.\getuid.c
-# End Source File
-# Begin Source File
-
-SOURCE=.\resolve.c
-# End Source File
-# Begin Source File
-
-SOURCE=.\roken.def
-
-!IF  "$(CFG)" == "roken - Win32 Release"
-
-!ELSEIF  "$(CFG)" == "roken - Win32 Debug"
-
-# PROP Exclude_From_Build 1
-
-!ENDIF 
-
-# End Source File
-# Begin Source File
-
-SOURCE=.\snprintf.c
-# End Source File
-# Begin Source File
-
-SOURCE=.\strcasecmp.c
-# End Source File
-# Begin Source File
-
-SOURCE=.\strtok_r.c
-# End Source File
-# End Group
-# Begin Group "Header Files"
-
-# PROP Default_Filter "h;hpp;hxx;hm;inl;fi;fd"
-# Begin Source File
-
-SOURCE=.\resolve.h
-# End Source File
-# End Group
-# Begin Group "Resource Files"
-
-# PROP Default_Filter "ico;cur;bmp;dlg;rc2;rct;bin;cnt;rtf;gif;jpg;jpeg;jpe"
-# Begin Source File
-
-SOURCE=.\roken.rc
-# End Source File
-# End Group
-# End Target
-# End Project
diff --git a/crypto/heimdal/lib/roken/roken.mak b/crypto/heimdal/lib/roken/roken.mak
deleted file mode 100644
index da9a834e5551..000000000000
--- a/crypto/heimdal/lib/roken/roken.mak
+++ /dev/null
@@ -1,316 +0,0 @@
-# Microsoft Developer Studio Generated NMAKE File, Based on roken.dsp
-!IF "$(CFG)" == ""
-CFG=roken - Win32 Release
-!MESSAGE No configuration specified. Defaulting to roken - Win32 Release.
-!ENDIF 
-
-!IF "$(CFG)" != "roken - Win32 Release" && "$(CFG)" != "roken - Win32 Debug"
-!MESSAGE Invalid configuration "$(CFG)" specified.
-!MESSAGE You can specify a configuration when running NMAKE
-!MESSAGE by defining the macro CFG on the command line.  For example:
-!MESSAGE 
-!MESSAGE NMAKE /f "roken.mak" CFG="roken - Win32 Release"
-!MESSAGE 
-!MESSAGE Possible choices for configuration are:
-!MESSAGE 
-!MESSAGE "roken - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library")
-!MESSAGE "roken - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library")
-!MESSAGE 
-!ERROR An invalid configuration is specified.
-!ENDIF 
-
-!IF "$(OS)" == "Windows_NT"
-NULL=
-!ELSE 
-NULL=nul
-!ENDIF 
-
-CPP=cl.exe
-MTL=midl.exe
-RSC=rc.exe
-
-!IF  "$(CFG)" == "roken - Win32 Release"
-
-OUTDIR=.\Release
-INTDIR=.\Release
-# Begin Custom Macros
-OutDir=.\.\Release
-# End Custom Macros
-
-!IF "$(RECURSE)" == "0" 
-
-ALL : "$(OUTDIR)\roken.dll"
-
-!ELSE 
-
-ALL : "$(OUTDIR)\roken.dll"
-
-!ENDIF 
-
-CLEAN : 
-	-@erase "$(INTDIR)\base64.obj"
-	-@erase "$(INTDIR)\concat.obj"
-	-@erase "$(INTDIR)\gettimeofday.obj"
-	-@erase "$(INTDIR)\getuid.obj"
-	-@erase "$(INTDIR)\resolve.obj"
-	-@erase "$(INTDIR)\roken.res"
-	-@erase "$(INTDIR)\snprintf.obj"
-	-@erase "$(INTDIR)\strcasecmp.obj"
-	-@erase "$(INTDIR)\strtok_r.obj"
-	-@erase "$(INTDIR)\vc50.idb"
-	-@erase "$(OUTDIR)\roken.dll"
-	-@erase "$(OUTDIR)\roken.exp"
-	-@erase "$(OUTDIR)\roken.lib"
-
-"$(OUTDIR)" :
-    if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"
-
-CPP_PROJ=/nologo /MT /GX /O2 /I "..\krb" /I "..\des" /I "..\..\include" /I\
- "..\..\include\win32" /I "." /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D\
- "HAVE_CONFIG_H" /Fp"$(INTDIR)\roken.pch" /YX /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\"\
- /FD /c 
-CPP_OBJS=.\Release/
-CPP_SBRS=.
-MTL_PROJ=/nologo /D "NDEBUG" /mktyplib203 /win32 
-RSC_PROJ=/l 0x409 /fo"$(INTDIR)\roken.res" /d "NDEBUG" 
-BSC32=bscmake.exe
-BSC32_FLAGS=/nologo /o"$(OUTDIR)\roken.bsc" 
-BSC32_SBRS= \
-	
-LINK32=link.exe
-LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
- advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo\
- /base:"0x68e7780" /subsystem:windows /dll /incremental:no\
- /pdb:"$(OUTDIR)\roken.pdb" /machine:I386 /def:".\roken.def"\
- /out:"$(OUTDIR)\roken.dll" /implib:"$(OUTDIR)\roken.lib" 
-DEF_FILE= \
-	".\roken.def"
-LINK32_OBJS= \
-	"$(INTDIR)\base64.obj" \
-	"$(INTDIR)\concat.obj" \
-	"$(INTDIR)\gettimeofday.obj" \
-	"$(INTDIR)\getuid.obj" \
-	"$(INTDIR)\resolve.obj" \
-	"$(INTDIR)\roken.res" \
-	"$(INTDIR)\snprintf.obj" \
-	"$(INTDIR)\strcasecmp.obj" \
-	"$(INTDIR)\strtok_r.obj"
-
-"$(OUTDIR)\roken.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS)
-    $(LINK32) @<<
-  $(LINK32_FLAGS) $(LINK32_OBJS)
-<<
-
-!ELSEIF  "$(CFG)" == "roken - Win32 Debug"
-
-OUTDIR=.\Debug
-INTDIR=.\Debug
-# Begin Custom Macros
-OutDir=.\.\Debug
-# End Custom Macros
-
-!IF "$(RECURSE)" == "0" 
-
-ALL : "$(OUTDIR)\roken.dll"
-
-!ELSE 
-
-ALL : "$(OUTDIR)\roken.dll"
-
-!ENDIF 
-
-CLEAN : 
-	-@erase "$(INTDIR)\base64.obj"
-	-@erase "$(INTDIR)\concat.obj"
-	-@erase "$(INTDIR)\gettimeofday.obj"
-	-@erase "$(INTDIR)\getuid.obj"
-	-@erase "$(INTDIR)\resolve.obj"
-	-@erase "$(INTDIR)\roken.res"
-	-@erase "$(INTDIR)\snprintf.obj"
-	-@erase "$(INTDIR)\strcasecmp.obj"
-	-@erase "$(INTDIR)\strtok_r.obj"
-	-@erase "$(INTDIR)\vc50.idb"
-	-@erase "$(INTDIR)\vc50.pdb"
-	-@erase "$(OUTDIR)\roken.dll"
-	-@erase "$(OUTDIR)\roken.exp"
-	-@erase "$(OUTDIR)\roken.ilk"
-	-@erase "$(OUTDIR)\roken.lib"
-	-@erase "$(OUTDIR)\roken.pdb"
-
-"$(OUTDIR)" :
-    if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"
-
-CPP_PROJ=/nologo /MDd /Gm /GX /Zi /Od /I "..\krb" /I "..\des" /I\
- "..\..\include" /I "..\..\include\win32" /I "." /D "_DEBUG" /D "WIN32" /D\
- "_WINDOWS" /D "HAVE_CONFIG_H" /Fp"$(INTDIR)\roken.pch" /YX /Fo"$(INTDIR)\\"\
- /Fd"$(INTDIR)\\" /FD /c 
-CPP_OBJS=.\Debug/
-CPP_SBRS=.
-MTL_PROJ=/nologo /D "_DEBUG" /mktyplib203 /win32 
-RSC_PROJ=/l 0x409 /fo"$(INTDIR)\roken.res" /d "_DEBUG" 
-BSC32=bscmake.exe
-BSC32_FLAGS=/nologo /o"$(OUTDIR)\roken.bsc" 
-BSC32_SBRS= \
-	
-LINK32=link.exe
-LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
- advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo\
- /subsystem:windows /dll /incremental:yes /pdb:"$(OUTDIR)\roken.pdb" /debug\
- /machine:I386 /def:".\roken.def" /out:"$(OUTDIR)\roken.dll"\
- /implib:"$(OUTDIR)\roken.lib" 
-LINK32_OBJS= \
-	"$(INTDIR)\base64.obj" \
-	"$(INTDIR)\concat.obj" \
-	"$(INTDIR)\gettimeofday.obj" \
-	"$(INTDIR)\getuid.obj" \
-	"$(INTDIR)\resolve.obj" \
-	"$(INTDIR)\roken.res" \
-	"$(INTDIR)\snprintf.obj" \
-	"$(INTDIR)\strcasecmp.obj" \
-	"$(INTDIR)\strtok_r.obj"
-
-"$(OUTDIR)\roken.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS)
-    $(LINK32) @<<
-  $(LINK32_FLAGS) $(LINK32_OBJS)
-<<
-
-!ENDIF 
-
-.c{$(CPP_OBJS)}.obj::
-   $(CPP) @<<
-   $(CPP_PROJ) $< 
-<<
-
-.cpp{$(CPP_OBJS)}.obj::
-   $(CPP) @<<
-   $(CPP_PROJ) $< 
-<<
-
-.cxx{$(CPP_OBJS)}.obj::
-   $(CPP) @<<
-   $(CPP_PROJ) $< 
-<<
-
-.c{$(CPP_SBRS)}.sbr::
-   $(CPP) @<<
-   $(CPP_PROJ) $< 
-<<
-
-.cpp{$(CPP_SBRS)}.sbr::
-   $(CPP) @<<
-   $(CPP_PROJ) $< 
-<<
-
-.cxx{$(CPP_SBRS)}.sbr::
-   $(CPP) @<<
-   $(CPP_PROJ) $< 
-<<
-
-
-!IF "$(CFG)" == "roken - Win32 Release" || "$(CFG)" == "roken - Win32 Debug"
-SOURCE=.\base64.c
-DEP_CPP_BASE6=\
-	"..\..\include\win32\config.h"\
-	".\base64.h"\
-
-
-"$(INTDIR)\base64.obj" : $(SOURCE) $(DEP_CPP_BASE6) "$(INTDIR)"
-
-
-SOURCE=.\concat.c
-DEP_CPP_CONCA=\
-	"..\..\include\win32\config.h"\
-	"..\..\include\win32\roken.h"\
-	".\err.h"\
-	".\roken-common.h"\
-	{$(INCLUDE)}"sys\stat.h"\
-	{$(INCLUDE)}"sys\types.h"\
-	
-
-"$(INTDIR)\concat.obj" : $(SOURCE) $(DEP_CPP_CONCA) "$(INTDIR)"
-
-
-SOURCE=.\gettimeofday.c
-DEP_CPP_GETTI=\
-	"..\..\include\win32\config.h"\
-	"..\..\include\win32\roken.h"\
-	".\err.h"\
-	".\roken-common.h"\
-	{$(INCLUDE)}"sys\stat.h"\
-	{$(INCLUDE)}"sys\types.h"\
-	
-
-"$(INTDIR)\gettimeofday.obj" : $(SOURCE) $(DEP_CPP_GETTI) "$(INTDIR)"
-
-
-SOURCE=.\getuid.c
-DEP_CPP_GETUI=\
-	"..\..\include\win32\config.h"\
-	"..\..\include\win32\roken.h"\
-	".\err.h"\
-	".\roken-common.h"\
-	{$(INCLUDE)}"sys\stat.h"\
-	{$(INCLUDE)}"sys\types.h"\
-	
-
-"$(INTDIR)\getuid.obj" : $(SOURCE) $(DEP_CPP_GETUI) "$(INTDIR)"
-
-
-SOURCE=.\resolve.c
-DEP_CPP_RESOL=\
-	"..\..\include\win32\config.h"\
-	"..\..\include\win32\roken.h"\
-	".\err.h"\
-	".\resolve.h"\
-	".\roken-common.h"\
-	{$(INCLUDE)}"sys\stat.h"\
-	{$(INCLUDE)}"sys\types.h"\
-	
-
-"$(INTDIR)\resolve.obj" : $(SOURCE) $(DEP_CPP_RESOL) "$(INTDIR)"
-
-
-SOURCE=.\snprintf.c
-DEP_CPP_SNPRI=\
-	"..\..\include\win32\config.h"\
-	"..\..\include\win32\roken.h"\
-	".\err.h"\
-	".\roken-common.h"\
-	{$(INCLUDE)}"sys\stat.h"\
-	{$(INCLUDE)}"sys\types.h"\
-	
-
-"$(INTDIR)\snprintf.obj" : $(SOURCE) $(DEP_CPP_SNPRI) "$(INTDIR)"
-
-
-SOURCE=.\strcasecmp.c
-DEP_CPP_STRCA=\
-	"..\..\include\win32\config.h"\
-	{$(INCLUDE)}"sys\types.h"\
-	
-
-"$(INTDIR)\strcasecmp.obj" : $(SOURCE) $(DEP_CPP_STRCA) "$(INTDIR)"
-
-
-SOURCE=.\strtok_r.c
-DEP_CPP_STRTO=\
-	"..\..\include\win32\config.h"\
-	"..\..\include\win32\roken.h"\
-	".\err.h"\
-	".\roken-common.h"\
-	{$(INCLUDE)}"sys\stat.h"\
-	{$(INCLUDE)}"sys\types.h"\
-	
-
-"$(INTDIR)\strtok_r.obj" : $(SOURCE) $(DEP_CPP_STRTO) "$(INTDIR)"
-
-
-SOURCE=.\roken.rc
-
-"$(INTDIR)\roken.res" : $(SOURCE) "$(INTDIR)"
-	$(RSC) $(RSC_PROJ) $(SOURCE)
-	
-
-
-!ENDIF 
-
diff --git a/crypto/heimdal/lib/roken/roken.rc b/crypto/heimdal/lib/roken/roken.rc
deleted file mode 100644
index e7e2f3e499ca..000000000000
--- a/crypto/heimdal/lib/roken/roken.rc
+++ /dev/null
@@ -1,105 +0,0 @@
-//Microsoft Developer Studio generated resource script.
-//
-#include "resource.h"
-
-#define APSTUDIO_READONLY_SYMBOLS
-/////////////////////////////////////////////////////////////////////////////
-//
-// Generated from the TEXTINCLUDE 2 resource.
-//
-#include "afxres.h"
-
-/////////////////////////////////////////////////////////////////////////////
-#undef APSTUDIO_READONLY_SYMBOLS
-
-/////////////////////////////////////////////////////////////////////////////
-// Swedish resources
-
-#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_SVE)
-#ifdef _WIN32
-LANGUAGE LANG_SWEDISH, SUBLANG_DEFAULT
-#pragma code_page(1252)
-#endif //_WIN32
-
-#ifdef APSTUDIO_INVOKED
-/////////////////////////////////////////////////////////////////////////////
-//
-// TEXTINCLUDE
-//
-
-1 TEXTINCLUDE DISCARDABLE 
-BEGIN
-    "resource.h\0"
-END
-
-2 TEXTINCLUDE DISCARDABLE 
-BEGIN
-    "#include ""afxres.h""\r\n"
-    "\0"
-END
-
-3 TEXTINCLUDE DISCARDABLE 
-BEGIN
-    "\r\n"
-    "\0"
-END
-
-#endif    // APSTUDIO_INVOKED
-
-
-#ifndef _MAC
-/////////////////////////////////////////////////////////////////////////////
-//
-// Version
-//
-
-VS_VERSION_INFO VERSIONINFO
- FILEVERSION 1,0,0,1
- PRODUCTVERSION 1,0,0,1
- FILEFLAGSMASK 0x3fL
-#ifdef _DEBUG
- FILEFLAGS 0x1L
-#else
- FILEFLAGS 0x0L
-#endif
- FILEOS 0x40004L
- FILETYPE 0x2L
- FILESUBTYPE 0x0L
-BEGIN
-    BLOCK "StringFileInfo"
-    BEGIN
-        BLOCK "040904b0"
-        BEGIN
-            VALUE "CompanyName", "Royal Institute of Technology (KTH)\0"
-            VALUE "FileDescription", "roken\0"
-            VALUE "FileVersion", "4, 0, 9, 9\0"
-            VALUE "InternalName", "roken\0"
-            VALUE "LegalCopyright", "Copyright © 1996 - 1998  Royal Institute of Technology (KTH)\0"
-            VALUE "OriginalFilename", "roken.dll\0"
-            VALUE "ProductName", "KTH Kerberos\0"
-            VALUE "ProductVersion", "4,0,9,9\0"
-        END
-    END
-    BLOCK "VarFileInfo"
-    BEGIN
-        VALUE "Translation", 0x409, 1200
-    END
-END
-
-#endif    // !_MAC
-
-#endif    // Swedish resources
-/////////////////////////////////////////////////////////////////////////////
-
-
-
-#ifndef APSTUDIO_INVOKED
-/////////////////////////////////////////////////////////////////////////////
-//
-// Generated from the TEXTINCLUDE 3 resource.
-//
-
-
-/////////////////////////////////////////////////////////////////////////////
-#endif    // not APSTUDIO_INVOKED
-
diff --git a/crypto/heimdal/tools/krb5-config.cat1 b/crypto/heimdal/tools/krb5-config.cat1
deleted file mode 100644
index 298f57b6ccbb..000000000000
--- a/crypto/heimdal/tools/krb5-config.cat1
+++ /dev/null
@@ -1,52 +0,0 @@
-
-KRB5-CONFIG(1)               UNIX Reference Manual              KRB5-CONFIG(1)
-
-NNAAMMEE
-     kkrrbb55--ccoonnffiigg - give information on how to link code against Heimdal li-
-     braries
-
-SSYYNNOOPPSSIISS
-     kkrrbb55--ccoonnffiigg [----pprreeffiixx[=_d_i_r]] [----eexxeecc--pprreeffiixx[=_d_i_r]] [----lliibbss] [----ccffllaaggss]
-     [_l_i_b_r_a_r_i_e_s]
-
-DDEESSCCRRIIPPTTIIOONN
-     kkrrbb55--ccoonnffiigg tells the application programmer what special flags to use to
-     compile and link programs against the libraries installed by Heimdal.
-
-     Options supported:
-
-     ----pprreeffiixx[=_d_i_r]
-             Print the prefix if no _d_i_r is specified, otherwise set prefix to
-             _d_i_r.
-
-     ----eexxeecc--pprreeffiixx[=_d_i_r]
-             Print the exec-prefix if no _d_i_r is specified, otherwise set exec-
-             prefix to _d_i_r.
-
-     ----lliibbss  Output the set of libraries that should be linked against.
-
-     ----ccffllaaggss
-             Output the set of flags to give to the C compiler when using the
-             Heimdal libraries.
-
-     By default kkrrbb55--ccoonnffiigg will output the set of flags and libraries to be
-     used by a normal program using the krb5 API.  The user can also supply a
-     library to be used, the supported ones are:
-
-     krb5    (the default)
-
-     gssapi  use the krb5 gssapi mechanism
-
-     kadm-client
-             use the client-side kadmin libraries
-
-     kadm-server
-             use the server-side kadmin libraries
-
-SSEEEE AALLSSOO
-     cc(1)
-
-HHIISSTTOORRYY
-     kkrrbb55--ccoonnffiigg appeared in Heimdal 0.3d.
-
- HEIMDAL                       November 30, 2000                             1