This commit was manufactured by cvs2svn to create branch 'RELENG_4'.

130 files changed, 47917 insertions, 0 deletions

diff --git a/crypto/heimdal/ChangeLog.1998 b/crypto/heimdal/ChangeLog.1998
new file mode 100644
index 000000000000..f26dba777ed2
--- /dev/null
+++ b/crypto/heimdal/ChangeLog.1998
@@ -0,0 +1,3201 @@
+Sat Dec  5 19:49:34 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/context.c: remove ktype_is_etype
+
+	* lib/krb5/crypto.c, lib/krb5/krb5.h, acconfig.h: NEW_DES3_CODE
+
+	* configure.in: fix for AIX install; better tests for AIX dynamic
+ 	AFS libs; `--enable-new-des3-code'
+
+Tue Dec  1 14:44:44 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* appl/afsutil/Makefile.am: link with extra libs for aix
+
+	* kuser/Makefile.am: link with extra libs for aix
+
+Sun Nov 29 01:56:21 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_addrs.c (krb5_get_all_server_addrs): add.  almost
+ 	the same as krb5_get_all_client_addrs except that it includes
+ 	loopback addresses
+
+	* kdc/connect.c (init_socket): bind to a particular address
+	(init_sockets): get all local addresses and bind to them all
+
+	* lib/krb5/addr_families.c (addr2sockaddr, print_addr): new
+ 	methods
+	(find_af, find_atype): new functions.  use them.
+
+	* configure.in: add hesiod
+
+Wed Nov 25 11:37:48 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/krb5_err.et: add some codes from kerberos-revisions-03
+
+Mon Nov 23 12:53:48 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/log.c: rename delete -> remove
+
+	* lib/kadm5/delete_s.c: rename delete -> remove
+
+	* lib/hdb/common.c: rename delete -> remove
+
+Sun Nov 22 12:26:26 1998  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: check for environ and `struct spwd'
+
+Sun Nov 22 11:42:45 1998  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/kerberos5.c (as_rep): set keytype to sess_ktype if
+ 	ktype_is_etype
+
+	* lib/krb5/encrypt.c (krb5_keytype_to_etypes): zero terminate
+ 	etypes
+	(em): sort entries
+
+Sun Nov 22 06:54:48 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/init_creds_pw.c: more type correctness
+
+	* lib/krb5/get_cred.c: re-structure code.  remove limits on ASN1
+ 	generated bits.
+
+Sun Nov 22 01:49:50 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* kdc/hprop.c (v4_prop): fix bogus indexing
+
+Sat Nov 21 21:39:20 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/verify_init.c (fail_verify_is_ok): new function
+	(krb5_verify_init_creds): if we cannot get a ticket for
+	host/`hostname` and fail_verify_is_ok just return.  use
+ 	krb5_rd_req
+
+Sat Nov 21 23:12:27 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/free.c (krb5_xfree): new function
+
+	* lib/krb5/creds.c (krb5_free_creds_contents): new function
+
+	* lib/krb5/context.c: more type correctness
+
+	* lib/krb5/checksum.c: more type correctness
+
+	* lib/krb5/auth_context.c (krb5_auth_con_init): more type
+ 	correctness
+
+	* lib/asn1/der_get.c (der_get_length): fix test of len
+	(der_get_tag): more type correctness
+
+	* kuser/klist.c (usage): void-ize
+
+	* admin/ktutil.c (kt_remove): some more type correctness.
+
+Sat Nov 21 16:49:20 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* kuser/klist.c: try to list enctypes as keytypes
+
+	* kuser/kinit.c: remove extra `--cache' option, add `--enctypes'
+ 	to set list of enctypes to use
+
+	* kadmin/load.c: load strings as hex
+
+	* kadmin/dump.c: dump hex as string is possible
+
+	* admin/ktutil.c: use print_version()
+
+	* configure.in, acconfig.h: test for hesiod
+
+Sun Nov 15 17:28:19 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/crypto.c: add some crypto debug code
+
+	* lib/krb5/get_in_tkt.c (_krb5_extract_ticket): don't use fixed
+ 	buffer when encoding ticket
+
+	* lib/krb5/auth_context.c (re-)implement `krb5_auth_setenctype'
+
+	* kdc/kerberos5.c: allow mis-match of tgt session key, and service
+ 	session key
+
+	* admin/ktutil.c: keytype -> enctype
+
+Fri Nov 13 05:35:48 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krb5.h (KRB5_TGS_NAME, KRB5_TGS_NAME_SIZE): added
+	
+Sat Nov  7 19:56:31 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_cred.c (add_cred): add termination NULL pointer
+
+Mon Nov  2 01:15:06 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_req.c: adapt to new crypto api
+
+	* lib/krb5/rd_rep.c: adapt to new crypto api
+
+	* lib/krb5/rd_priv.c: adopt to new crypto api
+
+	* lib/krb5/rd_cred.c: adopt to new crypto api
+
+	* lib/krb5/principal.c: ENOMEM -> ERANGE
+
+	* lib/krb5/mk_safe.c: cleanup and adopt to new crypto api
+
+	* lib/krb5/mk_req_ext.c: adopt to new crypto api
+
+	* lib/krb5/mk_req.c: get enctype from auth_context keyblock
+
+	* lib/krb5/mk_rep.c: cleanup and adopt to new crypto api
+
+	* lib/krb5/mk_priv.c: adopt to new crypto api
+
+	* lib/krb5/keytab.c: adopt to new crypto api
+
+	* lib/krb5/get_in_tkt_with_skey.c: adopt to new crypto api
+
+	* lib/krb5/get_in_tkt_with_keytab.c: adopt to new crypto api
+
+	* lib/krb5/get_in_tkt_pw.c: adopt to new crypto api
+
+	* lib/krb5/get_in_tkt.c: adopt to new crypto api
+
+	* lib/krb5/get_cred.c: adopt to new crypto api
+
+	* lib/krb5/generate_subkey.c: use new crypto api
+
+	* lib/krb5/context.c: rename etype functions to enctype ditto
+
+	* lib/krb5/build_auth.c: use new crypto api
+
+	* lib/krb5/auth_context.c: remove enctype and cksumtype from
+ 	auth_context
+
+Mon Nov  2 01:15:06 1998  Assar Westerlund  <assar@sics.se>
+
+	* kdc/connect.c (handle_udp, handle_tcp): correct type of `n'
+
+Tue Sep 15 18:41:38 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* admin/ktutil.c: fix printing of unrecognized keytypes
+
+Tue Sep 15 17:02:33 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/kadm5/set_keys.c: add KEYTYPE_USE_AFS3_SALT to keytype if
+ 	using AFS3 salt
+
+Tue Aug 25 23:30:52 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/send_to_kdc.c (krb5_sendto_kdc): care about
+ 	`use_admin_kdc'
+
+	* lib/krb5/changepw.c (get_kdc_address): use
+ 	krb5_get_krb_admin_hst
+
+	* lib/krb5/krbhst.c (krb5_get_krb_admin_hst): new function
+
+	* lib/krb5/krb5.h (krb5_context_data): add `use_admin_kdc'
+
+	* lib/krb5/context.c (krb5_get_use_admin_kdc,
+ 	krb5_set_use_admin_kdc): new functions
+
+Tue Aug 18 22:24:12 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/crypto.c: remove all calls to abort(); check return
+ 	value from _key_schedule;
+	(RSA_MD[45]_DES_verify): zero tmp and res;
+	(RSA_MD5_DES3_{verify,checksum}): implement
+
+Mon Aug 17 20:18:46 1998  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos4.c (swap32): conditionalize
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_internal): new function
+
+	* lib/krb5/get_host_realm.c (krb5_get_host_realm): if the hostname
+ 	returned from gethostby*() isn't a FQDN, try with the original
+ 	hostname
+
+	* lib/krb5/get_cred.c (make_pa_tgs_req): use krb5_mk_req_internal
+ 	and correct key usage
+
+	* lib/krb5/crypto.c (verify_checksum): make static
+
+	* admin/ktutil.c (kt_list): use krb5_enctype_to_string
+
+Sun Aug 16 20:57:56 1998  Assar Westerlund  <assar@sics.se>
+
+	* kadmin/cpw.c (do_cpw_entry): use asprintf for the prompt
+
+	* kadmin/ank.c (ank): print principal name in prompt
+
+	* lib/krb5/crypto.c (hmac): always allocate space for checksum.
+  	never trust c.checksum.length
+	(_get_derived_key): try to return the derived key
+
+Sun Aug 16 19:48:42 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/crypto.c (hmac): fix some peculiarities and bugs
+	(get_checksum_key): assume usage is `formatted'
+	(create_checksum,verify_checksum): moved the guts of the krb5_*
+	functions here, both take `formatted' key-usages
+	(encrypt_internal_derived): fix various bogosities
+	(derive_key): drop key_type parameter (already given by the
+	encryption_type)
+
+	* kdc/kerberos5.c (check_flags): handle case where client is NULL
+
+	* kdc/connect.c (process_request): return zero after processing
+ 	kerberos 4 request
+
+Sun Aug 16 18:38:15 1998  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/crypto.c: merge x-*.[ch] into one file
+
+	* lib/krb5/cache.c: remove residual from krb5_ccache_data
+
+Fri Aug 14 16:28:23 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/x-crypto.c (derive_key): move DES3 specific code to
+ 	separate function (will eventually end up someplace else)
+
+	* lib/krb5/x-crypto.c (krb5_string_to_key_derived): allocate key
+
+	* configure.in, acconfig.h: test for four valued krb_put_int
+
+Thu Aug 13 23:46:29 1998  Assar Westerlund  <assar@emma.pdc.kth.se>
+
+	* Release 0.0t
+
+Thu Aug 13 22:40:17 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/config_file.c (parse_binding): remove trailing
+ 	whitespace
+
+Wed Aug 12 20:15:11 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/x-checksum.c (krb5_verify_checksum): pass checksum type
+ 	to krb5_create_checksum
+
+	* lib/krb5/x-key.c: implement DES3_string_to_key_derived; fix a
+ 	few typos
+
+Wed Aug  5 12:39:54 1998  Assar Westerlund  <assar@emma.pdc.kth.se>
+
+	* Release 0.0s
+
+Thu Jul 30 23:12:17 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mk_error.c (krb5_mk_error): realloc until you die
+
+Thu Jul 23 19:49:03 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kdc_locl.h: proto for `get_des_key'
+
+	* configure.in: test for four valued el_init
+
+	* kuser/klist.c: keytype -> enctype
+
+	* kpasswd/kpasswdd.c (change): use new `krb5_string_to_key*'
+
+	* kdc/hprop.c (v4_prop, ka_convert): convert to a set of keys
+
+	* kdc/kaserver.c: use `get_des_key'
+
+	* kdc/524.c: use new crypto api
+
+	* kdc/kerberos4.c: use new crypto api
+
+	* kdc/kerberos5.c: always treat keytypes as enctypes; use new
+ 	crypto api
+
+	* kdc/kstash.c: adapt to new crypto api
+
+	* kdc/string2key.c: adapt to new crypto api
+
+	* admin/srvconvert.c: add keys for all possible enctypes
+
+	* admin/ktutil.c: keytype -> enctype
+
+	* lib/gssapi/init_sec_context.c: get enctype from auth_context
+ 	keyblock
+
+	* lib/hdb/hdb.c: remove hdb_*_keytype2key
+
+	* lib/kadm5/set_keys.c: adapt to new crypto api
+
+	* lib/kadm5/rename_s.c: adapt to new crypto api
+
+	* lib/kadm5/get_s.c: adapt to new crypto api
+
+	* lib/kadm5/create_s.c: add keys for des-cbc-crc, des-cbc-md4,
+ 	des-cbc-md5, and des3-cbc-sha1
+
+	* lib/krb5/heim_err.et: error message for unsupported salt
+
+	* lib/krb5/codec.c: short-circuit these functions, since they are
+ 	not needed any more
+
+	* lib/krb5/rd_safe.c: cleanup and adapt to new crypto api
+
+Mon Jul 13 23:00:59 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/send_to_kdc.c (krb5_sendto_kdc): don't advance
+ 	hostent->h_addr_list, use a copy instead
+
+Mon Jul 13 15:00:31 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/config_file.c (parse_binding, parse_section): make sure
+ 	everything is ok before adding to linked list
+
+	* lib/krb5/config_file.c: skip ws before checking for comment
+
+Wed Jul  8 10:45:45 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/asn1/k5.asn1: hmac-sha1-des3 = 12
+
+Tue Jun 30 18:08:05 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/send_to_kdc.c (krb5_sendto_kdc): do not close the
+ 	unopened file
+
+	* lib/krb5/mk_priv.c: realloc correctly
+
+	* lib/krb5/get_addrs.c (find_all_addresses): init j
+
+	* lib/krb5/context.c (krb5_init_context): print error if parsing
+ 	of config file produced an error.
+
+	* lib/krb5/config_file.c (parse_list, krb5_config_parse_file):
+ 	ignore more spaces
+
+	* lib/krb5/codec.c (krb5_encode_EncKrbCredPart,
+ 	krb5_encode_ETYPE_INFO): initialize `ret'
+
+	* lib/krb5/build_auth.c (krb5_build_authenticator): realloc
+ 	correctly
+
+	* lib/kadm5/set_keys.c (_kadm5_set_keys): initialize `ret'
+
+	* lib/kadm5/init_c.c (get_cred_cache): try to do the right thing
+ 	with default_client
+
+	* kuser/kinit.c (main): initialize `ticket_life'
+
+	* kdc/kerberos5.c (get_pa_etype_info): initialize `ret'
+	(tgs_rep2): initialize `krbtgt'
+
+	* kdc/connect.c (do_request): check for errors from `sendto'
+
+	* kdc/524.c (do_524): initialize `ret'
+
+	* kadmin/util.c (foreach_principal): don't clobber `ret'
+
+	* kadmin/del.c (del_entry): don't apply on zeroth argument
+
+	* kadmin/cpw.c (do_cpw_entry): initialize `ret'
+
+Sat Jun 13 04:14:01 1998  Assar Westerlund  <assar@juguete.sics.se>
+
+	* Release 0.0r
+
+Sun Jun  7 04:13:14 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/addr_families.c: fall-back definition of
+ 	IN6_ADDR_V6_TO_V4
+
+	* configure.in: only set CFLAGS if it wasn't set look for
+ 	dn_expand and res_search
+
+Mon Jun  1 21:28:07 1998  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: remove duplicate seteuid
+
+Sat May 30 00:19:51 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/convert_creds.c: import _krb_time_to_life, to avoid
+ 	runtime dependencies on libkrb with some shared library
+ 	implementations
+
+Fri May 29 00:09:02 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kuser/kinit_options.c: Default options for kinit.
+
+	* kuser/kauth_options.c: Default options for kauth.
+
+	* kuser/kinit.c: Implement lots a new options.
+
+	* kdc/kerberos5.c (check_tgs_flags): make sure kdc-req-body->rtime
+ 	is not NULL; set endtime to min of new starttime + old_life, and
+ 	requested endtime
+
+	* lib/krb5/init_creds_pw.c (get_init_creds_common): if the
+ 	forwardable or proxiable flags are set in options, set the
+ 	kdc-flags to the value specified, and not always to one
+
+Thu May 28 21:28:06 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c: Optionally compare client address to addresses
+ 	in ticket.
+
+	* kdc/connect.c: Pass client address to as_rep() and tgs_rep().
+
+	* kdc/config.c: Add check_ticket_addresses, and
+ 	allow_null_ticket_addresses variables.
+
+Tue May 26 14:03:42 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/kadm5/create_s.c: possibly make DES keys version 4 salted
+
+	* lib/kadm5/set_keys.c: check config file for kadmin/use_v4_salt
+ 	before zapping version 4 salts
+
+Sun May 24 05:22:17 1998  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0q
+
+	* lib/krb5/aname_to_localname.c: new file
+
+	* lib/gssapi/init_sec_context.c (repl_mutual): no output token
+
+	* lib/gssapi/display_name.c (gss_display_name): zero terminate
+ 	output.
+
+Sat May 23 19:11:07 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/gssapi/display_status.c: new file
+
+	* Makefile.am: send -I to aclocal
+
+	* configure.in: remove duplicate setenv
+
+Sat May 23 04:55:19 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kadmin/util.c (foreach_principal): Check for expression before
+ 	wading through the whole database.
+
+	* kadmin/kadmin.c: Pass NULL password to
+ 	kadm5_*_init_with_password.
+
+	* lib/kadm5/init_c.c: Implement init_with_{skey,creds}*. Make use
+ 	of `password' parameter to init_with_password.
+
+	* lib/kadm5/init_s.c: implement init_with_{skey,creds}*
+
+	* lib/kadm5/server.c: Better arguments for
+ 	kadm5_init_with_password.
+
+Sat May 16 07:10:36 1998  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hprop.c: conditionalize ka-server reading support on
+ 	KASERVER_DB
+
+	* configure.in: new option `--enable-kaserver-db'
+
+Fri May 15 19:39:18 1998  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/get_cred.c: Better error if local tgt couldn't be
+ 	found.
+
+Tue May 12 21:11:02 1998  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0p
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_extended): only set
+ 	encryption type in auth_context if it's compatible with the type
+ 	of the session key
+
+Mon May 11 21:11:14 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/hprop.c: add support for ka-server databases
+
+	* appl/ftp/ftpd: link with -lcrypt, if needed
+
+Fri May  1 07:29:52 1998  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: don't test for winsock.h
+
+Sat Apr 18 21:43:11 1998  Johan Danielsson  <joda@puffer.pdc.kth.se>
+
+	* Release 0.0o
+
+Sat Apr 18 00:31:11 1998  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/sock_principal.c: Save hostname.
+
+Sun Apr  5 11:29:45 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/mk_req_ext.c: Use same enctype as in ticket.
+
+	* kdc/hprop.c (v4_prop): Check for null key.
+
+Fri Apr  3 03:54:54 1998  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/str2key.c: Fix DES3 string-to-key.
+
+	* lib/krb5/keytab.c: Get default keytab name from context.
+
+	* lib/krb5/context.c: Get `default_keytab_name' value.
+
+	* kadmin/util.c (foreach_principal): Print error message if
+ 	`kadm5_get_principals' fails.
+
+	* kadmin/kadmind.c: Use `kadmind_loop'.
+
+	* lib/kadm5/server.c: Replace several other functions with
+ 	`kadmind_loop'.
+
+Sat Mar 28 09:49:18 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/keytab.c (fkt_add_entry): use an explicit seek instead
+ 	of O_APPEND
+
+	* configure.in: generate ftp Makefiles
+
+	* kuser/klist.c (print_cred_verbose): print IPv4-address in a
+ 	portable way.
+
+	* admin/srvconvert.c (srvconv): return 0 if successful
+
+Tue Mar 24 00:40:33 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/keytab.c: MIT compatible changes: add and use sizes to
+ 	keytab entries, and change default keytab to `/etc/krb5.keytab'.
+
+Mon Mar 23 23:43:59 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/gssapi/wrap.c: Use `gss_krb5_getsomekey'.
+
+	* lib/gssapi/unwrap.c: Implement and use `gss_krb5_getsomekey'.
+  	Fix bug in checking of pad.
+
+	* lib/gssapi/{un,}wrap.c: Add support for just integrity
+ 	protecting data.
+ 	
+	* lib/gssapi/accept_sec_context.c: Use
+ 	`gssapi_krb5_verify_8003_checksum'.
+
+	* lib/gssapi/8003.c: Implement `gssapi_krb5_verify_8003_checksum'.
+
+	* lib/gssapi/init_sec_context.c: Zero cred, and store session key
+ 	properly in auth-context.
+
+Sun Mar 22 00:47:22 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/kadm5/delete_s.c: Check immutable bit.
+
+	* kadmin/kadmin.c: Pass client name to kadm5_init.
+
+	* lib/kadm5/init_c.c: Get creds for client name passed in.
+
+	* kdc/hprop.c (v4_prop): Check for `changepw.kerberos'.
+
+Sat Mar 21 22:57:13 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/mk_error.c: Verify that error_code is in the range
+ 	[0,127].
+
+	* kdc/kerberos5.c: Move checking of principal flags to new
+ 	function `check_flags'.
+
+Sat Mar 21 14:38:51 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/get_s.c (kadm5_s_get_principal): handle an empty salt
+
+	* configure.in: define SunOS if running solaris
+
+Sat Mar 21 00:26:34 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/kadm5/server.c: Unifdef test for same principal when
+ 	changing password.
+
+	* kadmin/util.c: If kadm5_get_principals failes, we might still be
+ 	able to perform the requested opreration (for instance someone if
+ 	trying to change his own password).
+
+	* lib/kadm5/init_c.c: Try to get ticket via initial request, if
+ 	not possible via tgt.
+
+	* lib/kadm5/server.c: Check for principals changing their own
+ 	passwords.
+
+	* kdc/kerberos5.c (tgs_rep2): check for interesting flags on
+ 	involved principals.
+
+	* kadmin/util.c: Fix order of flags.
+
+Thu Mar 19 16:54:10 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos4.c: Return sane error code if krb_rd_req fails.
+
+Wed Mar 18 17:11:47 1998  Assar Westerlund  <assar@sics.se>
+
+	* acconfig.h: rename HAVE_STRUCT_SOCKADDR_IN6 to HAVE_IPV6
+
+Wed Mar 18 09:58:18 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_in_tkt_with_keytab.c (krb5_keytab_key_proc): don't
+ 	free keyseed; use correct keytab
+
+Tue Mar 10 09:56:16 1998  Assar Westerlund  <assar@sics.se>
+
+	* acinclude.m4 (AC_KRB_IPV6): rewrote to avoid false positives
+
+Mon Mar 16 23:58:23 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* Release 0.0n
+
+Fri Mar  6 00:41:30 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/gssapi/{accept_sec_context,release_cred}.c: Use
+	krb5_kt_close/krb5_kt_resolve.
+	
+	* lib/krb5/principal.c (krb5_425_conv_principal_ext): Use resolver
+ 	to lookup hosts, so CNAMEs can be ignored.
+
+	* lib/krb5/send_to_kdc.c (krb5_sendto_kdc, send_and_recv_http):
+ 	Add support for using proxy.
+
+	* lib/krb5/context.c: Initialize `http_proxy' from
+ 	`libdefaults/http_proxy'.
+
+	* lib/krb5/krb5.h: Add `http_proxy' to context.
+
+	* lib/krb5/send_to_kdc.c: Recognize `http/' and `udp/' as protocol
+ 	specifications.
+
+Wed Mar  4 01:47:29 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* admin/ktutil.c: Implement `add' and `remove' functions. Make
+ 	`--keytab' a global option.
+
+	* lib/krb5/keytab.c: Implement remove with files. Add memory
+ 	operations.
+
+Tue Mar  3 20:09:59 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/keytab.c: Use function pointers.
+
+	* admin: Remove kdb_edit.
+
+Sun Mar  1 03:28:42 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/dump_log.c: print operation names
+
+Sun Mar  1 03:04:12 1998  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: add X-tests, and {bin,...}dir appl/{kx,kauth}
+	
+	* lib/krb5/build_auth.c,mk_priv.c,rd_safe.c,mk_safe.c,mk_rep.c:
+ 	remove arbitrary limit
+
+	* kdc/hprop-common.c: use krb5_{read,write}_message
+
+	* lib/kadm5/ipropd_master.c (send_diffs): more careful use
+ 	krb5_{write,read}_message
+
+	* lib/kadm5/ipropd_slave.c (get_creds): get credentials for
+ 	`iprop/master' directly.
+	(main): use `krb5_read_message'
+
+Sun Mar  1 02:05:11 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kadmin/kadmin.c: Cleanup commands list, and add help strings.
+
+	* kadmin/get.c: Add long, short, and terse (equivalent to `list')
+ 	output formats. Short is the default.
+
+	* kadmin/util.c: Add `include_time' flag to timeval2str.
+
+	* kadmin/init.c: Max-life and max-renew can, infact, be zero.
+
+	* kadmin/{cpw,del,ext,get}.c: Use `foreach_principal'.
+
+	* kadmin/util.c: Add function `foreach_principal', that loops over
+ 	all principals matching an expression.
+
+	* kadmin/kadmin.c: Add usage string to `privileges'.
+
+	* lib/kadm5/get_princs_s.c: Also try to match aganist the
+ 	expression appended with `@default-realm'.
+
+	* lib/krb5/principal.c: Add `krb5_unparse_name_fixed_short', that
+ 	excludes the realm if it's the same as the default realm.
+
+Fri Feb 27 05:02:21 1998  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: more WFLAGS and WFLAGS_NOUNUSED added missing
+ 	headers and functions error -> com_err
+
+ 	(krb5_get_init_creds_keytab): use krb5_keytab_key_proc
+
+	* lib/krb5/get_in_tkt_with_keytab.c: make `krb5_keytab_key_proc'
+ 	global
+
+	* lib/kadm5/marshall.c (ret_principal_ent): set `n_tl_data'
+
+	* lib/hdb/ndbm.c: use `struct ndbm_db' everywhere.
+
+Fri Feb 27 04:49:24 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mk_priv.c (krb5_mk_priv): bump static limit to 10240.
+  	This should be fixed the correct way.
+
+	* lib/kadm5/ipropd_master.c (check_acl:) truncate buf correctly
+	(send_diffs): compare versions correctly
+	(main): reorder handling of events
+
+	* lib/kadm5/log.c (kadm5_log_previous): avoid bad type conversion
+
+Thu Feb 26 02:22:35 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/ipropd_{slave,master}.c: new files
+
+	* lib/kadm5/log.c (kadm5_log_get_version): take an `fd' as
+ 	argument
+
+	* lib/krb5/krb5.h (krb5_context_data): `et_list' should be `struct
+ 	et_list *'
+
+	* aux/make-proto.pl: Should work with perl4
+
+Mon Feb 16 17:20:22 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/krb5_locl.h: Remove <error.h> (it gets included via
+ 	{asn1,krb5}_err.h).
+
+Thu Feb 12 03:28:40 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_in_tkt.c (_krb5_extract_ticket): if time difference
+ 	is larger than max_skew, return KRB5KRB_AP_ERR_SKEW
+
+	* lib/kadm5/log.c (get_version): globalize
+
+	* lib/kadm5/kadm5_locl.h: include <sys/file.h>
+
+	* lib/asn1/Makefile.am: add PA_KEY_INFO and PA_KEY_INFO_ENTRY
+
+	* kdc/kerberos5.c (get_pa_etype_info): remove gcc-ism of
+ 	initializing local struct in declaration.
+
+Sat Jan 31 17:28:58 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/524.c: Use krb5_decode_EncTicketPart.
+
+	* kdc/kerberos5.c: Check at runtime whether to use enctypes
+ 	instead of keytypes. If so use the same value to encrypt ticket,
+ 	and kdc-rep as well as `keytype' for session key. Fix some obvious
+ 	bugs with the handling of additional tickets.
+
+	* lib/krb5/rd_req.c: Use krb5_decode_EncTicketPart, and
+ 	krb5_decode_Authenticator.
+
+	* lib/krb5/rd_rep.c: Use krb5_decode_EncAPRepPart.
+
+	* lib/krb5/rd_cred.c: Use krb5_decode_EncKrbCredPart.
+
+	* lib/krb5/mk_rep.c: Make sure enc_part.etype is an encryption
+ 	type, and not a key type.  Use krb5_encode_EncAPRepPart.
+
+	* lib/krb5/init_creds_pw.c: Use krb5_decode_PA_KEY_INFO.
+
+	* lib/krb5/get_in_tkt.c: Use krb5_decode_Enc{AS,TGS}RepPart.
+
+	* lib/krb5/get_for_creds.c: Use krb5_encode_EncKrbCredPart.
+
+	* lib/krb5/get_cred.c: Use krb5_decode_Enc{AS,TGS}RepPart.
+
+	* lib/krb5/build_auth.c: Use krb5_encode_Authenticator.
+
+	* lib/krb5/codec.c: Enctype conversion stuff.
+
+	* lib/krb5/context.c: Ignore KRB5_CONFIG if *not* running
+ 	setuid. Get configuration for libdefaults ktype_is_etype, and
+ 	default_etypes.
+
+	* lib/krb5/encrypt.c: Add krb5_string_to_etype, rename
+ 	krb5_convert_etype to krb5_decode_keytype, and add
+ 	krb5_decode_keyblock.
+
+Fri Jan 23 00:32:09 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/{get_in_tkt,rd_req}.c: Use krb5_convert_etype.
+
+	* lib/krb5/encrypt.c: Add krb5_convert_etype function - converts
+ 	from protocol keytypes (that really are enctypes) to internal
+ 	representation.
+
+Thu Jan 22 21:24:36 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/asn1/k5.asn1: Add PA-KEY-INFO structure to hold information
+ 	on keys in the database; and also a new `pa-key-info' padata-type.
+
+	* kdc/kerberos5.c: If pre-authentication fails, return a list of
+ 	keytypes, salttypes, and salts.
+
+	* lib/krb5/init_creds_pw.c: Add better support for
+ 	pre-authentication, by looking at hints from the KDC.
+
+	* lib/krb5/get_in_tkt.c: Add better support for specifying what
+ 	pre-authentication to use.
+
+	* lib/krb5/str2key.c: Merge entries for KEYTYPE_DES and
+ 	KEYTYPE_DES_AFS3.
+
+	* lib/krb5/krb5.h: Add pre-authentication structures.
+
+	* kdc/connect.c: Don't fail if realloc(X, 0) returns NULL.
+
+Wed Jan 21 06:20:40 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/init_s.c (kadm5_s_init_with_password_ctx): initialize
+ 	`log_context.socket_name' and `log_context.socket_fd'
+
+	* lib/kadm5/log.c (kadm5_log_flush): send a unix domain datagram
+ 	to inform the possible running ipropd of an update.
+
+Wed Jan 21 01:34:09 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_in_tkt.c: Return error-packet to caller.
+
+	* lib/krb5/free.c (krb5_free_kdc_rep): Free krb5_kdc_rep->error.
+
+	* kdc/kerberos5.c: Add some support for using enctypes instead of
+ 	keytypes.
+
+	* lib/krb5/get_cred.c: Fixes to send authorization-data to the
+ 	KDC.
+
+	* lib/krb5/build_auth.c: Only generate local subkey if there is
+ 	none.
+
+	* lib/krb5/krb5.h: Add krb5_authdata type.
+
+	* lib/krb5/auth_context.c: Add
+ 	krb5_auth_con_set{,localsub,remotesub}key.
+
+	* lib/krb5/init_creds_pw.c: Return some error if prompter
+ 	functions return failure.
+
+Wed Jan 21 01:16:13 1998  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd/kpasswd.c: detect bad password.  use krb5_err.
+
+	* kadmin/util.c (edit_entry): remove unused variables
+
+Tue Jan 20 22:58:31 1998  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kinit.c: rename `-s' to `-S' to be MIT-compatible.
+
+	* lib/kadm5/kadm5_locl.h: add kadm5_log_context and
+ 	kadm5_log*-functions
+
+	* lib/kadm5/create_s.c (kadm5_s_create_principal): add change to
+ 	log
+
+	* lib/kadm5/rename_s.c (kadm5_s_rename_principal): add change to
+ 	log
+
+	* lib/kadm5/init_s.c (kadm5_s_init_with_password_ctx): initialize
+ 	log_context
+
+	* lib/kadm5/delete_s.c (kadm5_s_delete_principal): add change to
+ 	log
+
+	* lib/kadm5/modify_s.c (kadm5_s_modify_principal): add change to
+ 	log
+
+	* lib/kadm5/randkey_s.c (kadm5_s_randkey_principal): add change to
+ 	log
+
+	* lib/kadm5/chpass_s.c (kadm5_s_chpass_principal): add change to
+ 	log
+
+	* lib/kadm5/Makefile.am: add log.c, dump_log and replay_log
+
+	* lib/kadm5/replay_log.c: new file
+
+	* lib/kadm5/dump_log.c: new file
+
+	* lib/kadm5/log.c: new file
+
+	* lib/krb5/str2key.c (get_str): initialize pad space to zero
+
+	* lib/krb5/config_file.c (krb5_config_vget_next): handle c == NULL
+
+	* kpasswd/kpasswdd.c: rewritten to use the kadm5 API
+
+	* kpasswd/Makefile.am: link with kadm5srv
+
+	* kdc/kerberos5.c (tgs_rep): initialize `i'
+
+	* kadmin/kadmind.c (main): use kadm5_server_{send,recv}_sp
+
+	* include/Makefile.am: added admin.h
+
+Sun Jan 18 01:41:34 1998  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/asn1/gen_copy.c: Don't return ENOMEM if allocating 0 bytes.
+
+	* lib/krb5/mcache.c (mcc_store_cred): restore linked list if
+ 	copy_creds fails.
+
+Tue Jan  6 04:17:56 1998  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/server.c: add kadm5_server_{send,recv}{,_sp}
+
+	* lib/kadm5/marshall.c: add kadm5_{store,ret}_principal_ent_mask.
+
+	* lib/kadm5/init_c.c (kadm5_c_init_with_password_ctx): use
+ 	krb5_getportbyname
+
+	* kadmin/kadmind.c (main): htons correctly.
+	moved kadm5_server_{recv,send}
+
+	* kadmin/kadmin.c (main): only set admin_server if explicitly
+ 	given
+
+Mon Jan  5 23:34:44 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/hdb/ndbm.c: Implement locking of database.
+
+	* kdc/kerberos5.c: Process AuthorizationData.
+
+Sat Jan  3 22:07:07 1998  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/string2key.c: Use AFS string-to-key from libkrb5.
+
+	* lib/krb5/get_in_tkt.c: Handle pa-afs3-salt case.
+
+	* lib/krb5/krb5.h: Add value for AFS salts.
+
+	* lib/krb5/str2key.c: Add support for AFS string-to-key.
+
+	* lib/kadm5/rename_s.c: Use correct salt.
+
+	* lib/kadm5/ent_setup.c: Always enable client. Only set max-life
+ 	and max-renew if != 0.
+
+	* lib/krb5/config_file.c: Add context to all krb5_config_*get_*.
+
+Thu Dec 25 17:03:25 1997  Assar Westerlund  <assar@sics.se>
+
+	* kadmin/ank.c (ank): don't zero password if --random-key was
+ 	given.
+
+Tue Dec 23 01:56:45 1997  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0m
+
+	* lib/kadm5/ent_setup.c (attr_to_flags): try to set `client'
+
+	* kadmin/util.c (edit_time): only set mask if != 0
+	(edit_attributes): only set mask if != 0
+
+	* kadmin/init.c (init): create `default'
+
+Sun Dec 21 09:44:05 1997  Assar Westerlund  <assar@sics.se>
+
+	* kadmin/util.c (str2deltat, str2attr, get_deltat): return value
+ 	as pointer and have return value indicate success.
+	
+	(get_response): check NULL from fgets
+	
+	(edit_time, edit_attributes): new functions for reading values and
+	offering list of answers on '?'
+	
+	(edit_entry): use edit_time and edit_attributes
+
+	* kadmin/ank.c (add_new_key): test the return value of
+ 	`krb5_parse_name'
+
+	* kdc/kerberos5.c (tgs_check_authenticator): RFC1510 doesn't say
+ 	that the checksum has to be keyed, even though later drafts do.
+  	Accept unkeyed checksums to be compatible with MIT.
+
+	* kadmin/kadmin_locl.h: add some prototypes.
+
+	* kadmin/util.c (edit_entry): return a value
+
+	* appl/afsutil/afslog.c (main): return a exit code.
+
+	* lib/krb5/get_cred.c (init_tgs_req): use krb5_keytype_to_enctypes
+
+	* lib/krb5/encrypt.c (krb5_keytype_to_enctypes): new function.
+
+	* lib/krb5/build_auth.c (krb5_build_authenticator): use
+ 	krb5_{free,copy}_keyblock instead of the _contents versions
+
+Fri Dec 12 14:20:58 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/{mk,rd}_priv.c: fix check for local/remote subkey
+
+Mon Dec  8 08:48:09 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/context.c: don't look at KRB5_CONFIG if running setuid
+
+Sat Dec  6 10:09:40 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/keyblock.c (krb5_free_keyblock): check for NULL
+	keyblock
+
+Sat Dec  6 08:26:10 1997  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0l
+
+Thu Dec  4 03:38:12 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/send_to_kdc.c: Add TCP client support.
+
+	* lib/krb5/store.c: Add k_{put,get}_int.
+
+	* kadmin/ank.c: Set initial kvno to 1.
+
+	* kdc/connect.c: Send version 5 TCP-reply as length+data.
+
+Sat Nov 29 07:10:11 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_req.c (krb5_rd_req): fixed obvious bug
+
+	* kdc/kaserver.c (create_reply_ticket): use a random nonce in the
+ 	reply packet.
+
+	* kdc/connect.c (init_sockets): less reallocing.
+
+	* **/*.c: changed `struct fd_set' to `fd_set'
+
+Sat Nov 29 05:12:01 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_default_principal.c: More guessing.
+
+Thu Nov 20 02:55:09 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/rd_req.c: Use principal from ticket if no server is
+ 	given.
+
+Tue Nov 18 02:58:02 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kuser/klist.c: Use krb5_err*().
+
+Sun Nov 16 11:57:43 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kadmin/kadmin.c: Add local `init', `load', `dump', and `merge'
+ 	commands.
+
+Sun Nov 16 02:52:20 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_ext): figure out the correct
+ 	`enctype'
+
+	* lib/krb5/mk_req.c (krb5_mk_req): use `(*auth_context)->enctype'
+ 	if set.
+
+	* lib/krb5/get_cred.c: handle the case of a specific keytype
+
+	* lib/krb5/build_auth.c (krb5_build_authenticator): enctype as a
+ 	parameter instead of guessing it.
+
+	* lib/krb5/build_ap_req.c (krb5_build_ap_req): new parameter
+ 	`enctype'
+
+	* appl/test/common.c (common_setup): don't use `optarg'
+
+	* lib/krb5/keytab.c (krb5_kt_copy_entry_contents): new function
+	(krb5_kt_get_entry): retrieve the latest version if kvno == 0
+
+	* lib/krb5/krb5.h: define KRB5_TC_MATCH_KEYTYPE
+
+	* lib/krb5/creds.c (krb5_compare_creds): check for
+ 	KRB5_TC_MATCH_KEYTYPE
+
+	* lib/gssapi/8003.c (gssapi_krb5_create_8003_checksum): remove
+ 	unused variable
+
+	* lib/krb5/creds.c (krb5_copy_creds_contents): only free the
+ 	contents if we fail.
+
+Sun Nov 16 00:32:48 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kpasswd/kpasswdd.c: Get password expiration time from config
+ 	file.
+
+	* lib/asn1/{der_get,gen_decode}.c: Allow passing NULL size.
+
+Wed Nov 12 02:35:57 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_for_creds.c (krb5_get_forwarded_creds):
+ 	restructured and fixed.
+
+	* lib/krb5/addr_families.c (krb5_h_addr2addr): new function.
+
+Wed Nov 12 01:36:01 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_addrs.c: Fall back to hostname's addresses if other
+ 	methods fail.
+
+Tue Nov 11 22:22:12 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kadmin/kadmin.c: Add `-l' flag to use local database.
+
+	* lib/kadm5/acl.c: Use KADM5_PRIV_ALL.
+
+	* lib/kadm5: Use function pointer trampoline for easier dual use
+ 	(without radiation-hardening capability).
+
+Tue Nov 11 05:15:22 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/encrypt.c (krb5_etype_valid): new function
+
+	* lib/krb5/creds.c (krb5_copy_creds_contents): zero target
+
+	* lib/krb5/context.c (valid_etype): remove
+
+	* lib/krb5/checksum.c: remove dead code
+
+	* lib/krb5/changepw.c (send_request): free memory on error.
+
+	* lib/krb5/build_ap_req.c (krb5_build_ap_req): check return value
+ 	from malloc.
+
+	* lib/krb5/auth_context.c (krb5_auth_con_init): free memory on
+ 	failure correctly.
+	(krb5_auth_con_setaddrs_from_fd): return error correctly.
+
+	* lib/krb5/get_in_tkt_with_{keytab,skey}.c: new files
+
+Tue Nov 11 02:53:19 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/auth_context.c: Implement auth_con_setuserkey.
+
+	* lib/gssapi/init_sec_context.c: Use krb5_auth_con_getkey.
+
+	* lib/krb5/keyblock.c: Rename krb5_free_keyblock to
+ 	krb5_free_keyblock_contents, and reimplement krb5_free_keyblock.
+
+	* lib/krb5/rd_req.c: Use auth_context->keyblock if
+ 	ap_options.use_session_key.
+
+Tue Nov 11 02:35:17 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/net_{read,write}.c: change `int fd' to `void *p_fd'.
+	fix callers.
+
+	* lib/krb5/krb5_locl.h: include <asn1.h> and <der.h>
+
+	* include/Makefile.am: add xdbm.h
+
+Tue Nov 11 01:58:22 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_cred.c: Implement krb5_get_cred_from_kdc.
+
+Mon Nov 10 22:41:53 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/ticket.c: Implement copy_ticket.
+
+	* lib/krb5/get_in_tkt.c: Make `options' parameter MIT-compatible.
+
+	* lib/krb5/data.c: Implement free_data and copy_data.
+
+Sun Nov  9 02:17:27 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/kadm5: Implement kadm5_get_privs, and kadm5_get_principals.
+
+	* kadmin/kadmin.c: Add get_privileges function.
+
+	* lib/kadm5: Rename KADM5_ACL_* -> KADM5_PRIV_* to conform with
+ 	specification.
+
+	* kdc/connect.c: Exit if no sockets could be bound.
+
+	* kadmin/kadmind.c: Check return value from krb5_net_read().
+
+	* lib/kadm5,kadmin: Fix memory leaks.
+
+Fri Nov  7 02:45:26 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/kadm5/create_s.c: Get some default values from `default'
+ 	principal.
+
+	* lib/kadm5/ent_setup.c: Add optional default entry to get some
+ 	values from.
+
+Thu Nov  6 00:20:41 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/error/compile_et.awk: Remove generated destroy_*_error_table
+ 	prototype
+
+	* kadmin/kadmind.c: Crude admin server.
+
+	* kadmin/kadmin.c: Update to use remote protocol.
+
+	* kadmin/get.c: Fix principal formatting.
+
+	* lib/kadm5: Add client support.
+
+	* lib/kadm5/error.c: Error code mapping.
+
+	* lib/kadm5/server.c: Kadmind support function.
+
+	* lib/kadm5/marshall.c: Kadm5 marshalling.
+
+	* lib/kadm5/acl.c: Simple acl system.
+
+	* lib/kadm5/kadm5_locl.h: Add client stuff.
+
+	* lib/kadm5/init_s.c: Initialize acl.
+
+	* lib/kadm5/*:  Return values.
+
+	* lib/kadm5/create_s.c: Correct kvno.
+
+Wed Nov  5 22:06:50 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/log.c: Fix parsing of log destinations.
+
+Mon Nov  3 20:33:55 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/principal.c: Reduce number of reallocs in unparse_name.
+
+Sat Nov  1 01:40:53 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kadmin: Simple kadmin utility.
+
+	* admin/ktutil.c: Print keytype.
+
+	* lib/kadm5/get_s.c: Set correct n_key_data.
+
+	* lib/kadm5/init_s.c: Add kadm5_s_init_with_password_ctx. Use
+ 	master key.
+
+	* lib/kadm5/destroy_s.c: Check for allocated context.
+
+	* lib/kadm5/{create,chpass}_s.c: Use _kadm5_set_keys().
+
+Sat Nov  1 00:21:00 1997  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: test for readv, writev
+
+Wed Oct 29 23:41:26 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/warn.c (_warnerr): handle the case of an illegal error
+ 	code
+
+	* kdc/kerberos5.c (encode_reply): return success
+
+Wed Oct 29 18:01:59 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c (find_etype) Return correct index of selected
+ 	etype.
+
+Wed Oct 29 04:07:06 1997  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0k
+
+	* lib/krb5/context.c (krb5_init_context): support `KRB5_CONFIG'
+ 	environment variable
+
+	* *: use the roken_get*-macros from roken.h for the benefit of
+ 	Crays.
+
+	* configure.in: add --{enable,disable}-otp.  check for compatible
+ 	prototypes for gethostbyname, gethostbyaddr, getservbyname, and
+ 	openlog (they have strange prototypes on Crays)
+
+	* acinclude.m4: new macro `AC_PROTO_COMPAT'
+
+Tue Oct 28 00:11:22 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/connect.c: Log bad requests.
+
+	* kdc/kerberos5.c: Move stuff that's in common between as_rep and
+ 	tgs_rep to separate functions.
+
+	* kdc/kerberos5.c: Fix user-to-user authentication.
+
+	* lib/krb5/get_cred.c: Some restructuring of krb5_get_credentials:
+ 	  - add a kdc-options argument to krb5_get_credentials, and rename
+	    it to krb5_get_credentials_with_flags
+	  - honour the KRB5_GC_CACHED, and KRB5_GC_USER_USER options
+	  - add some more user-to-user glue
+
+	* lib/krb5/rd_req.c: Move parts of krb5_verify_ap_req into a new
+ 	function, krb5_decrypt_ticket, so it is easier to decrypt and
+ 	check a ticket without having an ap-req.
+
+	* lib/krb5/krb5.h: Add KRB5_GC_CACHED, and KRB5_GC_USER_USER
+ 	flags.
+
+	* lib/krb5/crc.c (crc_init_table): Check if table is already
+ 	inited.
+
+Sun Oct 26 04:51:02 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/asn1/der_get.c (der_get_length, fix_dce): Special-case
+ 	indefinite encoding.
+
+	* lib/asn1/gen_glue.c (generate_units): Check for empty
+ 	member-list.
+
+Sat Oct 25 07:24:57 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/error/compile_et.awk: Allow specifying table-base.
+
+Tue Oct 21 20:21:40 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c: Check version number of krbtgt.
+
+Mon Oct 20 01:14:53 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/prompter_posix.c (krb5_prompter_posix): implement the
+ 	case of unhidden prompts.
+
+	* lib/krb5/str2key.c (string_to_key_internal): return error
+ 	instead of aborting.  always free memory
+
+	* admin/ktutil.c: add `help' command
+
+	* admin/kdb_edit.c: implement new commands: add_random_key(ark),
+ 	change_password(cpw), change_random_key(crk)
+
+Thu Oct 16 05:16:36 1997  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd/kpasswdd.c: change all the keys in the database
+
+	* kdc: removed all unsealing, now done by the hdb layer
+
+	* lib/hdb/hdb.c: new functions `hdb_create', `hdb_set_master_key'
+ 	and `hdb_clear_master_key'
+
+	* admin/misc.c: removed
+
+Wed Oct 15 22:47:31 1997  Assar Westerlund  <assar@sics.se>
+
+	* kuser/klist.c: print year as YYYY iff verbose
+
+Wed Oct 15 20:02:13 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kuser/klist.c: print etype from ticket
+
+Mon Oct 13 17:18:57 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* Release 0.0j
+
+	* lib/krb5/get_cred.c: Get the subkey from mk_req so it can be
+ 	used to decrypt the reply from DCE secds.
+
+	* lib/krb5/auth_context.c: Add {get,set}enctype.
+
+	* lib/krb5/get_cred.c: Fix for DCE secd.
+
+	* lib/krb5/store.c: Store keytype twice, as MIT does.
+
+	* lib/krb5/get_in_tkt.c: Use etype from reply.
+
+Fri Oct 10 00:39:48 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/connect.c: check for leading '/' in http request
+
+Tue Sep 30 21:50:18 1997  Assar Westerlund  <assar@assaris.pdc.kth.se>
+
+	* Release 0.0i
+
+Mon Sep 29 15:58:43 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_req.c (krb5_rd_req): redone because we don't know
+ 	the kvno or keytype before receiving the AP-REQ
+
+	* lib/krb5/mk_safe.c (krb5_mk_safe): figure out what cksumtype to
+ 	use from the keytype.
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_extended): figure out what
+ 	cksumtype to use from the keytype.
+
+	* lib/krb5/mk_priv.c (krb5_mk_priv): figure out what etype to use
+ 	from the keytype.
+
+	* lib/krb5/keytab.c (krb5_kt_get_entry): check the keytype
+
+	* lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): figure out
+ 	what etype to use from the keytype.
+
+	* lib/krb5/generate_seq_number.c (krb5_generate_seq_number):
+ 	handle other key types than DES
+
+	* lib/krb5/encrypt.c (key_type): add `best_cksumtype'
+	(krb5_keytype_to_cksumtype): new function
+
+	* lib/krb5/build_auth.c (krb5_build_authenticator): figure out
+ 	what etype to use from the keytype.
+
+	* lib/krb5/auth_context.c (krb5_auth_con_init): set `cksumtype'
+ 	and `enctype' to 0
+
+	* admin/extkeytab.c (ext_keytab): extract all keys
+
+	* appl/telnet/telnet/commands.c: INET6_ADDRSTRLEN kludge
+
+	* configure.in: check for <netinet6/in6.h>. check for -linet6
+	
+Tue Sep 23 03:00:53 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/encrypt.c: fix checksumtype for des3-cbc-sha1
+
+	* lib/krb5/rd_safe.c: fix check for keyed and collision-proof
+ 	checksum
+
+	* lib/krb5/context.c (valid_etype): remove hard-coded constants
+	(default_etypes): include DES3
+
+	* kdc/kerberos5.c: fix check for keyed and collision-proof
+ 	checksum
+
+	* admin/util.c (init_des_key, set_password): DES3 keys also
+
+ 	* lib/krb/send_to_kdc.c (krb5_sendto_kdc): no data returned means
+ 	no contact?
+
+	* lib/krb5/addr_families.c: fix typo in `ipv6_anyaddr'
+
+Mon Sep 22 11:44:27 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/kerberos5.c: Somewhat fix the etype usage. The list sent by
+ 	the client is used to select wich key to encrypt the kdc rep with
+ 	(in case of as-req), and with the server info to select the
+ 	session key type. The server key the ticket is encrypted is based
+ 	purely on the keys in the database.
+
+	* kdc/string2key.c: Add keytype support. Default to version 5
+ 	keys.
+
+	* lib/krb5/get_in_tkt.c: Fix a lot of etype/keytype misuse.
+
+	* lib/krb5/encrypt.c: Add des3-cbc-md5, and des3-cbc-sha1. Add
+ 	many *_to_* functions.
+
+	* lib/krb5/str2key.c: Add des3 string-to-key. Add ktype argument
+ 	to krb5_string_to_key().
+
+	* lib/krb5/checksum.c: Some cleanup, and added: 
+	  - rsa-md5-des3 
+	  - hmac-sha1-des3 
+	  - keyed and collision proof flags to each checksum method
+	  - checksum<->string functions.
+
+	* lib/krb5/generate_subkey.c: Use krb5_generate_random_keyblock.
+
+Sun Sep 21 15:19:23 1997  Assar Westerlund  <assar@sics.se>
+
+	* kdc/connect.c: use new addr_families functions
+
+	* kpasswd/kpasswdd.c: use new addr_families functions.  Now works
+ 	over IPv6
+
+	* kuser/klist.c: use correct symbols for address families
+
+	* lib/krb5/sock_principal.c: use new addr_families functions
+
+	* lib/krb5/send_to_kdc.c: use new addr_families functions
+
+	* lib/krb5/krb5.h: add KRB5_ADDRESS_INET6
+
+	* lib/krb5/get_addrs.c: use new addr_families functions
+
+	* lib/krb5/changepw.c: use new addr_families functions.  Now works
+ 	over IPv6
+
+	* lib/krb5/auth_context.c: use new addr_families functions
+
+	* lib/krb5/addr_families.c: new file
+
+	* acconfig.h: AC_SOCKADDR_IN6 -> AC_STRUCT_SOCKADDR_IN6.  Updated
+ 	uses.
+
+	* acinclude.m4: new macro `AC_KRB_IPV6'.  Use it.
+
+Sat Sep 13 23:04:23 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/hprop.c: Don't encrypt twice. Complain on non-convertable
+ 	principals.
+
+Sat Sep 13 00:59:36 1997  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0h
+	
+	* appl/telnet/telnet/commands.c: AF_INET6 support
+
+	* admin/misc.c: new file
+
+	* lib/krb5/context.c: new configuration variable `max_retries'
+
+	* lib/krb5/get_addrs.c: fixes and better #ifdef's
+
+	* lib/krb5/config_file.c: implement krb5_config_get_int
+
+	* lib/krb5/auth_context.c, send_to_kdc.c, sock_principal.c:
+ 	AF_INET6 support
+
+	* kuser/klist.c: support for printing IPv6-addresses
+
+	* kdc/connect.c: support AF_INET6
+
+	* configure.in: test for gethostbyname2 and struct sockaddr_in6
+
+Thu Sep 11 07:25:28 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/k5.asn1: Use `METHOD-DATA' instead of `SEQUENCE OF
+ 	PA-DATA'
+
+Wed Sep 10 21:20:17 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c: Fixes for cross-realm, including (but not
+ 	limited to):
+	  - allow client to be non-existant (should probably check for
+	    "local realm")
+	  - if server isn't found and it is a request for a krbtgt, try to
+ 	    find a realm on the way to the requested realm
+	  - update the transited encoding iff 
+	    client-realm != server-realm != tgt-realm
+
+	* lib/krb5/get_cred.c: Several fixes for cross-realm.
+
+Tue Sep  9 15:59:20 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/string2key.c: Fix password handling.
+
+	* lib/krb5/encrypt.c: krb5_key_to_string
+
+Tue Sep  9 07:46:05 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_addrs.c: rewrote.  Now should be able to handle
+ 	aliases and IPv6 addresses
+
+	* kuser/klist.c: try printing IPv6 addresses
+
+	* kdc/kerberos5.c: increase the arbitrary limit from 1024 to 8192
+
+	* configure.in: check for <netinet/in6_var.h>
+
+Mon Sep  8 02:57:14 1997  Assar Westerlund  <assar@sics.se>
+
+	* doc: fixes
+
+	* admin/util.c (init_des_key): increase kvno
+	(set_password): return -1 if `des_read_pw_string' failed
+
+	* admin/mod.c (doit2): check the return value from `set_password'
+
+	* admin/ank.c (doit): don't add a new entry if `set_password'
+ 	failed
+
+Mon Sep  8 02:20:16 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/verify_init.c: fix ap_req_nofail semantics
+
+	* lib/krb5/transited.c: something that might resemble
+ 	domain-x500-compress
+
+Mon Sep  8 01:24:42 1997  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hpropd.c (main): check number of arguments
+
+	* appl/popper/pop_init.c (pop_init): check number of arguments
+
+	* kpasswd/kpasswd.c (main): check number of arguments
+
+	* kdc/string2key.c (main): check number of arguments
+
+	* kuser/kdestroy.c (main): check number of arguments
+
+	* kuser/kinit.c (main): check number of arguments
+
+	* kpasswd/kpasswdd.c (main): use sigaction without SA_RESTART to
+ 	break out of select when a signal arrives
+
+	* kdc/main.c (main): use sigaction without SA_RESTART to break out
+ 	of select when a signal arrives
+
+	* kdc/kstash.c: default to HDB_DB_DIR "/m-key"
+
+	* kdc/config.c (configure): add `--version'.  Check the number of
+ 	arguments. Handle the case of there being no specification of port
+ 	numbers.
+
+	* admin/util.c: seal and unseal key at appropriate places
+
+	* admin/kdb_edit.c (main): parse arguments, config file and read
+ 	master key iff there's one.
+
+	* admin/extkeytab.c (ext_keytab): unseal key while extracting
+
+Sun Sep  7 20:41:01 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/roken/roken.h: include <fcntl.h>
+
+	* kdc/kerberos5.c (set_salt_padata): new function
+
+	* appl/telnet/telnetd/telnetd.c: Rename some variables that
+ 	conflict with cpp symbols on HP-UX 10.20
+
+	* change all calls of `gethostbyaddr' to cast argument 1 to `const
+ 	char *'
+
+	* acconfig.h: only use SGTTY on nextstep
+
+Sun Sep  7 14:33:50 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c: Check invalid flag.
+
+Fri Sep  5 14:19:38 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/verify_user.c: Use get_init_creds/verify_init_creds.
+
+	* lib/kafs: Move functions common to krb/krb5 modules to new file,
+ 	and make things more modular.
+
+	* lib/krb5/krb5.h: rename STRING -> krb5_config_string, and LIST
+ 	-> krb5_config_list
+
+Thu Sep  4 23:39:43 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/get_addrs.c: Fix loopback test.
+
+Thu Sep  4 04:45:49 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/roken/roken.h: fallback definition of `O_ACCMODE'
+
+	* lib/krb5/get_in_tkt.c (krb5_get_in_cred): be more careful when
+ 	checking for a v4 reply
+
+Wed Sep  3 18:20:14 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/hprop.c: Add `--decrypt' and `--encrypt' flags.
+
+	* lib/hdb/hdb.c: new {seal,unseal}_keys functions
+
+	* kdc/{hprop,hpropd}.c: Add support to dump database to stdout.
+
+	* kdc/hprop.c: Don't use same master key as version 4.
+
+	* admin/util.c: Don't dump core if no `default' is found.
+
+Wed Sep  3 16:01:07 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/connect.c: Allow run time port specification.
+
+	* kdc/config.c: Add flags for http support, and port
+ 	specifications.
+
+Tue Sep  2 02:00:03 1997  Assar Westerlund  <assar@sics.se>
+
+	* include/bits.c: Don't generate ifndef's in bits.h.  Instead, use
+ 	them when building the program.  This makes it possible to include
+ 	bits.h without having defined all HAVE_INT17_T symbols.
+	
+	* configure.in: test for sigaction
+
+	* doc: updated documentation.
+	
+Tue Sep  2 00:20:31 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* Release 0.0g
+
+Mon Sep  1 17:42:14 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/data.c: don't return ENOMEM if len == 0
+
+Sun Aug 31 17:15:49 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/hdb/hdb.asn1: Include salt type in salt.
+
+	* kdc/hprop.h: Change port to 754.
+
+	* kdc/hpropd.c: Verify who tries to transmit a database.
+
+	* appl/popper: Use getarg and krb5_log.
+
+	* lib/krb5/get_port.c: Add context parameter. Now takes port in
+ 	host byte order.
+
+Sat Aug 30 18:48:19 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/connect.c: Add timeout to select, and log about expired tcp
+ 	connections.
+
+	* kdc/config.c: Add `database' option.
+
+	* kdc/hpropd.c: Log about duplicate entries.
+
+	* lib/hdb/{db,ndbm}.c: Use common routines.
+
+	* lib/hdb/common.c: Implement more generic fetch/store/delete
+ 	functions.
+
+	* lib/hdb/hdb.h: Add `replace' parameter to store.
+	
+	* kdc/connect.c: Set filedecriptor to -1 on allocated decriptor
+ 	entries.
+
+Fri Aug 29 03:13:23 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_in_tkt.c: extract_ticket -> _krb5_extract_ticket
+
+	* aux/make-proto.pl: fix __P for stone age mode
+
+Fri Aug 29 02:45:46 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/45/mk_req.c: implementation of krb_mk_req that uses 524
+ 	protocol
+
+	* lib/krb5/init_creds_pw.c: make change_password and
+ 	get_init_creds_common static
+
+	* lib/krb5/krb5.h: Merge stuff from removed headerfiles.
+
+	* lib/krb5/fcache.c: fcc_ops -> krb5_fcc_ops
+
+	* lib/krb5/mcache.c: mcc_ops -> krb5_mcc_ops
+
+Fri Aug 29 01:45:25 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/krb5.h: Remove all prototypes.
+
+	* lib/krb5/convert_creds.c: Use `struct credentials' instead of
+ 	`CREDENTIALS'.
+
+Fri Aug 29 00:08:18 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/gen_glue.c: new file. generates 2int and int2 functions
+	and units for bit strings.
+
+	* admin/util.c: flags2int, int2flags, and flag_units are now
+ 	generated by asn1_compile
+
+	* lib/roken/parse_units.c: generalised `parse_units' and
+ 	`unparse_units' and added new functions `parse_flags' and
+ 	`unparse_flags' that use these
+
+	* lib/krb5/krb5_locl.h: moved krb5_data* functions to krb5.h
+
+	* admin/util.c: Use {un,}parse_flags for printing and parsing
+ 	hdbflags.
+
+Thu Aug 28 03:26:12 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_addrs.c: restructured
+
+	* lib/krb5/warn.c (_warnerr): leak less memory
+
+	* lib/hdb/hdb.c (hdb_free_entry): zero keys
+	(hdb_check_db_format): leak less memory
+
+	* lib/hdb/ndbm.c (NDBM_seq): check for valid hdb_entries implement
+ 	NDBM__get, NDBM__put
+
+	* lib/hdb/db.c (DB_seq): check for valid hdb_entries
+
+Thu Aug 28 02:06:58 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/send_to_kdc.c: Don't use sendto on connected sockets.
+
+Thu Aug 28 01:13:17 1997  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kinit.1, klist.1, kdestroy.1: new man pages
+
+	* kpasswd/kpasswd.1, kpasswdd.8: new man pages
+
+	* kdc/kstash.8, hprop.8, hpropd.8: new man pages
+
+	* admin/ktutil.8, admin/kdb_edit.8: new man pages
+
+	* admin/mod.c: new file
+
+	* admin/life.c: renamed gettime and puttime to getlife and putlife
+	and moved them to life.c
+
+	* admin/util.c: add print_flags, parse_flags, init_entry,
+ 	set_created_by, set_modified_by, edit_entry, set_password.  Use
+ 	them.
+
+	* admin/get.c: use print_flags
+
+	* admin: removed unused stuff.  use krb5_{warn,err}*
+
+	* admin/ank.c: re-organized and abstracted.
+
+	* admin/gettime.c: removed
+
+Thu Aug 28 00:37:39 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/{get_cred,get_in_tkt}.c: Check for v4 reply.
+
+	* lib/roken/base64.c: Add base64 functions.
+
+	* kdc/connect.c lib/krb5/send_to_kdc.c: Add http support.
+
+Wed Aug 27 00:29:20 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* include/Makefile.am: Don't make links to built files.
+
+	* admin/kdb_edit.c: Add command to set the database path.
+
+	* lib/hdb: Include version number in database.
+
+Tue Aug 26 20:14:54 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* admin/ktutil: Merged v4 srvtab conversion.
+
+Mon Aug 25 23:02:18 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/roken/roken.h: add F_OK
+
+	* lib/gssapi/acquire_creds.c: fix typo
+
+	* configure.in: call AC_TYPE_MODE_T
+
+	* acinclude.m4: Add AC_TYPE_MODE_T
+
+Sun Aug 24 16:46:53 1997  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0f
+
+Sun Aug 24 08:06:54 1997  Assar Westerlund  <assar@sics.se>
+
+	* appl/popper/pop_pass.c: log poppers
+
+	* kdc/kaserver.c: some more checks
+
+	* kpasswd/kpasswd.c: removed `-p'
+
+	* kuser/kinit.c: removed `-p'
+
+	* lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): If
+ 	KDC_ERR_PREUATH_REQUIRED, add preauthentication and try again.
+
+	* lib/krb5/get_in_tkt.c (krb5_get_in_cred): don't print out
+ 	krb-error text
+
+	* lib/gssapi/import_name.c (input_name): more names types.
+
+	* admin/load.c (parse_keys): handle the case of an empty salt
+
+	* kdc/kaserver.c: fix up memory deallocation
+
+	* kdc/kaserver.c: quick hack at talking kaserver protocol
+
+	* kdc/kerberos4.c: Make `db-fetch4' global
+
+	* configure.in: add --enable-kaserver
+
+	* kdc/rx.h, kdc/kerberos4.h: new header files
+
+	* lib/krb5/principal.c: fix krb5_build_principal_ext & c:o
+
+Sun Aug 24 03:52:44 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/{get_in_tkt,mk_safe,mk_priv}.c: Fix some Cray specific
+ 	type conflicts.
+
+	* lib/krb5/{get_cred,get_in_tkt}.c: Mask nonce to 32 bits.
+
+	* lib/des/{md4,md5,sha}.c: Now works on Crays.
+
+Sat Aug 23 18:15:01 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* appl/afsutil/afslog.c: If no cells or files specified, get
+ 	tokens for all local cells. Better test for files.
+
+Thu Aug 21 23:33:38 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/gssapi/v1.c: new file with v1 compatibility functions.
+
+Thu Aug 21 20:36:13 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/kafs/afskrb5.c: Don't check ticket file for afs ticket.
+
+	* kdc/kerberos4.c: Check database when converting v4 principals.
+
+	* kdc/kerberos5.c: Include kvno in Ticket.
+
+	* lib/krb5/encrypt.c: Add kvno parameter to encrypt_EncryptedData.
+
+	* kuser/klist.c: Print version number of ticket, include more
+ 	flags.
+
+Wed Aug 20 21:26:58 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/kafs/afskrb5.c (get_cred): Check cached afs tickets for
+ 	expiration.
+
+Wed Aug 20 17:40:31 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/recvauth.c (krb5_recvauth): Send a KRB-ERROR iff
+ 	there's an error.
+
+	* lib/krb5/sendauth.c (krb5_sendauth): correct the protocol
+ 	documentation and process KRB-ERROR's
+
+Tue Aug 19 20:41:30 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos4.c: Fix memory leak in v4 protocol handler.
+
+Mon Aug 18 05:15:09 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/gssapi/accept_sec_context.c: Added
+ 	`gsskrb5_register_acceptor_identity'
+
+Sun Aug 17 01:40:20 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/gssapi/accept_sec_context.c (gss_accept_sec_context): don't
+ 	always pass server == NULL to krb5_rd_req.
+
+	* lib/gssapi: new files: canonicalize_name.c export_name.c
+ 	context_time.c compare_name.c release_cred.c acquire_cred.c
+ 	inquire_cred.c, from Luke Howard <lukeh@xedoc.com.au>
+
+	* lib/krb5/config_file.c: Add netinfo support from Luke Howard
+ 	<lukeh@xedoc.com.au>
+
+	* lib/editline/sysunix.c: sgtty-support from Luke Howard
+ 	<lukeh@xedoc.com.au>
+
+	* lib/krb5/principal.c: krb5_sname_to_principal fix from Luke
+ 	Howard <lukeh@xedoc.com.au>
+
+Sat Aug 16 00:44:47 1997  Assar Westerlund  <assar@koi.pdc.kth.se>
+
+	* Release 0.0e
+
+Sat Aug 16 00:23:46 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* appl/afsutil/afslog.c: Use new libkafs.
+
+	* lib/kafs/afskrb5.c: Get AFS tokens via 524 protocol.
+
+	* lib/krb5/warn.c: Fix format string for *x type.
+
+Fri Aug 15 22:15:01 1997  Assar Westerlund  <assar@sics.se>
+
+	* admin/get.c (get_entry): print more information about the entry
+
+	* lib/des/Makefile.am: build destest, mdtest, des, rpw, speed
+
+	* lib/krb5/config_file.c: new functions `krb5_config_get_time' and
+ 	`krb5_config_vget_time'.  Use them.
+
+Fri Aug 15 00:09:37 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* admin/ktutil.c: Keytab manipulation program.
+
+	* lib/krb5/keytab.c: Return sane values from resolve and
+ 	start_seq_get.
+
+	* kdc/kerberos5.c: Fix for old clients passing 0 for `no endtime'.
+
+	* lib/45/get_ad_tkt.c: Kerberos 4 get_ad_tkt using
+ 	krb524_convert_creds_kdc.
+
+	* lib/krb5/convert_creds.c: Implementation of
+ 	krb524_convert_creds_kdc.
+
+	* lib/asn1/k5.asn1: Make kdc-req-body.till OPTIONAL
+
+	* kdc/524.c: A somewhat working 524-protocol module.
+
+	* kdc/kerberos4.c: Add version 4 ticket encoding and encryption
+ 	functions.
+
+	* lib/krb5/context.c: Fix kdc_timeout.
+
+	* lib/hdb/{ndbm,db}.c: Free name in close.
+
+	* kdc/kerberos5.c (tgs_check_autenticator): Return error code
+
+Thu Aug 14 21:29:03 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c (tgs_make_reply): Fix endtime in reply.
+
+	* lib/krb5/store_emem.c: Fix reallocation bug.
+
+Tue Aug 12 01:29:46 1997  Assar Westerlund  <assar@sics.se>
+
+	* appl/telnet/libtelnet/kerberos5.c, appl/popper/pop_init.c: Use
+ 	`krb5_sock_to_principal'.  Send server parameter to
+ 	krb5_rd_req/krb5_recvauth.  Set addresses in auth_context.
+
+	* lib/krb5/recvauth.c: Set addresses in auth_context if there
+ 	aren't any
+
+	* lib/krb5/auth_context.c: New function
+ 	`krb5_auth_con_setaddrs_from_fd'
+
+	* lib/krb5/sock_principal.c: new function
+	`krb5_sock_to_principal'
+	
+	* lib/krb5/time.c: new file with `krb5_timeofday' and
+ 	`krb5_us_timeofday'.  Use these functions.
+
+	* kuser/klist.c: print KDC offset iff verbose
+
+	* lib/krb5/get_in_tkt.c: implement KDC time offset and use it if
+ 	[libdefaults]kdc_timesync is set.
+	
+	* lib/krb5/fcache.c: Implement version 4 of the ccache format.
+
+Mon Aug 11 05:34:43 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_rep.c (krb5_free_ap_rep_enc_part): free all memory
+
+	* lib/krb5/principal.c (krb5_unparse_name): allocate memory
+ 	properly
+
+	* kpasswd/kpasswd.c: Use `krb5_change_password'
+
+	* lib/krb5/init_creds_pw.c (init_cred): set realm of server
+ 	correctly.
+
+	* lib/krb5/init_creds_pw.c: support changing of password when it
+ 	has expired
+
+	* lib/krb5/changepw.c: new file
+
+	* kuser/klist.c: use getarg
+
+	* admin/init.c (init): add `kadmin/changepw'
+
+Mon Aug 11 04:30:47 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_cred.c: Make get_credentials handle cross-realm.
+
+Mon Aug 11 00:03:24 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/config_file.c: implement support for #-comments
+
+Sat Aug  9 02:21:46 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/hprop*.c: Add database propagation programs.
+
+	* kdc/connect.c: Max request size.
+
+Sat Aug  9 00:47:28 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/otp: resurrected from krb4
+
+	* appl/push: new program for fetching mail with POP.
+
+	* appl/popper/popper.h: new include files.  new fields in `POP'
+
+	* appl/popper/pop_pass.c: Implement both v4 and v5.
+
+	* appl/popper/pop_init.c: Implement both v4 and v5.
+
+	* appl/popper/pop_debug.c: use getarg.  Talk both v4 and v5
+
+	* appl/popper: Popper from krb4.
+
+	* configure.in: check for inline and <netinet/tcp.h> generate
+ 	files in appl/popper, appl/push, and lib/otp
+
+Fri Aug  8 05:51:02 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_cred.c: clean-up and try to free memory even when
+ 	there're errors
+
+	* lib/krb5/get_cred.c: adapt to new `extract_ticket'
+
+	* lib/krb5/get_in_tkt.c: reorganize.  check everything and try to
+ 	return memory even if there are errors.
+
+	* kuser/kverify.c: new file
+
+	* lib/krb5/free_host_realm.c: new file
+
+	* lib/krb5/principal.c (krb5_sname_to_principal): implement
+ 	different nametypes.  Also free memory.
+
+	* lib/krb5/verify_init.c: more functionality
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_extended): free the checksum
+
+	* lib/krb5/get_in_tkt.c (extract_ticket): don't copy over the
+ 	principals in creds.  Should also compare them with that received
+ 	from the KDC
+
+	* lib/krb5/cache.c (krb5_cc_gen_new): copy the newly allocated
+ 	krb5_ccache
+	(krb5_cc_destroy): call krb5_cc_close
+	(krb5_cc_retrieve_cred): delete the unused creds
+
+Fri Aug  8 02:30:40 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/log.c: Allow better control of destinations of logging
+ 	(like passing explicit destinations, and log-functions).
+
+Fri Aug  8 01:20:39 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_default_principal.c: new file
+
+	* kpasswd/kpasswdd.c: use krb5_log*
+
+Fri Aug  8 00:37:47 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/init_creds_pw.c: Implement krb5_get_init_creds_keytab.
+
+Fri Aug  8 00:37:17 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/init_creds_pw.c: Use `krb5_get_default_principal'.
+  	Print password expire information.
+
+	* kdc/config.c: new variable `kdc_warn_pwexpire'
+
+	* kpasswd/kpasswd.c: converted to getarg and get_init_creds
+
+Thu Aug  7 22:17:09 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mcache.c: new file
+
+	* admin/gettime.c: new function puttime.  Use it.
+
+	* lib/krb5/keyblock.c: Added krb5_free_keyblock and
+ 	krb5_copy_keyblock
+
+	* lib/krb5/init_creds_pw.c: more functionality
+
+	* lib/krb5/creds.c: Added krb5_free_creds_contents and
+ 	krb5_copy_creds.  Changed callers.
+
+	* lib/krb5/config_file.c: new functions krb5_config_get and
+ 	krb5_config_vget
+
+	* lib/krb5/cache.c: cleanup added mcache
+	
+	* kdc/kerberos5.c: include last-req's of type 6 and 7, if
+ 	applicable
+
+Wed Aug  6 20:38:23 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/log.c: New parameter `log-level'. Default to `SYSLOG'.
+
+Tue Aug  5 22:53:54 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/verify_init.c, init_creds_pw.c, init_creds.c,
+	prompter_posix.c: the beginning of an implementation of the cygnus
+	initial-ticket API.
+
+	* lib/krb5/get_in_tkt_pw.c: make `krb5_password_key_proc' global
+
+	* lib/krb5/get_in_tkt.c (krb5_get_in_cred): new function that is
+ 	almost krb5_get_in_tkt but doesn't write the creds to the ccache.
+  	Small fixes in krb5_get_in_tkt
+
+	* lib/krb5/get_addrs.c (krb5_get_all_client_addrs): don't include
+ 	loopback.
+
+Mon Aug  4 20:20:48 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc: Make context global.
+
+Fri Aug  1 17:23:56 1997  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0d
+
+	* lib/roken/flock.c: new file
+
+	* kuser/kinit.c: check for and print expiry information in the
+ 	`kdc_rep'
+
+	* lib/krb5/get_in_tkt.c: Set `ret_as_reply' if != NULL
+
+	* kdc/kerberos5.c: Check the valid times on client and server.
+  	Check the password expiration.
+	Check the require_preauth flag.
+  	Send an lr_type == 6 with pw_end.
+	Set key.expiration to min(valid_end, pw_end)
+	
+	* lib/hdb/hdb.asn1: new flags `require_preauth' and `change_pw'
+
+	* admin/util.c, admin/load.c: handle the new flags.
+
+Fri Aug  1 16:56:12 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/hdb: Add some simple locking.
+
+Sun Jul 27 04:44:31 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/log.c: Add some general logging functions.
+
+	* kdc/kerberos4.c: Add version 4 protocol handler. The requrement
+ 	for this to work is that all involved principals has a des key in
+ 	the database, and that the client has a version 4 (un-)salted
+ 	key. Furthermore krb5_425_conv_principal has to do it's job, as
+ 	present it's not very clever.
+
+	* lib/krb5/principal.c: Quick patch to make 425_conv work
+ 	somewhat.
+
+	* lib/hdb/hdb.c: Add keytype->key and next key functions.
+
+Fri Jul 25 17:32:12 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/build_auth.c (krb5_build_authenticator): don't free
+ 	`cksum'.  It's allocated and freed by the caller
+
+	* lib/krb5/get_cred.c (krb5_get_kdc_cred): Don't free `addresses'.
+
+	* kdc/kerberos5.c (tgs_rep2): make sure we also have an defined
+ 	`client' to return as part of the KRB-ERROR
+
+Thu Jul 24 08:13:59 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c: Unseal keys from database before use.
+
+	* kdc/misc.c: New functions set_master_key, unseal_key and
+ 	free_key.
+
+	* lib/roken/getarg.c: Handle `-f arg' correctly.
+
+Thu Jul 24 01:54:43 1997  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kinit.c: implement `-l' aka `--lifetime'
+
+	* lib/roken/parse_units.c, parse_time.c: new files
+
+	* admin/gettime.c (gettime): use `parse_time'
+
+	* kdc/kerberos5.c (as_rep): Use `METHOD-DATA' when sending
+ 	KRB5KDC_ERR_PREAUTH_REQUIRED, not PA-DATA.
+
+	* kpasswd/kpasswdd.c: fix freeing bug use sequence numbers set
+ 	addresses in auth_context bind one socket per interface.
+	
+	* kpasswd/kpasswd.c: use sequence numbers
+
+	* lib/krb5/rd_req.c (krb5_verify_ap_req): do abs when verifying
+ 	the timestamps
+
+	* lib/krb5/rd_priv.c (krb5_rd_priv): Fetch the correct session key
+ 	from auth_context
+
+	* lib/krb5/mk_priv.c (krb5_mk_priv): Fetch the correct session key
+ 	from auth_context
+
+	* lib/krb5/mk_error.c (krb5_mk_error): return an error number and
+ 	not a comerr'd number.
+
+	* lib/krb5/get_in_tkt.c (krb5_get_in_tkt): interpret the error
+ 	number in KRB-ERROR correctly.
+
+	* lib/krb5/get_cred.c (krb5_get_kdc_cred): interpret the error
+ 	number in KRB-ERROR correctly.
+
+	* lib/asn1/k5.asn1: Add `METHOD-DATA'
+
+	* removed some memory leaks.
+
+Wed Jul 23 07:53:18 1997  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.0c
+
+	* lib/krb5/rd_cred.c, get_for_creds.c: new files
+
+	* lib/krb5/get_host_realm.c: try default realm as last chance
+
+	* kpasswd/kpasswdd.c: updated to hdb changes
+
+	* appl/telnet/libtelnet/kerberos5.c: Implement forwarding
+
+	* appl/telnet/libtelnet: removed totally unused files
+
+	* admin/ank.c: fix prompts and generation of random keys
+
+Wed Jul 23 04:02:32 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* admin/dump.c: Include salt in dump.
+
+	* admin: Mostly updated for new db-format.
+
+	* kdc/kerberos5.c: Update to use new db format. Better checking of
+ 	flags and such. More logging.
+
+	* lib/hdb/hdb.c: Use generated encode and decode functions.
+
+	* lib/hdb/hdb.h: Get hdb_entry from ASN.1 generated code.
+
+	* lib/krb5/get_cred.c: Get addresses from krbtgt if there are none
+ 	in the reply.
+
+Sun Jul 20 16:22:30 1997  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kinit.c: break if des_read_pw_string() != 0
+
+	* kpasswd/kpasswdd.c: send a reply
+
+	* kpasswd/kpasswd.c: restructured code.  better report on
+ 	krb-error break if des_read_pw_string() != 0
+
+	* kdc/kerberos5.c: Check `require_enc_timestamp' malloc space for
+ 	starttime and renew_till
+
+	* appl/telnet/libtelnet/kerberos5.c (kerberos5_is): Send a
+ 	keyblock to krb5_verify_chekcsum
+
+Sun Jul 20 06:35:46 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* Release 0.0b
+
+	* kpasswd/kpasswd.c: Avoid using non-standard struct names.
+
+Sat Jul 19 19:26:23 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/keytab.c (krb5_kt_get_entry): check return from
+ 	`krb5_kt_start_seq_get'.  From <map@stacken.kth.se>
+
+Sat Jul 19 04:07:39 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/asn1/k5.asn1: Update with more pa-data types from
+ 	draft-ietf-cat-kerberos-revisions-00.txt
+
+	* admin/load.c: Update to match current db-format.
+
+	* kdc/kerberos5.c (as_rep): Try all valid pa-datas before giving
+ 	up. Send back an empty pa-data if the client has the v4 flag set.
+
+	* lib/krb5/get_in_tkt.c: Pass both version5 and version4 salted
+ 	pa-data. DTRT if there is any pa-data in the reply.
+
+	* lib/krb5/str2key.c: XOR with some sane value.
+
+	* lib/hdb/hdb.h: Add `version 4 salted key' flag.
+
+	* kuser/kinit.c: Ask for password before calling get_in_tkt. This
+ 	makes it possible to call key_proc more than once.
+
+	* kdc/string2key.c: Add flags to output version 5 (DES only),
+ 	version 4, and AFS string-to-key of a password.
+
+	* lib/asn1/gen_copy.c: copy_* functions now returns an int (0 or
+ 	ENOMEM).
+
+Fri Jul 18 02:54:58 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_host_realm.c (krb5_get_host_realm): do the
+ 	name2name thing
+
+	* kdc/misc.c: check result of hdb_open
+
+	* admin/kdb_edit: updated to new sl
+
+	* lib/sl: sl_func now returns an int. != 0 means to exit.
+
+	* kpasswd/kpasswdd: A crude (but somewhat working) implementation
+ 	of `draft-ietf-cat-kerb-chg-password-00.txt'
+
+Fri Jul 18 00:55:39 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kuser/krenew.c: Crude ticket renewing program.
+
+	* kdc/kerberos5.c: Rewritten flags parsing, it now might work to
+ 	get forwarded and renewed tickets.
+
+	* kuser/kinit.c: Add `-r' flag.
+
+	* lib/krb5/get_cred.c: Move most of contents of get_creds to new
+ 	function get_kdc_cred, that always contacts the kdc and doesn't
+ 	save in the cache. This is a hack.
+
+	* lib/krb5/get_in_tkt.c: Pass starttime and renew_till in request
+ 	(a bit kludgy).
+
+	* lib/krb5/mk_req_ext.c: Make an auth_context if none passed in.
+
+	* lib/krb5/send_to_kdc.c: Get timeout from context.
+
+	* lib/krb5/context.c: Add kdc_timeout to context struct.
+
+Thu Jul 17 20:35:45 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kuser/klist.c: Print start time of ticket if available.
+
+	* lib/krb5/get_host_realm.c: Return error if no realm was found.
+
+Thu Jul 17 20:28:21 1997  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd: non-working kpasswd added
+
+Thu Jul 17 00:21:22 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* Release 0.0a
+
+	* kdc/main.c: Add -p flag to disable pa-enc-timestamp requirement.
+
+Wed Jul 16 03:37:41 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/kerberos5.c (tgs_rep2): Free ticket and ap_req.
+
+	* lib/krb5/auth_context.c (krb5_auth_con_free): Free remote
+ 	subkey.
+
+	* lib/krb5/principal.c (krb5_free_principal): Check for NULL.
+
+	* lib/krb5/send_to_kdc.c: Check for NULL return from
+ 	gethostbyname.
+
+	* lib/krb5/set_default_realm.c: Try to get realm of local host if
+ 	no default realm is available.
+
+	* Remove non ASN.1 principal code.
+
+Wed Jul 16 03:17:30 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/kerberos5.c: Split tgs_rep in smaller functions. Add better
+ 	error handing. Do some logging.
+
+	* kdc/log.c: Some simple logging facilities.
+
+	* kdc/misc.c (db_fetch): Take a krb5_principal.
+
+	* kdc/connect.c: Pass address of request to as_rep and
+ 	tgs_rep. Send KRB-ERROR.
+
+	* lib/krb5/mk_error.c: Add more fields.
+
+	* lib/krb5/get_cred.c: Print normal error code if no e_text is
+ 	available.
+
+Wed Jul 16 03:07:50 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_in_tkt.c: implement `krb5_init_etype'.
+ 	Change encryption type of pa_enc_timestamp to DES-CBC-MD5
+
+	* lib/krb5/context.c: recognize all encryption types actually
+ 	implemented
+
+	* lib/krb5/auth_context.c (krb5_auth_con_init): Change default
+ 	encryption type to `DES_CBC_MD5'
+
+	*  lib/krb5/read_message.c, write_message.c: new files
+
+Tue Jul 15 17:14:21 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1: replaced asn1_locl.h by `der_locl.h' and `gen_locl.h'.
+
+	* lib/error/compile_et.awk: generate a prototype for the
+ 	`destroy_foo_error_table' function.
+
+Mon Jul 14 12:24:40 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krbhst.c (krb5_get_krbhst): Get all kdc's and try also
+ 	with `kerberos.REALM'
+
+	* kdc/kerberos5.c, lib/krb5/rd_priv.c, lib/krb5/rd_safe.c: use
+ 	`max_skew'
+
+	* lib/krb5/rd_req.c (krb5_verify_ap_req): record authenticator
+ 	subkey
+
+	* lib/krb5/build_auth.c (krb5_build_authenticator): always
+ 	generate a subkey.
+
+	* lib/krb5/address.c: implement `krb5_address_order'
+
+	* lib/gssapi/import_name.c: Implement `gss_import_name'
+
+	* lib/gssapi/external.c: Use new OID
+
+	* lib/gssapi/encapsulate.c: New functions
+ 	`gssapi_krb5_encap_length' and `gssapi_krb5_make_header'.  Changed
+	callers.
+
+	* lib/gssapi/decapsulate.c: New function
+ 	`gssaspi_krb5_verify_header'.  Changed callers.
+
+	* lib/asn1/gen*.c: Give tags to generated structs.
+	Use `err' and `asprintf'
+
+	* appl/test/gss_common.c: new file
+
+	* appl/test/gssapi_server.c: removed all krb5 calls
+
+	* appl/telnet/libtelnet/kerberos5.c: Add support for genering and
+ 	verifying checksums.  Also start using session subkeys.
+
+Mon Jul 14 12:08:25 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/rd_req.c (krb5_rd_req_with_keyblock): Split up.
+
+Sun Jul 13 03:07:44 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_safe.c, mk_safe.c: made bug-compatible with MIT
+
+	* lib/krb5/encrypt.c: new functions `DES_encrypt_null_ivec' and
+ 	`DES_encrypt_key_ivec'
+
+	* lib/krb5/checksum.c: implement rsa-md4-des and rsa-md5-des
+
+	* kdc/kerberos5.c (tgs_rep): support keyed checksums
+
+	* lib/krb5/creds.c: new file
+
+	* lib/krb5/get_in_tkt.c: better freeing
+
+	* lib/krb5/context.c (krb5_free_context): more freeing
+
+	* lib/krb5/config_file.c: New function `krb5_config_file_free'
+
+	* lib/error/compile_et.awk: Generate a `destroy_' function.
+
+	* kuser/kinit.c, klist.c: Don't leak memory.
+
+Sun Jul 13 02:46:27 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kdc/connect.c: Check filedescriptor in select.
+
+	* kdc/kerberos5.c: Remove most of the most common memory leaks.
+
+	* lib/krb5/rd_req.c: Free allocated data.
+
+	* lib/krb5/auth_context.c (krb5_auth_con_free): Free a lot of
+ 	fields.
+
+Sun Jul 13 00:32:16 1997  Assar Westerlund  <assar@sics.se>
+
+	* appl/telnet: Conditionalize the krb4-support.
+
+	* configure.in: Test for krb4
+
+Sat Jul 12 17:14:12 1997  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos5.c: check if the pre-auth was decrypted properly.
+  	set the `pre_authent' flag
+
+	* lib/krb5/get_cred.c, lib/krb5/get_in_tkt.c: generate a random nonce.
+
+	* lib/krb5/encrypt.c: Made `generate_random_block' global.
+
+	* appl/test: Added gssapi_client and gssapi_server.
+
+	* lib/krb5/data.c: Add `krb5_data_zero'
+
+	* appl/test/tcp_client.c: try `mk_safe' and `mk_priv'
+
+	* appl/test/tcp_server.c: try `rd_safe' and `rd_priv'
+
+Sat Jul 12 16:45:58 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_addrs.c: Fix for systems that has sa_len, but
+ 	returns zero length from SIOCGIFCONF.
+
+Sat Jul 12 16:38:34 1997  Assar Westerlund  <assar@sics.se>
+
+	* appl/test: new programs
+	
+	* lib/krb5/rd_req.c: add address compare
+
+	* lib/krb5/mk_req_ext.c: allow no checksum
+
+	* lib/krb5/keytab.c (krb5_kt_ret_string): 0-terminate string
+
+	* lib/krb5/address.c: fix `krb5_address_compare'
+
+Sat Jul 12 15:03:16 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/get_addrs.c: Fix ip4 address extraction.
+
+	* kuser/klist.c: Add verbose flag, and split main into smaller
+ 	pieces.
+
+	* lib/krb5/fcache.c: Save ticket flags.
+
+	* lib/krb5/get_in_tkt.c (extract_ticket): Extract addresses and
+ 	flags.
+
+	* lib/krb5/krb5.h: Add ticket_flags to krb5_creds.
+
+Sat Jul 12 13:12:48 1997  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: Call `AC_KRB_PROG_LN_S'
+
+	* acinclude.m4: Add `AC_KRB_PROG_LN_S' from krb4
+
+Sat Jul 12 00:57:01 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/get_in_tkt.c: Use union of krb5_flags and KDCOptions to
+ 	pass options.
+
+Fri Jul 11 15:04:22 1997  Assar Westerlund  <assar@sics.se>
+
+	* appl/telnet: telnet & telnetd seems to be working.
+	
+	* lib/krb5/config_file.c: Added krb5_config_v?get_list Fixed
+ 	krb5_config_vget_next
+
+	* appl/telnet/libtelnet/kerberos5.c: update to current API
+
+Thu Jul 10 14:54:39 1997  Assar Westerlund  <assar@sics.se>
+
+	* appl/telnet/libtelnet/kerberos5.c (kerberos5_status): call
+ 	`krb5_kuserok'
+
+	* appl/telnet: Added.
+
+Thu Jul 10 05:09:25 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/error/compile_et.awk: Remove usage of sub, gsub, and
+ 	functions for compatibility with awk.
+
+	* include/bits.c: Must use signed char.
+
+	* lib/krb5/context.c: Move krb5_get_err_text, and krb5_init_ets
+ 	here.
+
+	* lib/error/error.c: Replace krb5_get_err_text with new function
+ 	com_right.
+
+	* lib/error/compile_et.awk: Avoid using static variables.
+
+	* lib/error/error.c: Don't use krb5_locl.h
+
+	* lib/error/error.h: Move definitions of error_table and
+ 	error_list from krb5.h.
+
+	* lib/error: Moved from lib/krb5.
+
+Wed Jul  9 07:42:04 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/encrypt.c: Temporary hack to avoid des_rand_data.
+
+Wed Jul  9 06:58:00 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/{rd,mk}_{*}.c: more checking for addresses and stuff
+	according to pseudocode from 1510
+
+Wed Jul  9 06:06:06 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/hdb/hdb.c: Add hdb_etype2key.
+
+	* kdc/kerberos5.c: Check authenticator. Use more general etype
+ 	functions.
+	
+Wed Jul  9 03:51:12 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/k5.asn1: Made all `s_address' OPTIONAL according to
+ 	draft-ietf-cat-kerberos-r-00.txt
+
+	* lib/krb5/principal.c (krb5_parse_name): default to local realm
+ 	if none given
+	
+	* kuser/kinit.c: New option `-p' and prompt
+
+Wed Jul  9 02:30:06 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/keyblock.c: Keyblock generation functions.
+
+	* lib/krb5/encrypt.c: Use functions from checksum.c.
+
+	* lib/krb5/checksum.c: Move checksum functions here. Add
+ 	krb5_cksumsize function.
+
+Wed Jul  9 01:15:38 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_host_realm.c: implemented
+
+	* lib/krb5/config_file.c: Redid part.  New functions:
+ 	krb5_config_v?get_next
+
+	* kuser/kdestroy.c: new program
+
+	* kuser/kinit.c: new flag `-f'
+
+	* lib/asn1/k5.asn1: Made HostAddresses = SEQUENCE OF HostAddress
+
+	* acinclude.m4: Added AC_KRB_STRUCT_SOCKADDR_SA_LEN
+
+	* lib/krb5/krb5.h: krb5_addresses == HostAddresses.  Changed all
+ 	users.
+
+	* lib/krb5/get_addrs.c: figure out all local addresses, possibly
+ 	even IPv6!
+
+	* lib/krb5/checksum.c: table-driven checksum
+
+Mon Jul  7 21:13:28 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/encrypt.c: Make krb5_decrypt use the same struct as
+ 	krb5_encrypt.
+
+Mon Jul  7 11:15:51 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/roken/vsyslog.c: new file
+
+	* lib/krb5/encrypt.c: add des-cbc-md4.
+	adjust krb5_encrypt and krb5_decrypt to reality
+
+Mon Jul  7 02:46:31 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/encrypt.c: Implement as a vector of function pointers.
+
+	* lib/krb5/{decrypt,encrypt}.c: Implement des-cbc-crc, and
+ 	des-cbc-md5 in separate functions.
+
+	* lib/krb5/krb5.h: Add more checksum and encryption types.
+
+	* lib/krb5/krb5_locl.h: Add etype to krb5_decrypt.
+
+Sun Jul  6 23:02:59 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/[gs]et_default_realm.c, kuserok.c: new files
+
+	* lib/krb5/config_file.[ch]: new c-based configuration reading
+ 	stuff
+
+Wed Jul  2 23:12:56 1997  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: Set WFLAGS if using gcc
+
+Wed Jul  2 17:47:03 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/asn1/der_put.c (der_put_int): Return size correctly.
+
+	* admin/ank.c: Be compatible with the asn1 principal format.
+
+Wed Jul  1 23:52:20 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/asn1: Now all decode_* and encode_* functions now take a
+ 	final size_t* argument, that they return the size in. Return
+ 	values are zero for success, and anything else (such as some
+ 	ASN1_* constant) for error.
+
+Mon Jun 30 06:08:14 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/keytab.c (krb5_kt_add_entry): change open mode to
+ 	O_WRONLY | O_APPEND
+
+	* lib/krb5/get_cred.c: removed stale prototype for
+ 	`extract_ticket' and corrected call.
+
+	* lib/asn1/gen_length.c (length_type): Make the length functions
+ 	for SequenceOf non-destructive
+
+	* admin/ank.c (doit): Fix reading of `y/n'.
+
+Mon Jun 16 05:41:43 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/gssapi/wrap.c, unwrap.c: do encrypt and add sequence number
+
+	* lib/gssapi/get_mic.c, verify_mic.c: Add sequence number.
+
+	* lib/gssapi/accept_sec_context.c (gss_accept_sec_context): Set
+ 	KRB5_AUTH_CONTEXT_DO_SEQUENCE.  Verify 8003 checksum.
+
+	* lib/gssapi/8003.c: New file.
+
+	* lib/krb/krb5.h: Define a `krb_authenticator' as an ASN.1
+ 	Authenticator.
+
+	* lib/krb5/auth_context.c: New functions
+ 	`krb5_auth_setlocalseqnumber' and `krb5_auth_setremoteseqnumber'
+
+Tue Jun 10 00:35:54 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5: Preapre for use of some asn1-types.
+
+	* lib/asn1/*.c (copy_*): Constness.
+
+	* lib/krb5/krb5.h: Include asn1.h; krb5_data is now an
+ 	octet_string.
+
+	* lib/asn1/der*,gen.c: krb5_data -> octet_string, char * ->
+ 	general_string
+
+	* lib/asn1/libasn1.h: Moved stuff from asn1_locl.h that doesn't
+ 	have anything to do with asn1_compile.
+
+	* lib/asn1/asn1_locl.h: Remove der.h. Add some prototypes.
+
+Sun Jun  8 03:51:55 1997  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos5.c: Fix PA-ENC-TS-ENC
+
+ 	* kdc/connect.c(process_request): Set `new'
+	
+	* lib/krb5/get_in_tkt.c: Do PA-ENC-TS-ENC the correct way.
+
+	* lib: Added editline,sl,roken.
+
+Mon Jun  2 00:37:48 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/fcache.c: Move file cache from cache.c.
+
+	* lib/krb5/cache.c: Allow more than one cache type.
+
+Sun Jun  1 23:45:33 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* admin/extkeytab.c: Merged with kdb_edit.
+
+Sun Jun  1 23:23:08 1997  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kdc.c: more support for ENC-TS-ENC
+
+	* lib/krb5/get_in_tkt.c: redone to enable pre-authentication
+
+Sun Jun  1 22:45:11 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/hdb/db.c: Merge fetch and store.
+
+	* admin: Merge to one program.
+
+	* lib/krb5/str2key.c: Fill in keytype and length.
+
+Sun Jun  1 16:31:23 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_safe.c, lib/krb5/rd_priv.c, lib/krb5/mk_rep.c,
+ 	lib/krb5/mk_priv.c, lib/krb5/build_auth.c: Some support for
+ 	KRB5_AUTH_CONTEXT_DO_SEQUENCE
+
+	* lib/krb5/get_in_tkt.c (get_in_tkt): be prepared to parse an
+ 	KRB_ERROR.  Some support for PA_ENC_TS_ENC.
+
+	* lib/krb5/auth_context.c: implemented seq_number functions
+
+	* lib/krb5/generate_subkey.c, generate_seq_number.c: new files
+
+	* lib/gssapi/gssapi.h: avoid including <krb5.h>
+
+	* lib/asn1/Makefile.am: SUFFIXES as a variable to make automake
+ 	happy
+
+	* kdc/kdc.c: preliminary PREAUTH_ENC_TIMESTAMP
+
+	* configure.in: adapted to automake 1.1p
+
+Mon May 26 22:26:21 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/principal.c: Add contexts to many functions.
+
+Thu May 15 20:25:37 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/verify_user.c: First stab at a verify user.
+
+	* lib/auth/sia/sia5.c: SIA module for Kerberos 5.
+
+Mon Apr 14 00:09:03 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/gssapi: Enough of a gssapi-over-krb5 implementation to be
+	able to (mostly) run gss-client and gss-server.
+	
+	* lib/krb5/keytab.c: implemented krb5_kt_add_entry,
+ 	krb5_kt_store_principal, krb5_kt_store_keyblock
+
+	* lib/des/md5.[ch], sha.[ch]: new files
+
+	* lib/asn1/der_get.c (generalizedtime2time): use `timegm'
+
+	* lib/asn1/timegm.c: new file
+
+	* admin/extkeytab.c: new program
+
+	* admin/admin_locl.h: new file
+
+	* admin/Makefile.am: Added extkeytab
+
+	* configure.in: moved config to include
+	removed timezone garbage
+	added lib/gssapi and admin
+
+	* Makefile.am: Added admin
+
+Mon Mar 17 11:34:05 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/kdc.c: Use new copying functions, and free some data.
+
+	* lib/asn1/Makefile.am: Try to not always rebuild generated files.
+
+	* lib/asn1/der_put.c: Add fix_dce().
+
+	* lib/asn1/der_{get,length,put}.c: Fix include files.
+
+	* lib/asn1/der_free.c: Remove unused functions.
+	
+	* lib/asn1/gen.c: Split into gen_encode, gen_decode, gen_free,
+ 	gen_length, and gen_copy.
+
+Sun Mar 16 18:13:52 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/sendauth.c: implemented functionality
+
+	* lib/krb5/rd_rep.c: Use `krb5_decrypt'
+
+	* lib/krb5/cache.c (krb5_cc_get_name): return default if `id' ==
+ 	NULL
+
+	* lib/krb5/principal.c (krb5_free_principal): added `context'
+ 	argument.  Changed all callers.
+	
+	(krb5_sname_to_principal): new function
+
+	* lib/krb5/auth_context.c (krb5_free_authenticator): add `context'
+ 	argument.  Changed all callers
+
+	* lib/krb5/{net_write.c,net_read.c,recvauth.c}: new files
+
+	* lib/asn1/gen.c: Fix encoding and decoding of BitStrings
+
+Fri Mar 14 11:29:00 1997  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: look for *dbm?
+
+	* lib/asn1/gen.c: Fix filename in generated files. Check fopens.
+  	Put trailing newline in asn1_files.
+
+Fri Mar 14 05:06:44 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/get_in_tkt.c: Fix some memory leaks.
+
+	* lib/krb5/krbhst.c: Properly free hostlist.
+
+	* lib/krb5/decrypt.c: CRCs are 32 bits.
+
+Fri Mar 14 04:39:15 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/asn1/gen.c: Generate one file for each type.
+
+Fri Mar 14 04:13:47 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/gen.c: Generate `length_FOO' functions
+
+	* lib/asn1/der_length.c: new file
+
+	* kuser/klist.c: renamed stime -> printable_time to avoid conflict
+ 	on HP/UX
+
+Fri Mar 14 03:37:23 1997  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/hdb/ndbm.c: Return NOENTRY if fetch fails. Don't free
+ 	datums. Don't add .db to filename.
+
+Fri Mar 14 02:49:51 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/dump.c: Database dump program.
+
+	* kdc/ank.c: Trivial database editing program.
+
+	* kdc/{kdc.c, load.c}: Use libhdb.
+
+	* lib/hdb: New database routine library.
+
+	* lib/krb5/error/Makefile.am: Add hdb_err.
+
+Wed Mar 12 17:41:14 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* kdc/kdc.c: Rewritten AS, and somewhat more working TGS support.
+
+	* lib/asn1/gen.c: Generate free functions.
+
+	* Some specific free functions.
+
+Wed Mar 12 12:30:13 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krb5_mk_req_ext.c: new file
+
+	* lib/asn1/gen.c: optimize the case with a simple type
+
+	* lib/krb5/get_cred.c (krb5_get_credentials): Use
+ 	`mk_req_extended' and remove old code.
+
+	* lib/krb5/get_in_tkt.c (decrypt_tkt): First try with an
+ 	EncASRepPart, then with an EncTGSRepPart.
+
+Wed Mar 12 08:26:04 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/store_emem.c: New resizable memory storage.
+
+	* lib/krb5/{store.c, store_fd.c, store_mem.c}: Split of store.c
+
+	* lib/krb5/krb5.h: Add free entry to krb5_storage.
+
+	* lib/krb5/decrypt.c: Make keyblock const.
+
+Tue Mar 11 20:22:17 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/krb5.h: Add EncTicketPart to krb5_ticket.
+
+	* lib/krb5/rd_req.c: Return whole asn.1 ticket in
+ 	krb5_ticket->tkt.
+
+	* lib/krb5/get_in_tkt.c: TGS -> AS
+
+	* kuser/kfoo.c: Print error string rather than number.
+
+	* kdc/kdc.c: Some kind of non-working TGS support.
+
+Mon Mar 10 01:43:22 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/gen.c: reduced generated code by 1/5
+
+ 	* lib/asn1/der_put.c: (der_put_length_and_tag): new function
+
+	* lib/asn1/der_get.c (der_match_tag_and_length): new function
+
+	* lib/asn1/der.h: added prototypes
+
+Mon Mar 10 01:15:43 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/krb5.h: Include <asn1_err.h>. Add prototype for
+ 	krb5_rd_req_with_keyblock.
+
+	* lib/krb5/rd_req.c: Add function krb5_rd_req_with_keyblock that
+ 	takes a precomputed keyblock.
+
+	* lib/krb5/get_cred.c: Use krb5_mk_req rather than inlined code.
+
+	* lib/krb5/mk_req.c: Calculate checksum of in_data.
+
+Sun Mar  9 21:17:58 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/error/compile_et.awk: Add a declaration of struct
+ 	error_list, and multiple inclusion block to header files.
+
+Sun Mar  9 21:01:12 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_req.c: do some checks on times
+
+	* lib/krb/{mk_priv.c, rd_priv.c, sendauth.c, decrypt.c,
+	address.c}: new files
+
+	* lib/krb5/auth_context.c: more code
+
+	* configure.in: try to figure out timezone
+
+Sat Mar  8 11:41:07 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/error/error.c: Try strerror if error code wasn't found.
+
+	* lib/krb5/get_in_tkt.c: Remove realm parameter from
+ 	krb5_get_salt.
+
+	* lib/krb5/context.c: Initialize error table.
+
+	* kdc: The beginnings of a kdc.
+
+Sat Mar  8 08:16:28 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_safe.c: new file
+
+	* lib/krb5/checksum.c (krb5_verify_checksum): New function
+
+	* lib/krb5/get_cred.c: use krb5_create_checksum
+
+	* lib/krb5/checksum.c: new file
+
+	* lib/krb5/store.c: no more arithmetic with void*
+
+	* lib/krb5/cache.c: now seems to work again
+
+Sat Mar  8 06:58:09 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/Makefile.am: Add asn1_glue.c and error/*.c to libkrb5.
+
+	* lib/krb5/get_in_tkt.c: Moved some functions to asn1_glue.c.
+
+	* lib/krb5/asn1_glue.c: Moved some asn1-stuff here.
+	
+	* lib/krb5/{cache,keytab}.c: Use new storage functions.
+
+	* lib/krb5/krb5.h: Protypes for new storage functions.
+
+	* lib/krb5/krb5.h: Make krb5_{ret,store}_* functions able to write
+ 	data to more than file descriptors.
+
+Sat Mar  8 01:01:17 1997  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/encrypt.c: New file.
+
+	* lib/krb5/Makefile.am: More -I
+
+	* configure.in: Test for big endian, random, rand, setitimer
+
+	* lib/asn1/gen.c: perhaps even decodes bitstrings
+
+Thu Mar  6 19:05:29 1997  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/config_file.y: Better return values on error.
+
+Sat Feb  8 15:59:56 1997  Assar Westerlund  <assar@pdc.kth.se>
+
+	* lib/asn1/parse.y: ifdef HAVE_STRDUP
+
+	* lib/asn1/lex.l: ifdef strdup
+	brange-dead version of list of special characters to make stupid
+ 	lex accept it.
+
+	* lib/asn1/gen.c: A DER integer should really be a `unsigned'
+
+	* lib/asn1/der_put.c: A DER integer should really be a `unsigned'
+
+	* lib/asn1/der_get.c: A DER integer should really be a `unsigned'
+
+	* lib/krb5/error/Makefile.am: It seems "$(SHELL) ./compile_et" is
+ 	needed.
+
+	* lib/krb/mk_rep.c, lib/krb/rd_req.c, lib/krb/store.c,
+ 	lib/krb/store.h: new files.
+
+	* lib/krb5/keytab.c: now even with some functionality.
+
+	* lib/asn1/gen.c: changed paramater from void * to Foo *
+
+	* lib/asn1/der_get.c (der_get_octet_string): Fixed bug with empty
+ 	string.
+
+Sun Jan 19 06:17:39 1997  Assar Westerlund  <assar@pdc.kth.se>
+
+	* lib/krb5/get_cred.c (krb5_get_credentials): Check for creds in
+ 	cc before getting new ones.
+
+	* lib/krb5/krb5.h (krb5_free_keyblock): Fix prototype.
+
+	* lib/krb5/build_auth.c (krb5_build_authenticator): It seems the
+ 	CRC should be stored LSW first. (?)
+
+	* lib/krb5/auth_context.c: Implement `krb5_auth_con_getkey' and
+ 	`krb5_free_keyblock'
+
+	* lib/**/Makefile.am: Rename foo libfoo.a
+
+	* include/Makefile.in: Use test instead of [
+	-e does not work with /bin/sh on psoriasis
+
+	* configure.in: Search for awk
+	create lib/krb/error/compile_et
+	
+Tue Jan 14 03:46:26 1997  Assar Westerlund  <assar@pdc.kth.se>
+
+	* lib/krb5/Makefile.am: replaced mit-crc.c by crc.c
+
+Wed Dec 18 00:53:55 1996  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* kuser/kinit.c: Guess principal.
+
+	* lib/krb5/error/compile_et.awk: Don't include krb5.h. Fix some
+ 	warnings.
+
+	* lib/krb5/error/asn1_err.et: Add ASN.1 error messages.
+
+	* lib/krb5/mk_req.c: Get client from cache.
+
+	* lib/krb5/cache.c: Add better error checking some useful return
+ 	values.
+
+	* lib/krb5/krb5.h: Fix krb5_auth_context.
+
+	* lib/asn1/der.h: Make krb5_data compatible with krb5.h
+
+Tue Dec 17 01:32:36 1996  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/error: Add primitive error library.
+
+Mon Dec 16 16:30:20 1996  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lib/krb5/cache.c: Get correct address type from cache.
+
+	* lib/krb5/krb5.h: Change int16 to int to be compatible with asn1.
+
diff --git a/crypto/heimdal/ChangeLog.1999 b/crypto/heimdal/ChangeLog.1999
new file mode 100644
index 000000000000..e022b9682465
--- /dev/null
+++ b/crypto/heimdal/ChangeLog.1999
@@ -0,0 +1,2194 @@
+1999-12-30  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (krb4): use `-ldes' in tests
+
+1999-12-26  Assar Westerlund  <assar@sics.se>
+
+	* lib/hdb/print.c (event2string): handle events without principal.
+  	From Luke Howard <lukeh@PADL.COM>
+
+1999-12-25  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2j
+
+Tue Dec 21 18:03:17 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/hdb/Makefile.am (asn1_files): add $(EXEEXT) for cygwin and
+ 	related systems
+
+	* lib/asn1/Makefile.am (asn1_files): add $(EXEEXT) for cygwin and
+ 	related systems
+
+	* include/Makefile.am (krb5-types.h): add $(EXEEXT) for cygwin and
+ 	related systems
+
+1999-12-20  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2i
+
+1999-12-20  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): bump version to 6:3:1
+
+	* lib/krb5/send_to_kdc.c (send_via_proxy): free data
+	* lib/krb5/send_to_kdc.c (send_via_proxy): new function use
+	getaddrinfo instead of gethostbyname{,2}
+	* lib/krb5/get_for_creds.c: use getaddrinfo instead of
+	getnodebyname{,2}
+
+1999-12-17  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2h
+
+1999-12-17  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2g
+
+1999-12-16  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: bump version to 6:2:1
+
+	* lib/krb5/principal.c (krb5_sname_to_principal): handle
+	ai_canonname not being set
+	* lib/krb5/expand_hostname.c (krb5_expand_hostname): handle
+	ai_canonname not being set
+
+	* appl/test/uu_server.c: print messages to stderr
+	* appl/test/tcp_server.c: print messages to stderr
+	* appl/test/nt_gss_server.c: print messages to stderr
+	* appl/test/gssapi_server.c: print messages to stderr
+
+	* appl/test/tcp_client.c (proto): remove shadowing `context'
+	* appl/test/common.c (client_doit): add forgotten ntohs
+
+1999-12-13  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (VERISON): bump to 0.2g-pre
+
+1999-12-12  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (krb5_425_conv_principal_ext): be more
+ 	robust and handle extra dot at the beginning of default_domain
+
+1999-12-12  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2f
+
+1999-12-12  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: bump version to 6:1:1
+	
+	* lib/krb5/changepw.c (get_kdc_address): use
+ 	`krb5_get_krb_changepw_hst'
+
+	* lib/krb5/krbhst.c (krb5_get_krb_changepw_hst): add
+
+	* lib/krb5/get_host_realm.c: add support for _kerberos.domain
+ 	(according to draft-ietf-cat-krb-dns-locate-01.txt)
+
+1999-12-06  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2e
+
+1999-12-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/changepw.c (krb5_change_password): use the correct
+ 	address
+
+	* lib/krb5/Makefile.am: bump version to 6:0:1
+
+	* lib/asn1/Makefile.am: bump version to 1:4:0
+
+1999-12-04  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: move AC_KRB_IPv6 to make sure it's performed
+ 	before AC_BROKEN
+	(el_init): use new feature of AC_FIND_FUNC_NO_LIBS
+
+	* appl/test/uu_client.c: use client_doit
+	* appl/test/test_locl.h (client_doit): add prototype
+	* appl/test/tcp_client.c: use client_doit
+	* appl/test/nt_gss_client.c: use client_doit
+	* appl/test/gssapi_client.c: use client_doit
+	* appl/test/common.c (client_doit): move identical code here and
+	start using getaddrinfo
+
+	* appl/kf/kf.c (doit): rewrite to use getaddrinfo
+	* kdc/hprop.c: re-write to use getaddrinfo
+	* lib/krb5/principal.c (krb5_sname_to_principal): use getaddrinfo
+	* lib/krb5/expand_hostname.c (krb5_expand_hostname): use
+	getaddrinfo
+	* lib/krb5/changepw.c: re-write to use getaddrinfo
+	* lib/krb5/addr_families.c (krb5_parse_address): use getaddrinfo
+
+1999-12-03  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (BROKEN): check for freeaddrinfo, getaddrinfo,
+	getnameinfo, gai_strerror
+	(socklen_t): check for
+
+1999-12-02  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/crypto.c: ARCFOUR_set_key -> RC4_set_key
+
+1999-11-23  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/crypto.c (ARCFOUR_string_to_key): change order of bytes
+ 	within unicode characters.  this should probably be done in some
+ 	arbitrarly complex way to do it properly and you would have to
+ 	know what character encoding was used for the password and salt
+ 	string.
+
+	* lib/krb5/addr_families.c (ipv4_uninteresting): ignore 0.0.0.0
+	(INADDR_ANY)
+	(ipv6_uninteresting): remove unused macro
+
+1999-11-22  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/krb5.h: rc4->arcfour
+
+	* lib/krb5/crypto.c: rc4->arcfour
+
+1999-11-17  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krb5_locl.h: add <rc4.h>
+	* lib/krb5/krb5.h (krb5_keytype): add KEYTYPE_RC4
+	* lib/krb5/crypto.c: some code for doing RC4/MD5/HMAC which might
+	not be totally different from some small company up in the
+	north-west corner of the US
+
+	* lib/krb5/get_addrs.c (find_all_addresses): change code to
+ 	actually increment buf_size
+
+1999-11-14  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krb5.h (krb5_context_data): add `scan_interfaces'
+	* lib/krb5/get_addrs.c (krb5_get_all_client_addrs): make interaces
+ 	scanning optional
+	* lib/krb5/context.c (init_context_from_config_file): set
+ 	`scan_interfaces'
+
+	* lib/krb5/Makefile.am (libkrb5_la_SOURCES): add add_et_list.c
+	* lib/krb5/add_et_list.c (krb5_add_et_list): new function
+
+1999-11-12  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_default_realm.c (krb5_get_default_realm,
+	krb5_get_default_realms): set realms if they were unset
+	* lib/krb5/context.c (init_context_from_config_file): don't
+	initialize default realms here.  it's done lazily instead.
+	
+	* lib/krb5/krb5.h (KRB5_TC_*): make constants unsigned
+	* lib/asn1/gen_glue.c (generate_2int, generate_units): make sure
+	bit constants are unsigned
+	* lib/asn1/gen.c (define_type): make length in sequences be
+	unsigned.
+
+	* configure.in: remove duplicate test for setsockopt test for
+	struct tm.tm_isdst
+
+	* lib/krb5/get_in_tkt.c (krb5_get_in_cred): generate
+	preauthentication information if we get back ERR_PREAUTH_REQUIRED
+	* lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): remove
+	preauthentication generation code.  it's now in krb5_get_in_cred
+	
+	* configure.in (AC_BROKEN_SNPRINTF): add strptime check for struct
+	tm.tm_gmtoff and timezone
+	
+1999-11-11  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/main.c: make this work with multi-db
+
+	* kdc/kdc_locl.h: make this work with multi-db
+
+	* kdc/config.c: make this work with multi-db
+
+1999-11-09  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/misc.c: update for multi-database code
+
+	* kdc/main.c: update for multi-database code
+
+	* kdc/kdc_locl.h: update
+
+	* kdc/config.c: allow us to have more than one database
+
+1999-11-04  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2d
+
+	* lib/krb5/Makefile.am: bump version to 5:0:0 to be safe
+ 	(krb5_context_data has changed and some code do (might) access
+ 	fields directly)
+
+	* lib/krb5/krb5.h (krb5_context_data): add `etypes_des'
+
+	* lib/krb5/get_cred.c (init_tgs_req): use
+ 	krb5_keytype_to_enctypes_default
+
+	* lib/krb5/crypto.c (krb5_keytype_to_enctypes_default): new
+ 	function
+
+	* lib/krb5/context.c (set_etypes): new function
+	(init_context_from_config_file): set both `etypes' and `etypes_des'
+
+1999-11-02  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (VERSION): bump to 0.2d-pre
+
+1999-10-29  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (krb5_parse_name): check memory allocations
+
+1999-10-28  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2c
+
+	* lib/krb5/dump_config.c (print_tree): check for empty tree
+
+	* lib/krb5/string-to-key-test.c (tests): update the test cases
+ 	with empty principals so that they actually use an empty realm and
+ 	not the default.  use the correct etype for 3DES
+
+	* lib/krb5/Makefile.am: bump version to 4:1:0
+
+	* kdc/config.c (configure): more careful with the port string
+
+1999-10-26  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2b
+
+1999-10-20  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: bump version to 4:0:0
+ 	(krb524_convert_creds_kdc and potentially some other functions
+ 	have changed prototypes)
+
+	* lib/hdb/Makefile.am: bump version to 4:0:1
+
+	* lib/asn1/Makefile.am: bump version to 1:3:0
+
+	* configure.in (LIB_roken): add dbopen.  getcap in roken
+ 	references dbopen and with shared libraries we need to add this
+ 	dependency.
+
+	* lib/krb5/verify_krb5_conf.c (main): support speicifying the
+ 	configuration file to test on the command line
+
+	* lib/krb5/config_file.c (parse_binding): handle line with no
+ 	whitespace before =
+	(krb5_config_parse_file_debug): set lineno earlier so that we don't
+	use it unitialized
+
+	* configure.in (AM_INIT_AUTOMAKE): bump to 0.2b-pre opt*: need
+ 	more include files for these tests
+
+	* lib/krb5/set_default_realm.c (krb5_set_default_realm): use
+ 	krb5_config_get_strings, which means that your configuration file
+ 	should look like:
+	
+	[libdefaults]
+	  default_realm = realm1 realm2 realm3
+
+	* lib/krb5/set_default_realm.c (config_binding_to_list): fix
+ 	copy-o.  From Michal Vocu <michal@karlin.mff.cuni.cz>
+
+	* kdc/config.c (configure): add a missing strdup.  From Michal
+ 	Vocu <michal@karlin.mff.cuni.cz>
+
+1999-10-17  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2a
+
+	* configure.in: only test for db.h with using berkeley_db. remember
+ 	to link with LIB_tgetent when checking for el_init. add xnlock
+
+	* appl/Makefile.am: add xnlock
+
+	* kdc/kerberos5.c (find_etype): support null keys
+
+	* kdc/kerberos4.c (get_des_key): support null keys
+
+	* lib/krb5/crypto.c (krb5_get_wrapped_length): more correct
+ 	calculation
+
+1999-10-16  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kuser/kinit.c (main): pass ccache to krb524_convert_creds_kdc
+
+1999-10-12  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/crypto.c (krb5_enctype_to_keytype): remove warning
+
+1999-10-10  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mk_req.c (krb5_mk_req): use krb5_free_host_realm
+
+	* lib/krb5/krb5.h (krb5_ccache_data): make `ops' const
+
+	* lib/krb5/crypto.c (krb5_string_to_salttype): new function
+
+	* **/*.[ch]: const-ize
+
+1999-10-06  Assar Westerlund  <assar@sics.se>
+	
+	* lib/krb5/creds.c (krb5_compare_creds): const-ify
+	
+	* lib/krb5/cache.c: clean-up and comment-up
+
+	* lib/krb5/copy_host_realm.c (krb5_copy_host_realm): copy all the
+ 	strings
+
+	* lib/krb5/verify_user.c (krb5_verify_user_lrealm): free the
+ 	correct realm part
+
+	* kdc/connect.c (handle_tcp): things work much better when ret is
+ 	initialized
+
+1999-10-03  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/convert_creds.c (krb524_convert_creds_kdc): look at the
+ 	type of the session key
+
+	* lib/krb5/crypto.c (krb5_enctypes_compatible_keys): spell
+ 	correctly
+
+	* lib/krb5/creds.c (krb5_compare_creds): fix spelling of
+ 	krb5_enctypes_compatible_keys
+
+	* lib/krb5/convert_creds.c (krb524_convert_creds_kdc): get new
+ 	credentials from the KDC if the existing one doesn't have a DES
+ 	session key.
+
+	* lib/45/get_ad_tkt.c (get_ad_tkt): update to new
+ 	krb524_convert_creds_kdc
+
+1999-10-03  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/keytab_keyfile.c: make krb5_akf_ops const
+
+	* lib/krb5/keytab_memory.c: make krb5_mkt_ops const
+
+	* lib/krb5/keytab_file.c: make krb5_fkt_ops const
+
+1999-10-01  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/config_file.c: rewritten to allow error messages
+
+	* lib/krb5/Makefile.am (bin_PROGRAMS): add verify_krb5_conf
+	(libkrb5_la_SOURCES): add config_file_netinfo.c
+
+	* lib/krb5/verify_krb5_conf.c: new program for verifying that
+	krb5.conf is corret
+
+	* lib/krb5/config_file_netinfo.c: moved netinfo code here from
+ 	config_file.c
+
+1999-09-28  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hpropd.c (dump_krb4): kludge default_realm
+
+	* lib/asn1/check-der.c: add test cases for Generalized time and
+ 	make sure we return the correct value
+
+	* lib/asn1/der_put.c: simplify by using der_put_length_and_tag
+
+	* lib/krb5/verify_user.c (krb5_verify_user_lrealm): ariant of
+ 	krb5_verify_user that tries in all the local realms
+
+	* lib/krb5/set_default_realm.c: add support for having several
+ 	default realms
+
+	* lib/krb5/kuserok.c (krb5_kuserok): use `krb5_get_default_realms'
+
+	* lib/krb5/get_default_realm.c (krb5_get_default_realms): add
+
+	* lib/krb5/krb5.h (krb5_context_data): change `default_realm' to
+ 	`default_realms'
+
+	* lib/krb5/context.c: change from `default_realm' to
+ 	`default_realms'
+
+	* lib/krb5/aname_to_localname.c (krb5_aname_to_localname): use
+ 	krb5_get_default_realms
+
+	* lib/krb5/Makefile.am (libkrb5_la_SOURCES): add copy_host_realm.c
+
+	* lib/krb5/copy_host_realm.c: new file
+
+1999-09-27  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/asn1/der_put.c (encode_generalized_time): encode length
+
+	* lib/krb5/recvauth.c: new function `krb5_recvauth_match_version'
+	that allows more intelligent matching of the application version
+
+1999-09-26  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/asn1_print.c: add err.h
+
+	* kdc/config.c (configure): use parse_bytes
+
+	* appl/test/nt_gss_common.c: use the correct header file
+
+1999-09-24  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kuser/klist.c: add a `--cache' flag
+
+	* kuser/kinit.c (main): only get default value for `get_v4_tgt' if
+	it's explicitly set in krb5.conf
+
+1999-09-23  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/asn1_print.c (tag_names); add another univeral tag
+
+	* lib/asn1/der.h: update universal tags
+
+1999-09-22  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/asn1_print.c (loop): print length of octet string
+
+1999-09-21  Johan Danielsson  <joda@pdc.kth.se>
+
+	* admin/ktutil.c (kt_get): add `--help'
+
+1999-09-21  Assar Westerlund  <assar@sics.se>
+
+	* kuser/Makefile.am: add kdecode_ticket
+
+	* kuser/kdecode_ticket.c: new debug program
+
+	* appl/test/nt_gss_server.c: new program to test against `Sample *
+ 	SSPI Code' in Windows 2000 RC1 SDK.
+
+	* appl/test/Makefile.am: add nt_gss_client and nt_gss_server
+
+	* lib/asn1/der_get.c (decode_general_string): remember to advance
+ 	ret over the length-len
+
+	* lib/asn1/Makefile.am: add asn1_print
+
+	* lib/asn1/asn1_print.c: new program for printing DER-structures
+
+	* lib/asn1/der_put.c: make functions more consistent
+
+	* lib/asn1/der_get.c: make functions more consistent
+
+1999-09-20  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/kerberos5.c: be more informative in pa-data error messages
+
+1999-09-16  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: test for strlcpy, strlcat
+
+1999-09-14  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): return
+ 	KRB5_LIBOS_PWDINTR when interrupted
+
+	* lib/krb5/get_in_tkt_pw.c (krb5_password_key_proc): check return
+ 	value from des_read_pw_string
+
+	* kuser/kinit.c (main): don't print any error if reading the
+ 	password was interrupted
+
+	* kpasswd/kpasswd.c (main): don't print any error if reading the
+ 	password was interrupted
+
+	* kdc/string2key.c (main): check the return value from fgets
+
+	* kdc/kstash.c (main): check return value from des_read_pw_string
+
+	* admin/ktutil.c (kt_add): check the return-value from fgets and
+ 	overwrite the password for paranoid reasons
+
+	* lib/krb5/keytab_keyfile.c (get_cell_and_realm): only remove the
+ 	newline if it's there
+
+1999-09-13  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hpropd.c (main): remove bogus error with `--print'.  remove
+ 	sysloging of number of principals transferred
+
+	* kdc/hprop.c (ka_convert): set flags correctly for krbtgt/CELL
+ 	principals
+	(main): get rid of bogus opening of hdb database when propagating
+	ka-server database
+
+1999-09-12  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krb5_locl.h (O_BINARY): add fallback definition
+
+	* lib/krb5/krb5.h (krb5_context_data): add keytab types
+
+	* configure.in: revert back awk test, not worked around in
+ 	roken.awk
+
+	* lib/krb5/keytab_krb4.c: remove O_BINARY
+
+	* lib/krb5/keytab_keyfile.c: some support for AFS KeyFile's.  From
+	Love <lha@e.kth.se>
+
+	* lib/krb5/keytab_file.c: remove O_BINARY
+
+	* lib/krb5/keytab.c: move the list of keytab types to the context
+
+	* lib/krb5/fcache.c: remove O_BINARY
+
+	* lib/krb5/context.c (init_context_from_config_file): register all
+ 	standard cache and keytab types
+	(krb5_free_context): free `kt_types'
+
+	* lib/krb5/cache.c (krb5_cc_resolve): move the registration of the
+ 	standard types of credential caches to context
+
+	* lib/krb5/Makefile.am (libkrb5_la_SOURCES): add keytab_keyfile.c
+
+1999-09-10  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/keytab.c: add comments and clean-up
+
+	* admin/ktutil.c: add `ktutil copy'
+
+	* lib/krb5/keytab_krb4.c: new file
+
+	* lib/krb5/krb5.h (krb5_kt_cursor): add a `data' field
+
+	* lib/krb5/Makefile.am: add keytab_krb4.c
+
+	* lib/krb5/keytab.c: add krb4 and correct some if's
+
+	* admin/srvconvert.c (srvconv): move common code
+
+	* lib/krb5/krb5.h (krb5_fkt_ops, krb5_mkt_ops): new variables
+
+	* lib/krb5/keytab.c: move out file and memory functions
+
+	* lib/krb5/Makefile.am (libkrb5_la_SOURCES): add keytab_file.c,
+ 	keytab_memory.c
+
+	* lib/krb5/keytab_memory.c: new file
+
+	* lib/krb5/keytab_file.c: new file
+
+	* kpasswd/kpasswdd.c: move out password quality functions
+
+1999-09-07  Assar Westerlund  <assar@sics.se>
+
+	* lib/hdb/Makefile.am (libhdb_la_SOURCES): add keytab.c.  From
+ 	Love <lha@e.kth.se>
+
+	* lib/krb5/convert_creds.c (krb524_convert_creds_kdc): check
+ 	return value from `krb5_sendto_kdc'
+
+1999-09-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/send_to_kdc.c (send_and_recv): rename to recv_loop and
+ 	remove the sending of data.  add a parameter `limit'.  let callers
+ 	send the date themselves (and preferably with net_write on tcp
+ 	sockets)
+	(send_and_recv_tcp): read first the length field and then only that
+	many bytes
+
+1999-09-05  Assar Westerlund  <assar@sics.se>
+
+	* kdc/connect.c (handle_tcp): try to print warning `TCP data of
+ 	strange type' less often
+
+	* lib/krb5/send_to_kdc.c (send_and_recv): handle EINTR properly.
+  	return on EOF.  always free data.  check return value from
+ 	realloc.
+	(send_and_recv_tcp, send_and_recv_http): check advertised length
+	against actual length
+
+1999-09-01  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: check for sgi capabilities
+
+1999-08-27  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/get_addrs.c: krb5_get_all_server_addrs shouldn't return
+	extra addresses
+
+	* kpasswd/kpasswdd.c: use HDB keytabs; change some error messages;
+	add --realm flag
+
+	* lib/krb5/address.c (krb5_append_addresses): remove duplicates
+
+1999-08-26  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/hdb/keytab.c: HDB keytab backend
+
+1999-08-25  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/keytab.c
+	(krb5_kt_{start_seq_get,next_entry,end_seq_get}): check for NULL
+	pointer
+
+1999-08-24  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kpasswd/kpasswdd.c: add `--keytab' flag
+
+1999-08-23  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/addr_families.c (IN6_ADDR_V6_TO_V4): use `s6_addr'
+ 	instead of the non-standard `s6_addr32'.  From Yoshinobu Inoue
+ 	<shin@kame.net> by way of the KAME repository
+
+1999-08-18  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (--enable-new-des3-code): remove check for `struct
+ 	addrinfo'
+
+	* lib/krb5/crypto.c (etypes): remove NEW_DES3_CODE, enable
+ 	des3-cbc-sha1 and keep old-des3-cbc-sha1 for backwards
+ 	compatability
+
+	* lib/krb5/krb5.h (krb5_enctype): des3-cbc-sha1 (with key
+ 	derivation) just got assigned etype 16 by <bcn@isi.edu>.  keep the
+ 	old etype at 7.
+
+1999-08-16  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/sendauth.c (krb5_sendauth): only look at errno if
+ 	krb5_net_read actually returns -1
+
+	* lib/krb5/recvauth.c (krb5_recvauth): only look at errno if
+ 	krb5_net_read actually returns -1
+
+	* appl/kf/kf.c (proto): don't trust errno if krb5_net_read hasn't
+ 	returned -1
+
+	* appl/test/tcp_server.c (proto): only trust errno if
+ 	krb5_net_read actually returns -1
+
+	* appl/kf/kfd.c (proto): be more careful with the return value
+ 	from krb5_net_read
+
+1999-08-13  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_addrs.c (get_addrs_int): try the different ways
+ 	sequentially instead of just one.  this helps if your heimdal was
+ 	built with v6-support but your kernel doesn't have it, for
+ 	example.
+
+1999-08-12  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hpropd.c: add inetd flag.  default means try to figure out
+ 	if stdin is a socket or not.
+
+	* Makefile.am (ACLOCAL): just use `cf', this variable is only used
+ 	when the current directory is $(top_srcdir) anyways and having
+ 	$(top_srcdir) there breaks if it's a relative path
+
+1999-08-09  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: check for setproctitle
+
+1999-08-05  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (krb5_sname_to_principal): remember to call
+ 	freehostent
+
+	* appl/test/tcp_client.c: call freehostent
+
+	* appl/kf/kf.c (doit): call freehostent
+
+	* appl/kf/kf.c: make v6 friendly and simplify
+
+	* appl/kf/kfd.c: make v6 friendly and simplify
+
+	* appl/test/tcp_server.c: simplify by using krb5_err instead of
+ 	errx
+	
+	* appl/test/tcp_client.c: simplify by using krb5_err instead of
+ 	errx
+
+	* appl/test/tcp_server.c: make v6 friendly and simplify
+
+	* appl/test/tcp_client.c: make v6 friendly and simplify
+
+1999-08-04  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1m
+
+1999-08-04  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kinit.c (main): some more KRB4-conditionalizing
+
+	* lib/krb5/get_in_tkt.c: type correctness
+
+	* lib/krb5/get_for_creds.c (krb5_fwd_tgs_creds): set forwarded in
+ 	flags.  From Miroslav Ruda <ruda@ics.muni.cz>
+
+	* kuser/kinit.c (main): add config file support for forwardable
+ 	and krb4 support.  From Miroslav Ruda <ruda@ics.muni.cz>
+
+	* kdc/kerberos5.c (as_rep): add an empty X500-compress string as
+ 	transited.
+	(fix_transited_encoding): check length.
+	From Miroslav Ruda <ruda@ics.muni.cz>
+
+	* kdc/hpropd.c (dump_krb4): check the realm so that we don't dump
+ 	principals in some other realm. From Miroslav Ruda
+ 	<ruda@ics.muni.cz>
+	(main): rename sa_len -> sin_len, sa_lan is a define on some
+	platforms.
+
+	* appl/kf/kfd.c: add regpag support. From Miroslav Ruda
+ 	<ruda@ics.muni.cz>
+
+	* appl/kf/kf.c: add `-G' and forwardable option in krb5.conf.
+  	From Miroslav Ruda <ruda@ics.muni.cz>
+
+	* lib/krb5/config_file.c (parse_list): don't run past end of line
+
+	* appl/test/gss_common.h: new prototypes
+
+	* appl/test/gssapi_client.c: use gss_err instead of abort
+
+	* appl/test/gss_common.c (gss_verr, gss_err): add
+
+1999-08-03  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am (n_fold_test_LDADD): need to set this
+ 	otherwise it doesn't build with shared libraries
+
+	* kdc/hpropd.c: v6-ify
+
+	* kdc/hprop.c: v6-ify
+
+1999-08-01  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mk_req.c (krb5_mk_req): use krb5_expand_hostname
+
+1999-07-31  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_host_realm.c (krb5_get_host_realm_int): new
+ 	function that takes a FQDN
+
+	* lib/krb5/Makefile.am (libkrb5_la_SOURCES): add exapnd_hostname.c
+
+	* lib/krb5/expand_hostname.c: new file
+
+1999-07-28  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1l
+
+1999-07-28  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/Makefile.am: bump version to 1:2:0
+
+	* lib/krb5/Makefile.am: bump version to 3:1:0
+
+	* configure.in: more inet_pton to roken
+
+	* lib/krb5/principal.c (krb5_sname_to_principal): use
+ 	getipnodebyname
+
+1999-07-26  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1k
+
+1999-07-26  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/Makefile.am: bump version number (changed function
+	signatures)
+
+	* lib/hdb/Makefile.am: bump version number (changes to some
+	function signatures)
+
+1999-07-26  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: bump version to 3:0:2
+
+	* lib/hdb/Makefile.am: bump version to 2:1:0
+
+	* lib/asn1/Makefile.am: bump version to 1:1:0
+
+1999-07-26  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1j
+
+1999-07-26  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: rokenize inet_ntop
+
+	* lib/krb5/store_fd.c: lots of changes from size_t to ssize_t
+	
+	* lib/krb5/store_mem.c: lots of changes from size_t to ssize_t
+	
+	* lib/krb5/store_emem.c: lots of changes from size_t to ssize_t
+	
+	* lib/krb5/store.c: lots of changes from size_t to ssize_t
+	(krb5_ret_stringz): check return value from realloc
+
+	* lib/krb5/mk_safe.c: some type correctness
+	
+	* lib/krb5/mk_priv.c: some type correctness
+	
+	* lib/krb5/krb5.h (krb5_storage): change return values of
+	functions from size_t to ssize_t
+	
+1999-07-24  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1i
+
+	* configure.in (AC_PROG_AWK): disable. mawk seems to mishandle \#
+ 	in lib/roken/roken.awk
+
+	* lib/krb5/get_addrs.c (find_all_addresses): try to use SA_LEN to
+ 	step over addresses if there's no `sa_lan' field
+
+	* lib/krb5/sock_principal.c (krb5_sock_to_principal): simplify by
+ 	using `struct sockaddr_storage'
+
+	* lib/krb5/send_to_kdc.c (krb5_sendto_kdc): simplify by using
+ 	`struct sockaddr_storage'
+
+	* lib/krb5/changepw.c (krb5_change_password): simplify by using
+ 	`struct sockaddr_storage'
+
+	* lib/krb5/auth_context.c (krb5_auth_con_setaddrs_from_fd):
+ 	simplify by using `struct sockaddr_storage'
+
+	* kpasswd/kpasswdd.c (*): simplify by using `struct
+ 	sockaddr_storage'
+
+	* kdc/connect.c (*): simplify by using `struct sockaddr_storage'
+
+	* configure.in (sa_family_t): just test for existence
+	(sockaddr_storage): also specify include file
+
+	* configure.in (AM_INIT_AUTOMAKE): bump version to 0.1i
+	(sa_family_t): test for
+	(struct	sockaddr_storage): test for
+
+	* kdc/hprop.c (propagate_database): typo, NULL should be
+ 	auth_context
+
+	* lib/krb5/get_addrs.c: conditionalize on HAVE_IPV6 instead of
+ 	AF_INET6
+
+	* appl/kf/kf.c (main): use warnx
+
+	* appl/kf/kf.c (proto): remove shadowing context
+
+	* lib/krb5/get_addrs.c (find_all_addresses): try to handle the
+ 	case of getting back an `sockaddr_in6' address when sizeof(struct
+ 	sockaddr_in6) > sizeof(struct sockaddr) and we have no sa_len to
+ 	tell us how large the address is.  This obviously doesn't work
+ 	with unknown protocol types.
+
+1999-07-24  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1h
+
+1999-07-23  Assar Westerlund  <assar@sics.se>
+
+	* appl/kf/kfd.c: clean-up and more paranoia
+
+	* etc/services.append: add kf
+
+	* appl/kf/kf.c: rename tk_file to ccache for consistency.  clean-up
+
+1999-07-22  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/n-fold-test.c (main): print the correct data
+
+	* appl/Makefile.am (SUBDIRS): add kf
+
+	* appl/kf: new program.  From Miroslav Ruda <ruda@ics.muni.cz>
+
+	* kdc/hprop.c: declare some variables unconditionally to simplify
+ 	things
+
+	* kpasswd/kpasswdd.c: initialize kadm5 connection for every change
+ 	(otherwise the modifier in the database doesn't get set)
+
+	* kdc/hpropd.c: clean-up and re-organize
+
+	* kdc/hprop.c: clean-up and re-organize
+
+ 	* configure.in (SunOS): define to xy for SunOS x.y
+
+1999-07-19  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (AC_BROKEN): test for copyhostent, freehostent,
+ 	getipnodebyaddr, getipnodebyname
+
+1999-07-15  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/check-der.c: more test cases for integers
+
+	* lib/asn1/der_length.c (length_int): handle the case of the
+ 	largest negative integer by not calling abs
+
+1999-07-14  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/check-der.c (generic_test): check malloc return value
+ 	properly
+
+	* lib/krb5/Makefile.am: add string_to_key_test
+
+	* lib/krb5/prog_setup.c (krb5_program_setup): always initialize
+ 	the context
+
+	* lib/krb5/n-fold-test.c (main): return a relevant return value
+
+	* lib/krb5/krbhst.c: do SRV lookups for admin server as well.
+  	some clean-up.
+
+1999-07-12  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: handle not building X programs
+
+1999-07-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/addr_families.c (ipv6_parse_addr): remove duplicate
+ 	variable
+	(ipv6_sockaddr2port): fix typo
+
+	* etc/services.append: beginning of a file with services
+
+	* lib/krb5/cache.c (krb5_cc_resolve): fall-back to files if
+ 	there's no prefix.  also clean-up a little bit.
+
+	* kdc/hprop.c (--kaspecials): new flag for handling special KA
+ 	server entries.  From "Brandon S. Allbery KF8NH"
+ 	<allbery@kf8nh.apk.net>
+
+1999-07-05  Assar Westerlund  <assar@sics.se>
+
+	* kdc/connect.c (handle_tcp): make sure we have data before
+ 	starting to look for HTTP
+
+	* kdc/connect.c (handle_tcp): always do getpeername, we can't
+ 	trust recvfrom to return anything sensible
+
+1999-07-04  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_in_tkt.c (add_padat): encrypt pre-auth data with
+ 	all enctypes
+
+	* kpasswd/kpasswdd.c (change): fetch the salt-type from the entry
+
+	* admin/srvconvert.c (srvconv): better error messages
+
+1999-07-03  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (unparse_name): error check malloc properly
+
+	* lib/krb5/get_in_tkt.c (krb5_init_etype): error check malloc
+ 	properly
+
+	* lib/krb5/crypto.c (*): do some malloc return-value checks
+ 	properly
+
+	* lib/hdb/hdb.c (hdb_process_master_key): simplify by using
+ 	krb5_data_alloc
+
+	* lib/hdb/hdb.c (hdb_process_master_key): check return value from
+ 	malloc
+
+	* lib/asn1/gen_decode.c (decode_type): fix generation of decoding
+ 	information for TSequenceOf.
+
+	* kdc/kerberos5.c (get_pa_etype_info): check return value from
+ 	malloc
+
+1999-07-02  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/der_copy.c (copy_octet_string): don't fail if length ==
+ 	0 and malloc returns NULL
+
+1999-06-29  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/addr_families.c (ipv6_parse_addr): implement
+
+1999-06-24  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_cred.c (krb5_rd_cred): compare the sender's address
+ 	as an addrport one
+
+	* lib/krb5/krb5.h (KRB5_ADDRESS_ADDRPORT, KRB5_ADDRESS_IPPORT):
+ 	add
+	(krb5_auth_context): add local and remote port
+
+	* lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): get the
+ 	local and remote address and add them to the krb-cred packet
+
+	* lib/krb5/auth_context.c: save the local and remove ports in the
+ 	auth_context
+
+	* lib/krb5/address.c (krb5_make_addrport): create an address of
+ 	type KRB5_ADDRESS_ADDRPORT from (addr, port)
+
+	* lib/krb5/addr_families.c (krb5_sockaddr2port): new function for
+ 	grabbing the port number out of the sockaddr
+
+1999-06-23  Assar Westerlund  <assar@sics.se>
+
+	* admin/srvcreate.c (srvcreate): always take the DES-CBC-MD5 key.
+  	increase possible verbosity.
+
+	* lib/krb5/config_file.c (parse_list): handle blank lines at
+ 	another place
+	
+	* kdc/connect.c (add_port_string): don't return a value
+
+ 	* lib/kadm5/init_c.c (get_cred_cache): you cannot reuse the cred
+ 	cache if the principals are different.  close and NULL the old one
+ 	so that we create a new one.
+
+	* configure.in: move around cgywin et al
+	(LIB_kdb): set at the end of krb4-block
+	(krb4): test for krb_enable_debug and krb_disable_debug
+
+1999-06-16  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kdestroy.c (main): try to destroy v4 ticket even if the
+ 	destruction of the v5 one fails
+
+	* lib/krb5/crypto.c (DES3_postproc): new version that does the
+ 	right thing
+	(*): don't put and recover length in 3DES encoding
+	other small fixes
+
+1999-06-15  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_default_principal.c: rewrite to use
+ 	get_default_username
+
+	* lib/krb5/Makefile.am: add n-fold-test
+
+	* kdc/connect.c: add fallbacks for all lookups by service name
+	(handle_tcp): break-up and clean-up
+
+1999-06-09  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/addr_families.c (ipv6_uninteresting): don't consider
+ 	the loopback address as uninteresting
+
+	* lib/krb5/get_addrs.c: new magic flag to get loopback address if
+ 	there are no other addresses.
+	(krb5_get_all_client_addrs): use that flag
+
+1999-06-04  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/crypto.c (HMAC_SHA1_DES3_checksum): don't include the
+ 	length
+	(checksum_sha1, checksum_hmac_sha1_des3): blocksize should be 64
+	(encrypt_internal_derived): don't include the length and don't
+	decrease by the checksum size twice
+	(_get_derived_key): the constant should be 5 bytes
+
+1999-06-02  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: use KRB_CHECK_X
+	
+	* configure.in: check for netinet/ip.h
+	
+1999-05-31  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd/kpasswdd.c (setup_passwd_quality_check): conditionalize
+ 	on RTLD_NOW
+
+1999-05-23  Assar Westerlund  <assar@sics.se>
+
+	* appl/test/uu_server.c: removed unused stuff
+
+	* appl/test/uu_client.c: removed unused stuff
+
+1999-05-21  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kgetcred.c (main): correct error message
+
+	* lib/krb5/crypto.c (verify_checksum): call (*ct->checksum)
+ 	directly, avoiding redundant lookups and memory leaks
+
+	* lib/krb5/auth_context.c (krb5_auth_con_setaddrs_from_fd): free
+ 	local and remote addresses
+
+	* lib/krb5/get_default_principal.c (get_logname): also try
+ 	$USERNAME
+	
+	* lib/asn1/Makefile.am (asn1_files): add $(EXEEXT)
+
+	* lib/krb5/principal.c (USE_RESOLVER): try to define only if we
+	have a libresolv (currently by checking for res_search)
+
+1999-05-18  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/connect.c (handle_tcp): remove %-escapes in request
+
+1999-05-14  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1g
+
+	* admin/ktutil.c (kt_remove): -t should be -e
+
+	* configure.in (CHECK_NETINET_IP_AND_TCP): use
+
+	* kdc/hpropd.c: support for dumping to krb4.  From Miroslav Ruda
+ 	<ruda@ics.muni.cz>
+
+	* admin/ktutil.c (kt_add): new option `--no-salt'.  From Miroslav
+ 	Ruda <ruda@ics.muni.cz>
+
+	* configure.in: add cygwin and DOS tests replace sendmsg, recvmsg,
+ 	and innetgr with roken versions
+
+	* kuser/kgetcred.c: new program
+
+Tue May 11 14:09:33 1999  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/mcache.c: fix paste-o
+	
+1999-05-10  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: don't use uname
+
+1999-05-10  Assar Westerlund  <assar@sics.se>
+
+	* acconfig.h (KRB_PUT_INT): if we don't have KRB4 use four
+	arguments :-)
+
+	* appl/test/uu_server.c (setsockopt): cast to get rid of a warning
+	
+	* appl/test/tcp_server.c (setsockopt): cast to get rid of a
+	warning
+
+	* appl/test/tcp_client.c (proto): call krb5_sendauth with ccache
+	== NULL
+
+	* appl/test/gssapi_server.c (setsockopt): cast to get rid of a
+	warning
+
+	* lib/krb5/sendauth.c (krb5_sendauth): handle ccache == NULL by
+	setting the default ccache.
+
+	* configure.in (getsockopt, setsockopt): test for
+	(AM_INIT_AUTOMAKE): bump version to 0.1g
+
+	* appl/Makefile.am (SUBDIRS): add kx
+	
+	* lib/hdb/convert_db.c (main): handle the case of no master key
+	
+1999-05-09  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1f
+
+	* kuser/kinit.c: add --noaddresses
+	
+	* lib/krb5/get_in_tkt.c (init_as_req): interpret `addrs' being an
+	empty sit of list as to not ask for any addresses.
+	
+1999-05-08  Assar Westerlund  <assar@sics.se>
+
+	* acconfig.h (_GNU_SOURCE): define this to enable (used)
+ 	extensions on glibc-based systems such as linux
+
+1999-05-03  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_cred.c (get_cred_from_kdc_flags): allocate and free
+	`*out_creds' properly
+
+	* lib/krb5/creds.c (krb5_compare_creds): just verify that the
+	keytypes/enctypes are compatible, not that they are the same
+
+	* kuser/kdestroy.c (cache): const-correctness
+
+1999-05-03  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/hdb/hdb.c (hdb_set_master_key): initialise master key
+	version
+
+	* lib/hdb/convert_db.c: add support for upgrading database
+	versions
+
+	* kdc/misc.c: add flags to fetch
+
+	* kdc/kstash.c: unlink keyfile on failure, chmod to 400
+
+	* kdc/hpropd.c: add --print option
+
+	* kdc/hprop.c: pass flags to hdb_foreach
+
+	* lib/hdb/convert_db.c: add some flags
+
+	* lib/hdb/Makefile.am: remove extra LDFLAGS, update version to 2;
+	build prototype headers
+	
+	* lib/hdb/hdb_locl.h: update prototypes
+
+	* lib/hdb/print.c: move printable version of entry from kadmin
+
+	* lib/hdb/hdb.c: change hdb_{seal,unseal}_* to check if the key is
+	sealed or not; add flags to hdb_foreach
+
+	* lib/hdb/ndbm.c: add flags to NDBM_seq, NDBM_firstkey, and
+	NDBM_nextkey
+
+	* lib/hdb/db.c: add flags to DB_seq, DB_firstkey, and DB_nextkey
+
+	* lib/hdb/common.c: add flags to _hdb_{fetch,store}
+
+	* lib/hdb/hdb.h: add master_key_version to struct hdb, update
+	prototypes
+
+	* lib/hdb/hdb.asn1: make mkvno optional, update version to 2
+
+	* configure.in: --enable-netinfo
+
+	* lib/krb5/config_file.c: HAVE_NETINFO_NI_H -> HAVE_NETINFO
+
+	* config.sub: fix for crays
+
+	* config.guess: new version from automake 1.4
+	
+	* config.sub: new version from automake 1.4
+
+Wed Apr 28 00:21:17 1999  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.1e
+
+	* lib/krb5/mcache.c (mcc_get_next): get the current cursor
+ 	correctly
+
+	* acconfig.h: correct definition of KRB_PUT_INT for old krb4 code.
+  	From Ake Sandgren <ake@cs.umu.se>
+
+1999-04-27  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/kerberos5.c: fix arguments to decrypt_ticket
+	
+1999-04-25  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_internal): try to handle old
+	DCE secd's that are not able to handle MD5 checksums by defaulting
+	to MD4 if the keytype was DES-CBC-CRC
+	
+	* lib/krb5/mk_req.c (krb5_mk_req): use auth_context->keytype
+	
+	* lib/krb5/krb5.h (krb5_auth_context_data): add `keytype' and
+	`cksumtype'
+
+	* lib/krb5/get_cred.c (make_pa_tgs_req): remove old kludge for
+	secd
+	(init_tgs_req): add all supported enctypes for the keytype in
+	`in_creds->session.keytype' if it's set
+
+	* lib/krb5/crypto.c (F_PSEUDO): new flag for non-protocol
+	encryption types
+	(do_checksum): new function
+	(verify_checksum): take the checksum to use from the checksum message
+	and not from the crypto struct
+	(etypes): add F_PSEUDO flags
+	(krb5_keytype_to_enctypes): new function
+
+	* lib/krb5/auth_context.c (krb5_auth_con_init): initalize keytype
+	and cksumtype
+	(krb5_auth_setcksumtype, krb5_auth_getcksumtype): implement
+	(krb5_auth_setkeytype, krb5_auth_getkeytype): implement
+	(krb5_auth_setenctype): comment out, it's rather bogus anyway
+
+Sun Apr 25 16:55:50 1999  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/krb5_locl.h: fix for stupid aix warnings
+
+	* lib/krb5/fcache.c (erase_file): don't malloc
+	
+Sat Apr 24 18:35:21 1999  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/config.c: pass context to krb5_config_file_free
+
+	* kuser/kinit.c: add `--fcache-version' to set cache version to
+	create
+
+	* kuser/klist.c: print cache version if verbose
+
+	* lib/krb5/transited.c (krb5_domain_x500_decode): don't abort
+
+	* lib/krb5/principal.c: abort -> krb5_abortx
+
+	* lib/krb5/mk_rep.c: abort -> krb5_abortx
+
+	* lib/krb5/config_file.c: abort -> krb5_abortx
+
+	* lib/krb5/context.c (init_context_from_config_file): init
+	fcache_version; add krb5_{get,set}_fcache_version
+
+	* lib/krb5/keytab.c: add support for reading (and writing?) old
+	version keytabs
+
+	* lib/krb5/cache.c: add krb5_cc_get_version
+
+	* lib/krb5/fcache.c: add support for reading and writing old
+	version cache files
+
+	* lib/krb5/store_mem.c (krb5_storage_from_mem): zero flags
+
+	* lib/krb5/store_emem.c (krb5_storage_emem): zero flags
+
+	* lib/krb5/store_fd.c (krb5_storage_from_fd): zero flags
+
+	* lib/krb5/store.c: add flags to change how various fields are
+	stored, used for old cache version support
+	
+	* lib/krb5/krb5.h: add support for reading and writing old version
+	cache files, and keytabs
+	
+Wed Apr 21 00:09:26 1999  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: fix test for readline.h remember to link with
+ 	$LIB_tgetent when trying linking with readline
+
+	* lib/krb5/init_creds_pw.c (get_init_creds_common): if start_time
+ 	is given, request a postdated ticket.
+
+	* lib/krb5/data.c (krb5_data_free): free data as long as it's not
+ 	NULL
+
+Tue Apr 20 20:18:14 1999  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd/Makefile.am (kpasswdd_LDADD): add LIB_dlopen
+
+	* lib/krb5/krb5.h (KRB5_VERIFY_AP_REQ_IGNORE_INVALID): add
+
+	* lib/krb5/rd_req.c (krb5_decrypt_ticket): add `flags` and
+ 	KRB5_VERIFY_AP_REQ_IGNORE_INVALID for ignoring that the ticket is
+ 	invalid
+
+Tue Apr 20 12:42:08 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* kpasswd/kpasswdd.c: don't try to load library by default; get
+ 	library and function name from krb5.conf
+
+	* kpasswd/sample_passwd_check.c: sample password checking
+ 	functions
+
+Mon Apr 19 22:22:19 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/store.c (krb5_storage_to_data, krb5_ret_data): use
+ 	krb5_data_alloc and be careful with checking allocation and sizes.
+
+	* kuser/klist.c (--tokens): conditionalize on KRB4
+
+	* kuser/kinit.c (renew_validate): set all flags
+	(main): fix cut-n-paste error when setting start-time
+
+	* kdc/kerberos5.c (check_tgs_flags): starttime of a validate
+ 	ticket should be > than current time
+	(*): send flags to krb5_verify_ap_req and krb5_decrypt_ticket
+
+	* kuser/kinit.c (renew_validate): use the client realm instead of
+ 	the local realm when renewing tickets.
+
+	* lib/krb5/get_for_creds.c (krb5_fwd_tgs_creds): compat function
+	(krb5_get_forwarded_creds): correct freeing of out_creds
+
+	* kuser/kinit.c (renew_validate): hopefully fix up freeing of
+ 	memory
+
+	* configure.in: do all the krb4 tests with "$krb4" != "no"
+
+	* lib/krb5/keyblock.c (krb5_free_keyblock_contents): don't zero
+ 	keyvalue if it's NULL.  noticed by Ake Sandgren <ake@cs.umu.se>
+
+	* lib/krb5/get_in_tkt.c (add_padata): loop over all enctypes
+ 	instead of just taking the first one.  fix all callers.  From
+ 	"Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
+
+	* kdc/kdc_locl.h (enable_kaserver): declaration
+	
+	* kdc/hprop.c (ka_convert): print the failing principal.  AFS 3.4a
+ 	creates krbtgt.REALMOFCELL as NOTGS+NOSEAL, work around.  From
+ 	"Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
+
+	* kdc/hpropd.c (open_socket): stupid cast to get rid of a warning
+
+	* kdc/connect.c (add_standard_ports, process_request): look at
+ 	enable_kaserver.  From "Brandon S. Allbery KF8NH"
+ 	<allbery@kf8nh.apk.net>
+
+	* kdc/config.c: new flag --kaserver and config file option
+ 	enable-kaserver.  From "Brandon S. Allbery KF8NH"
+ 	<allbery@kf8nh.apk.net>
+
+Mon Apr 19 12:32:04 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* configure.in: check for dlopen, and dlfcn.h
+
+	* kpasswd/kpasswdd.c: add support for dlopen:ing password quality
+ 	check library
+
+	* configure.in: add appl/su
+
+Sun Apr 18 15:46:53 1999  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/cache.c: add krb5_cc_get_type that returns type of a
+ 	cache
+
+Fri Apr 16 17:58:51 1999  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: LIB_kdb: -L should be before -lkdb
+	test for prototype of strsep
+	
+Thu Apr 15 11:34:38 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/Makefile.am: update version
+
+	* lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): use
+ 	ALLOC_SEQ
+
+	* lib/krb5/fcache.c: add some support for reading and writing old
+ 	cache formats;
+	(fcc_store_cred): use krb5_store_creds; (fcc_read_cred): use
+	krb5_ret_creds
+
+	* lib/krb5/store_mem.c (krb5_storage_from_mem): check malloc,
+ 	initialize host_byteorder
+
+	* lib/krb5/store_fd.c (krb5_storage_from_fd): initialize
+ 	host_byteorder
+
+	* lib/krb5/store_emem.c (krb5_storage_emem): initialize
+ 	host_byteorder
+
+	* lib/krb5/store.c (krb5_storage_set_host_byteorder): add;
+	(krb5_store_int32,krb5_ret_int32,krb5_store_int16,krb5_ret_int16):
+ 	check host_byteorder flag; (krb5_store_creds): add;
+ 	(krb5_ret_creds): add
+
+	* lib/krb5/krb5.h (krb5_storage): add `host_byteorder' flag for
+ 	storage of numbers
+
+	* lib/krb5/heim_err.et: add `host not found' error
+
+	* kdc/connect.c: don't use data after clearing decriptor
+
+	* lib/krb5/auth_context.c: abort -> krb5_abortx
+
+	* lib/krb5/warn.c: add __attribute__; add *abort functions
+
+	* configure.in: check for __attribute__
+
+	* kdc/connect.c: log bogus requests
+
+Tue Apr 13 18:38:05 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/kadm5/create_s.c (kadm5_s_create_principal): create v4 salts
+ 	for all DES keys
+
+1999-04-12  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_cred.c (init_tgs_req): re-structure a little bit
+
+	* lib/krb5/get_cred.c (init_tgs_req): some more error checking
+
+	* lib/krb5/generate_subkey.c (krb5_generate_subkey): check return
+	value from malloc
+
+Sun Apr 11 03:47:23 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/krb5.conf.5: update to reality
+
+	* lib/krb5/krb5_425_conv_principal.3: update to reality
+
+1999-04-11  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_host_realm.c: handle more than one realm for a host
+
+	* kpasswd/kpasswd.c (main): use krb5_program_setup and
+	print_version
+
+	* kdc/string2key.c (main): use krb5_program_setup and
+	print_version
+
+Sun Apr 11 02:35:58 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/principal.c (krb5_524_conv_principal): make it actually
+ 	work, and check built-in list of host-type first-components
+
+	* lib/krb5/krbhst.c: lookup SRV-records to find a kdc for a realm
+
+	* lib/krb5/context.c: add srv_* flags to context
+
+	* lib/krb5/principal.c: add default v4_name_convert entries
+
+	* lib/krb5/krb5.h: add srv_* flags to context
+
+Sat Apr 10 22:52:28 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* kadmin/kadmin.c: complain about un-recognised commands
+
+	* admin/ktutil.c: complain about un-recognised commands
+
+Sat Apr 10 15:41:49 1999  Assar Westerlund  <assar@sics.se>
+
+	* kadmin/load.c (doit): fix error message
+
+	* lib/krb5/crypto.c (encrypt_internal): free checksum if lengths
+ 	fail to match.
+	(krb5_get_wrapped_length): new function
+
+	* configure.in: security/pam_modules.h: check for
+
+	* lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): kludge
+ 	around `ret_as_reply' semantics by only freeing it when ret == 0
+
+Fri Apr  9 20:24:04 1999  Assar Westerlund  <assar@sics.se>
+
+	* kuser/klist.c (print_cred_verbose): handle the case of a bad
+ 	enctype
+
+	* configure.in: test for more header files
+	(LIB_roken): set
+
+Thu Apr  8 15:01:59 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* configure.in: fixes for building w/o krb4
+
+	* ltmain.sh: update to libtool 1.2d
+
+	* ltconfig: update to libtool 1.2d
+
+Wed Apr  7 23:37:26 1999  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hpropd.c: fix some error messages to be more understandable.
+
+	* kdc/hprop.c (ka_dump): remove unused variables
+
+	* appl/test/tcp_server.c: remove unused variables
+
+	* appl/test/gssapi_server.c: remove unused variables
+
+	* appl/test/gssapi_client.c: remove unused variables
+
+Wed Apr  7 14:05:15 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/context.c (krb5_get_err_text): long -> krb5_error_code
+
+	* kuser/klist.c: make it compile w/o krb4
+
+	* kuser/kdestroy.c: make it compile w/o krb4
+
+	* admin/ktutil.c: fix {srv,key}2{srv,key}tab confusion; add help
+ 	strings
+
+Mon Apr  5 16:13:46 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* configure.in: test for MIPS ABI; new test_package
+
+Thu Apr  1 11:00:40 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* include/Makefile.am: clean krb5-private.h
+
+	* Release 0.1d
+
+	* kpasswd/kpasswdd.c (doit): pass context to
+ 	krb5_get_all_client_addrs
+
+	* kdc/connect.c (init_sockets): pass context to
+ 	krb5_get_all_server_addrs
+
+	* lib/krb5/get_in_tkt.c (init_as_req): pass context to
+ 	krb5_get_all_client_addrs
+
+	* lib/krb5/get_cred.c (get_cred_kdc_la): pass context to
+ 	krb5_get_all_client_addrs
+
+	* lib/krb5/get_addrs.c (get_addrs_int): add extra host addresses
+
+	* lib/krb5/krb5.h: add support for adding an extra set of
+ 	addresses
+
+	* lib/krb5/context.c: add support for adding an extra set of
+ 	addresses
+
+	* lib/krb5/addr_families.c: add krb5_parse_address
+
+	* lib/krb5/address.c: krb5_append_addresses
+
+	* lib/krb5/config_file.c (parse_binding): don't zap everything
+ 	after first whitespace
+
+	* kuser/kinit.c (renew_validate): don't allocate out
+
+	* lib/krb5/get_for_creds.c (krb5_get_forwarded_creds): don't
+ 	allocate out_creds
+
+	* lib/krb5/get_cred.c (get_cred_kdc, get_cred_kdc_la): make
+ 	out_creds pointer;
+	(krb5_get_kdc_cred): allocate out_creds; (get_cred_from_kdc_flags):
+	free more memory
+
+	* lib/krb5/crypto.c (encrypt_internal): free checksum
+
+	* lib/krb5/convert_creds.c (krb524_convert_creds_kdc): free reply,
+ 	and ticket
+
+	* kuser/Makefile.am: remove kfoo
+
+	* lib/Makefile.am: add auth
+
+	* lib/kadm5/iprop.h: getarg.h
+
+	* lib/kadm5/replay_log.c: use getarg
+
+	* lib/kadm5/ipropd_slave.c: use getarg
+
+	* lib/kadm5/ipropd_master.c: use getarg
+
+	* lib/kadm5/dump_log.c: use getarg
+
+	* kpasswd/kpasswdd.c: use getarg
+
+	* Makefile.am.common: make a more working check-local target
+
+	* lib/asn1/main.c: use getargs
+
+Mon Mar 29 20:19:57 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* kuser/klist.c (print_cred_verbose): use krb5_print_address
+
+	* lib/kadm5/server.c: k_{put,get}_int -> _krb5_{put,get}_int
+
+	* lib/krb5/addr_families.c (krb5_print_address): handle unknown
+ 	address types; (ipv6_print_addr): print in 16-bit groups (as it
+ 	should)
+
+	* lib/krb5/crc.c: crc_{init_table,update} ->
+ 	_krb5_crc_{init_table,update}
+
+	* lib/krb5/crypto.c: k_{put,get}_int -> _krb5_{put,get}_int
+ 	crc_{init_table,update} -> _krb5_crc_{init_table,update}
+
+	* lib/krb5/send_to_kdc.c: k_{put,get}_int -> _krb5_{put,get}_int
+
+	* lib/krb5/store.c: k_{put,get}_int -> _krb5_{put,get}_int
+
+	* lib/krb5/krb5_locl.h: include krb5-private.h
+
+	* kdc/connect.c (addr_to_string): use krb5_print_address
+
+	* lib/krb5/addr_families.c (krb5_print_address): int -> size_t
+
+	* lib/krb5/addr_families.c: add support for printing ipv6
+ 	addresses, either with inet_ntop, or ugly for-loop
+
+	* kdc/524.c: check that the ticket came from a valid address; use
+ 	the address of the connection as the address to put in the v4
+ 	ticket (if this address is AF_INET)
+
+	* kdc/connect.c: pass addr to do_524
+
+	* kdc/kdc_locl.h: prototype for do_524
+
+Sat Mar 27 17:48:31 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* configure.in: check for OSF C2; bind/bitypes.h, getudbnam,
+ 	setlim; check for auth modules; siad.h, getpwnam_r;
+ 	lib/auth/Makefile, lib/auth/sia/Makefile
+
+	* lib/krb5/crypto.c: n_fold -> _krb5_n_fold
+
+	* lib/krb5/n-fold.c: n_fold -> _krb5_n_fold
+
+Thu Mar 25 04:35:21 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/set_keys.c (_kadm5_set_keys): free salt when zapping
+ 	it
+
+	* lib/kadm5/free.c (kadm5_free_principal_ent): free `key_data'
+
+	* lib/hdb/ndbm.c (NDBM_destroy): clear master key
+
+	* lib/hdb/db.c (DB_destroy): clear master key
+	(DB_open): check malloc
+
+	* kdc/connect.c (init_sockets): free addresses
+
+	* kadmin/kadmin.c (main): make code more consistent.  always free
+ 	configuration information.
+
+	* kadmin/init.c (create_random_entry): free the entry
+
+Wed Mar 24 04:02:03 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/init_creds_pw.c (krb5_get_init_creds_password):
+ 	re-organize the code to always free `kdc_reply'
+
+	* lib/krb5/get_in_tkt.c (krb5_get_in_cred): be more careful about
+ 	freeing memory
+
+	* lib/krb5/fcache.c (fcc_destroy): don't call fcc_close
+
+	* lib/krb5/crypto.c (krb5_crypto_destroy): free `crypto'
+
+	* lib/hdb/hdb_locl.h: try db_185.h first in case db.h is a DB 2.0
+ 	header
+
+	* configure.in (db_185.h): check for
+
+	* admin/srvcreate.c: new file. contributed by Daniel Kouril
+ 	<kouril@informatics.muni.cz>
+
+	* admin/ktutil.c: srvcreate: new command
+
+	* kuser/klist.c: add support for printing AFS tokens
+
+	* kuser/kdestroy.c: add support for destroying v4 tickets and AFS
+ 	tokens.  based on code by Love <lha@stacken.kth.se>
+
+	* kuser/Makefile.am (kdestroy_LDADD, klist_LDADD): more libraries
+
+	* configure.in: sys/ioccom.h: test for
+
+	* kuser/klist.c (main): don't print `no ticket file' with --test.
+  	From: Love <lha@e.kth.se>
+
+	* kpasswd/kpasswdd.c (doit): more braces to make gcc happy
+
+	* kdc/connect.c (init_socket): get rid of a stupid warning
+
+	* include/bits.c (my_strupr): cast away some stupid warnings
+
+Tue Mar 23 14:34:44 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/get_host_realm.c (krb5_get_host_realm): no infinite
+ 	loops, please
+
+Tue Mar 23 00:00:45 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/kadm5/Makefile.am (install_build_headers): recover from make
+ 	rewriting the names of the headers kludge to help solaris make
+
+	* lib/krb5/Makefile.am: kludge to help solaris make
+
+	* lib/hdb/Makefile.am: kludge to help solaris make
+
+	* configure.in (LIB_kdb): make sure there's a -L option in here by
+ 	adding $(LIB_krb4)
+
+	* lib/asn1/gen_glue.c (generate_2int, generate_int2): int ->
+ 	unsigned
+
+	* configure.in (SunOS): set to a number KRB4, KRB5 conditionals:
+ 	remove the `dnl' to work around an automake flaw
+
+Sun Mar 21 15:08:49 1999  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/get_default_realm.c: char* -> krb5_realm
+
+Sun Mar 21 14:08:30 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* include/bits.c: <bind/bitypes.h>
+
+	* lib/krb5/Makefile.am: create krb5-private.h
+
+Sat Mar 20 00:08:59 1999  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (gethostname): remove duplicate
+
+Fri Mar 19 14:48:03 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/hdb/Makefile.am: add version-info
+
+	* lib/gssapi/Makefile.am: add version-info
+
+	* lib/asn1/Makefile.am: use $(x:y=z) make syntax; move check-der
+ 	to check_PROGRAMS
+
+	* lib/Makefile.am: add 45
+
+	* lib/kadm5/Makefile.am: split in client and server libraries
+ 	(breaks shared libraries otherwise)
+
+Thu Mar 18 11:33:30 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* include/kadm5/Makefile.am: clean a lot of header files (since
+ 	automake lacks a clean-hook)
+
+	* include/Makefile.am: clean a lot of header files (since automake
+ 	lacks a clean-hook)
+
+	* lib/kadm5/Makefile.am: fix build-installation of headers
+
+	* lib/krb5/Makefile.am: remove include_dir hack
+
+	* lib/hdb/Makefile.am: remove include_dir hack
+
+	* lib/asn1/Makefile.am: remove include_dir hack
+
+	* include/Makefile.am: remove include_dir hack
+
+	* doc/whatis.texi: define sub for html
+
+	* configure.in: LIB_kdb, have_err_h, have_fnmatch_h, have_glob_h
+
+	* lib/asn1/Makefile.am: der.h
+
+	* kpasswd/kpasswdd.c: admin.h -> kadm5/admin.h
+
+	* kdc/Makefile.am: remove junk
+
+	* kadmin/Makefile.am: sl.a -> sl.la
+
+	* appl/afsutil/Makefile.am: remove EXTRA_bin_PROGRAMS
+
+	* admin/Makefile.am: sl.a -> sl.la
+
+	* configure.in: condition KRB5; AC_CHECK_XAU
+
+	* Makefile.am: include Makefile.am.common
+
+	* include/kadm5/Makefile.am: include Makefile.am.common; don't
+ 	install headers from here
+
+	* include/Makefile.am: include Makefile.am.common; don't install
+ 	headers from here
+
+	* doc/Makefile.am: include Makefile.am.common
+
+	* lib/krb5/Makefile.am: include Makefile.am.common
+
+	* lib/kadm5/Makefile.am: include Makefile.am.common
+
+	* lib/hdb/Makefile.am: include Makefile.am.common
+
+	* lib/gssapi/Makefile.am: include Makefile.am.common
+
+	* lib/asn1/Makefile.am: include Makefile.am.common
+
+	* lib/Makefile.am: include Makefile.am.common
+
+	* lib/45/Makefile.am: include Makefile.am.common
+
+	* kuser/Makefile.am: include Makefile.am.common
+
+	* kpasswd/Makefile.am: include Makefile.am.common
+
+	* kdc/Makefile.am: include Makefile.am.common
+
+	* kadmin/Makefile.am: include Makefile.am.common
+
+	* appl/test/Makefile.am: include Makefile.am.common
+
+	* appl/afsutil/Makefile.am: include Makefile.am.common
+
+	* appl/Makefile.am: include Makefile.am.common
+
+	* admin/Makefile.am: include Makefile.am.common
+
+Wed Mar 17 03:04:38 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/store.c (krb5_store_stringz): braces fix
+
+	* lib/kadm5/get_s.c (kadm5_s_get_principal): braces fix
+
+	* lib/kadm5/ent_setup.c (_kadm5_setup_entry): braces fix
+
+	* kdc/connect.c (loop): braces fix
+
+	* lib/krb5/config_file.c: cast to unsigned char to make is* happy
+
+	* lib/krb5/log.c (krb5_addlog_dest): more braces to make gcc happy
+
+	* lib/krb5/crypto.c (krb5_verify_checksum): rename C -> cksum to
+ 	be consistent
+
+	* kadmin/util.c (timeval2str): more braces to make gcc happy
+
+	* kadmin/load.c: cast in is* to get rid of stupid warning
+
+	* kadmin/dump.c (append_hex): cast in isalnum to get rid of stupid
+ 	warning
+
+	* kdc/kaserver.c: malloc checks and fixes
+
+	* lib/krb5/get_host_realm.c (krb5_get_host_realm): include leading
+ 	dot (if any) when looking up realms.
+
+Fri Mar 12 13:57:56 1999  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/get_host_realm.c: add dns support
+
+	* lib/krb5/set_default_realm.c: use krb5_free_host_realm
+
+	* lib/krb5/free_host_realm.c: check for NULL realmlist
+
+	* lib/krb5/context.c: don't print warning if there is no krb5.conf
+
+Wed Mar 10 19:29:46 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* configure.in: use AC_WFLAGS
+
+Mon Mar  8 11:49:43 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* Release 0.1c
+
+	* kuser/klist.c: use print_version
+
+	* kuser/kdestroy.c: use print_version
+
+	* kdc/hpropd.c: use print_version
+
+	* kdc/hprop.c: use print_version
+
+	* kdc/config.c: use print_version
+
+	* kadmin/kadmind.c: use print_version
+
+	* kadmin/kadmin.c: use print_version
+
+	* appl/test/common.c: use print_version
+
+	* appl/afsutil/afslog.c: use print_version
+
+Mon Mar  1 10:49:14 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/krb5/get_addrs.c: SOCKADDR_HAS_SA_LEN ->
+ 	HAVE_STRUCT_SOCKADDR_SA_LEN
+
+	* configure.in, acconfig.h, cf/*: update to automake 1.4/autoconf 2.13
+
+Sun Feb 28 18:19:20 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/asn1/gen.c: make `BIT STRING's unsigned
+
+	* lib/asn1/{symbol.h,gen.c}: add TUInteger type
+
+	* lib/krb5/verify_user.c (krb5_verify_user): pass prompter to
+ 	krb5_get_init_creds_password
+
+	* lib/krb5/fcache.c (fcc_gen_new): implement
+
+Sat Feb 27 22:41:23 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* doc/install.texi: krb4 is now automatically detected
+
+	* doc/misc.texi: update procedure to set supported encryption
+ 	types
+
+	* doc/setup.texi: change some silly wordings
+
+Sat Feb 27 22:17:30 1999  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/krb5/keytab.c (fkt_remove_entry): make this work
+
+	* admin/ktutil.c: add minimally working `get' command
+
+Sat Feb 27 19:44:49 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* lib/hdb/convert_db.c: more typos
+
+	* include/Makefile.am: remove EXTRA_DATA (as of autoconf
+ 	2.13/automake 1.4)
+
+	* appl/Makefile.am: OTP_dir
+
+Fri Feb 26 17:37:00 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* doc/setup.texi: add kadmin section
+
+	* lib/asn1/check-der.c: fix printf warnings
+
+Thu Feb 25 11:16:49 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* configure.in: -O does not belong in WFLAGS
+
+Thu Feb 25 11:05:57 1999  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/asn1/der_put.c: fix der_put_int
+
+Tue Feb 23 20:35:12 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* configure.in: use AC_BROKEN_GLOB
+
+Mon Feb 22 15:12:44 1999  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* configure.in: check for glob
+
+Mon Feb 22 11:32:42 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* Release 0.1b
+
+Sat Feb 20 15:48:06 1999  Johan Danielsson  <joda@blubb.pdc.kth.se>
+
+	* lib/hdb/convert_db.c: convert DES3 keys to des3-cbc-sha1, and
+ 	des3-cbc-md5
+
+	* lib/krb5/crypto.c (DES3_string_to_key): make this actually do
+ 	what the draft said it should
+
+	* lib/hdb/convert_db.c: little program for database conversion
+
+	* lib/hdb/db.c (DB_open): try to open database w/o .db extension
+
+	* lib/hdb/ndbm.c (NDBM_open): add test for database format
+
+	* lib/hdb/db.c (DB_open): add test for database format
+
+	* lib/asn1/gen_glue.c (generate_2int): don't depend on flags being
+ 	unsigned
+
+	* lib/hdb/hdb.c: change `hdb_set_master_key' to take an
+ 	EncryptionKey, and add a new function `hdb_set_master_keyfile' to
+ 	do what `hdb_set_master_key' used to do
+
+	* kdc/kstash.c: add `--convert-file' option to change keytype of
+ 	existing master key file
+
+Fri Feb 19 07:04:14 1999  Assar Westerlund  <assar@squid.pdc.kth.se>
+
+	* Release 0.1a
+
+Sat Feb 13 17:12:53 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/mk_safe.c (krb5_mk_safe): sizeof(buf) -> buf_size, buf
+ 	is now a `u_char *'
+
+	* lib/krb5/get_in_tkt.c (krb5_init_etype): etypes are now `int'
+
+	* lib/krb5/get_host_realm.c (krb5_get_host_realm): constize
+ 	orig_host
+
+ 	(krb5_salttype_to_string): new function (RSA_MD5_DES_verify,
+ 	RSA_MD5_DES3_verify): initialize ret
+
+	* lib/gssapi/init_sec_context.c (init_auth): remove unnecessary
+ 	gssapi_krb5_init.  ask for KEYTYPE_DES credentials
+
+	* kadmin/get.c (print_entry_long): print the keytypes and salts
+ 	available for the principal
+
+	* configure.in (WFLAGS): add `-O' to catch unitialized variables
+ 	and such
+	(gethostname, mkstemp, getusershell, inet_aton): more tests
+
+	* lib/hdb/hdb.h: update prototypes
+
+	* configure.in: homogenize broken detection with krb4
+
+	* lib/kadm5/init_c.c (kadm5_c_init_with_context): remove unused
+ 	`error'
+
+	* lib/asn1/Makefile.am (check-der): add
+
+	* lib/asn1/gen.c (define_type): map ASN1 Integer to `int' instead
+ 	of `unsigned'
+
+	* lib/asn1/der_length.c (length_unsigned): new function
+	(length_int): handle signed integers
+
+	* lib/asn1/der_put.c (der_put_unsigned): new function
+	(der_put_int): handle signed integers
+
+ 	* lib/asn1/der_get.c (der_get_unsigned): new function
+ 	(der_get_int): handle signed integers
+
+	* lib/asn1/der.h: all integer functions take `int' instead of
+ 	`unsigned'
+
+	* lib/asn1/lex.l (filename): unused. remove.
+
+	* lib/asn1/check-der.c: new test program for der encoding and
+ 	decoding.
+
+Mon Feb  1 04:09:06 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/send_to_kdc.c (krb5_sendto_kdc): only call
+ 	gethostbyname2 with AF_INET6 if we actually have IPv6.  From
+ 	"Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
+
+ 	* lib/krb5/changepw.c (get_kdc_address): dito
+
+Sun Jan 31 06:26:36 1999  Assar Westerlund  <assar@sics.se>
+
+	* kdc/connect.c (parse_prots): always bind to AF_INET, there are
+ 	v6-implementations without support for `mapped V4 addresses'.
+  	From Jun-ichiro itojun Hagino <itojun@kame.net>
+
+Sat Jan 30 22:38:27 1999  Assar Westerlund  <assar@juguete.sics.se>
+
+	* Release 0.0u
+
+Sat Jan 30 13:43:02 1999  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: explicit rules for *.et files
+
+ 	* lib/kadm5/init_c.c (get_kadm_ticket): only remove creds if
+ 	krb5_get_credentials was succesful.
+ 	(get_new_cache): return better error codes and return earlier.
+ 	(get_cred_cache): only delete default_client if it's different
+ 	from client
+ 	(kadm5_c_init_with_context): return a more descriptive error.
+
+	* kdc/kerberos5.c (check_flags): handle NULL client or server
+
+	* lib/krb5/sendauth.c (krb5_sendauth): return the error in
+ 	`ret_error' iff != NULL
+
+	* lib/krb5/rd_error.c (krb5_free_error, krb5_free_error_contents):
+ 	new functions
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_extended): more
+ 	type-correctness
+
+	* lib/krb5/krb5.h (krb5_error): typedef to KRB_ERROR
+
+	* lib/krb5/init_creds_pw.c: KRB5_TGS_NAME: use
+
+	* lib/krb5/get_cred.c: KRB5_TGS_NAME: use
+
+ 	* lib/kafs/afskrb5.c (afslog_uid_int): update to changes
+
+	* lib/kadm5/rename_s.c (kadm5_s_rename_principal): call remove
+ 	instead of rename, but shouldn't this just call rename?
+
+ 	* lib/kadm5/get_s.c (kadm5_s_get_principal): always return an
+ 	error if the principal wasn't found.
+
+	* lib/hdb/ndbm.c (NDBM_seq): unseal key
+
+	* lib/hdb/db.c (DB_seq): unseal key
+
+	* lib/asn1/Makefile.am: added explicit rules for asn1_err.[ch]
+
+	* kdc/hprop.c (v4_prop): add krbtgt/THISREALM@OTHERREALM when
+ 	finding cross-realm tgts in the v4 database
+
+	* kadmin/mod.c (mod_entry): check the number of arguments.  check
+ 	that kadm5_get_principal worked.
+
+	* lib/krb5/keytab.c (fkt_remove_entry): remove KRB5_KT_NOTFOUND if
+ 	we weren't able to remove it.
+
+	* admin/ktutil.c: less drive-by-deleting.  From Love
+ 	<lha@e.kth.se>
+
+	* kdc/connect.c (parse_ports): copy the string before mishandling
+ 	it with strtok_r
+
+	* kdc/kerberos5.c (tgs_rep2): print the principal with mismatching
+ 	kvnos
+
+	* kadmin/kadmind.c (main): convert `debug_port' to network byte
+ 	order
+
+	* kadmin/kadmin.c: allow specification of port number.
+
+	* lib/kadm5/kadm5_locl.h (kadm5_client_context): add
+ 	`kadmind_port'.
+
+	* lib/kadm5/init_c.c (_kadm5_c_init_context): move up
+ 	initalize_kadm5_error_table_r.
+	allow specification of port number.
+	
+  	From Love <lha@stacken.kth.se>
+
+	* kuser/klist.c: add option -t | --test
+
diff --git a/crypto/heimdal/ChangeLog.2000 b/crypto/heimdal/ChangeLog.2000
new file mode 100644
index 000000000000..a1cb687f550e
--- /dev/null
+++ b/crypto/heimdal/ChangeLog.2000
@@ -0,0 +1,1320 @@
+2000-12-31  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/test_get_addrs.c (main): handle krb5_init_context
+	failure consistently
+	* lib/krb5/string-to-key-test.c (main): handle krb5_init_context
+	failure consistently
+	* lib/krb5/prog_setup.c (krb5_program_setup): handle
+	krb5_init_context failure consistently
+	* lib/hdb/convert_db.c (main): handle krb5_init_context failure
+	consistently
+	* kuser/kverify.c (main): handle krb5_init_context failure
+	consistently
+	* kuser/klist.c (main): handle krb5_init_context failure
+	consistently
+	* kuser/kinit.c (main): handle krb5_init_context failure
+	consistently
+	* kuser/kgetcred.c (main): handle krb5_init_context failure
+	consistently
+	* kuser/kdestroy.c (main): handle krb5_init_context failure
+	consistently
+	* kuser/kdecode_ticket.c (main): handle krb5_init_context failure
+	consistently
+	* kuser/generate-requests.c (generate_requests): handle
+	krb5_init_context failure consistently
+	* kpasswd/kpasswd.c (main): handle krb5_init_context failure
+	consistently
+	* kpasswd/kpasswd-generator.c (generate_requests): handle
+	krb5_init_context failure consistently
+	* kdc/main.c (main): handle krb5_init_context failure consistently
+	* appl/test/uu_client.c (proto): handle krb5_init_context failure
+	consistently
+	* appl/kf/kf.c (main): handle krb5_init_context failure
+	consistently
+	* admin/ktutil.c (main): handle krb5_init_context failure
+	consistently
+
+	* admin/get.c (kt_get): more error checking
+
+2000-12-29  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/asn1_print.c (loop): check for length longer than data.
+	inspired by lha@stacken.kth.se
+
+2000-12-16  Johan Danielsson  <joda@pdc.kth.se>
+
+	* admin/ktutil.8: reflect recent changes
+
+	* admin/copy.c: don't copy an entry that already exists in the
+	keytab, and warn if the keyblock differs
+
+2000-12-15  Johan Danielsson  <joda@pdc.kth.se>
+
+	* admin/Makefile.am: merge srvconvert and srvcreate with copy
+
+	* admin/copy.c: merge srvconvert and srvcreate with copy
+
+	* lib/krb5/Makefile.am: always build keytab_krb4.c
+
+	* lib/krb5/context.c: always register the krb4 keytab functions
+
+	* lib/krb5/krb5.h: declare krb4_ftk_ops
+
+	* lib/krb5/keytab_krb4.c: We don't really need to include krb.h
+	here, since we only use the principal size macros, so define these
+	here. Theoretically someone could have a krb4 system where these
+	values are != 40, but this is unlikely, and
+	krb5_524_conv_principal also assume they are 40.
+
+2000-12-13  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/krb5.h: s/krb5_donot_reply/krb5_donot_replay/
+
+	* lib/krb5/replay.c: fix query-replace-o from MD5 API change, and
+	the struct is called krb5_donot_replay
+
+2000-12-12  Assar Westerlund  <assar@sics.se>
+
+	* admin/srvconvert.c (srvconvert): do not use data after free:ing
+	it
+
+2000-12-11  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.3d
+
+2000-12-11  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): set version to 14:0:0
+	* lib/hdb/Makefile.am (libhdb_la_LDFLAGS): update to 6:3:0
+	* lib/krb5/Makefile.am (libkrb5_la_LIBADD): add library
+	dependencies
+
+2000-12-10  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/auth_context.c: implement krb5_auth_con_{get,set}rcache
+
+2000-12-08  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krb5.h (krb5_enctype): add ETYPE_DES3_CBC_NONE_IVEC as
+	a new pseudo-type
+
+	* lib/krb5/crypto.c (DES_AFS3_CMU_string_to_key): always treat
+	cell names as lower case
+	(krb5_encrypt_ivec, krb5_decrypt_ivec): new functions that allow an
+	explicit ivec to be specified.  fix all sub-functions.
+	(DES3_CBC_encrypt_ivec): new function that takes an explicit ivec
+
+2000-12-06  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/Makefile.am: actually build replay cache code
+
+	* lib/krb5/replay.c: implement krb5_get_server_rcache
+
+	* kpasswd/kpasswdd.c: de-pointerise auth_context parameter to
+	krb5_mk_rep
+
+	* lib/krb5/recvauth.c: de-pointerise auth_context parameter to
+	krb5_mk_rep
+
+	* lib/krb5/mk_rep.c: auth_context should not be a pointer
+
+	* lib/krb5/auth_context.c: implement krb5_auth_con_genaddrs, and
+	make setaddrs_from_fd use that
+
+	* lib/krb5/krb5.h: add some more KRB5_AUTH_CONTEXT_* flags
+
+2000-12-05  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/Makefile.am: add kerberos.8 manpage
+
+	* lib/krb5/cache.c: check for NULL remove_cred function
+
+	* lib/krb5/fcache.c: pretend that empty files are non-existant
+
+	* lib/krb5/get_addrs.c (find_all_addresses): use getifaddrs, from
+	Jason Thorpe <thorpej@netbsd.org>
+
+2000-12-01  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: remove configure-time generation of krb5-config
+	* tools/Makefile.am: add generation of krb5-config at make-time
+	instead of configure-time
+
+	* tools/krb5-config.in: add --prefix and --exec-prefix
+
+2000-11-30  Assar Westerlund  <assar@sics.se>
+
+	* tools/Makefile.am: add krb5-config.1
+	* tools/krb5-config.in: add kadm-client and kadm5-server as
+	libraries
+
+2000-11-29  Assar Westerlund  <assar@sics.se>
+
+	* tools/krb5-config.in: add --prefix, --exec-prefix and gssapi
+
+2000-11-29  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: add roken/Makefile here, since it can't live in
+	rk_ROKEN
+
+2000-11-16  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: use the libtool -rpath, do not rely on ld
+	understanding -rpath
+
+	* configure.in: fix the -Wl stuff for krb4 linking add some
+	gratuitous extra options when linking with an existing libdes
+
+2000-11-15  Assar Westerlund  <assar@sics.se>
+
+	* lib/hdb/hdb.c (hdb_next_enctype2key): const-ize a little bit
+	* lib/Makefile.am (SUBDIRS): try to only build des when needed
+	* kuser/klist.c: print key versions numbers of v4 tickets in
+	verbose mode
+
+	* kdc/kerberos5.c (tgs_rep2): adapt to new krb5_verify_ap_req2
+	* appl/test/gss_common.c (read_token): remove unused variable
+
+	* configure.in (krb4): add -Wl
+	(MD4Init et al): look for these in more libraries
+	(getmsg): only run test if we have the function
+	(AC_OUTPUT): create tools/krb5-config
+
+	* tools/krb5-config.in: new script for storing flags to use
+	* Makefile.am (SUBDIRS): add tools
+
+	* lib/krb5/get_cred.c (make_pa_tgs_req): update to new
+	krb5_mk_req_internal
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_internal): allow different
+	usages for the encryption.  change callers
+	* lib/krb5/rd_req.c (decrypt_authenticator): add an encryption
+	`usage'.  also try the old
+	(and wrong) usage of KRB5_KU_AP_REQ_AUTH for backwards compatibility
+	(krb5_verify_ap_req2): new function for specifying the usage different
+	from the default (KRB5_KU_AP_REQ_AUTH)
+	* lib/krb5/build_auth.c (krb5_build_authenticator): add a `usage'
+	parameter to permit the generation of authenticators with
+	different crypto usage
+
+	* lib/krb5/mk_req.c (krb5_mk_req_exact): new function that takes a
+	krb5_principal
+	(krb5_mk_req): use krb5_mk_req_exact
+
+	* lib/krb5/mcache.c (mcc_close): free data
+	(mcc_destroy): don't free data
+
+2000-11-13  Assar Westerlund  <assar@sics.se>
+
+	* lib/hdb/ndbm.c: handle both ndbm.h and gdbm/ndbm.h
+	* lib/hdb/hdb.c: handle both ndbm.h and gdbm/ndbm.h
+
+2000-11-12  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/hpropd.8: remove extra .Xc
+
+2000-10-27  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kuser/kinit.c: fix v4 fallback lifetime calculation
+
+2000-10-10  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/524.c: fix log messge
+
+2000-10-08  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/changepw.c (krb5_change_password): check for fd's being
+	too large to select on
+	* kpasswd/kpasswdd.c (add_new_tcp): check for the socket fd being
+	too large to select on
+	* kdc/connect.c (add_new_tcp): check for the socket fd being too
+	large to selct on
+	* kdc/connect.c (loop): check that the socket fd is not too large
+	to select on
+	* lib/krb5/send_to_kdc.c (recv_loop): check `fd' for being too
+	large to be able to select on
+
+	* kdc/kaserver.c (do_authenticate): check for time skew
+
+2000-10-01  Assar Westerlund  <assar@sics.se>
+
+	* kdc/524.c (set_address): allocate memory for storing addresses
+	in if the original request had an empty set of addresses
+	* kdc/524.c (set_address): fix bad return of pointer to automatic
+	data
+
+	* config.sub: update to version 2000-09-11 (aka 1.181) from
+	subversions.gnu.org
+
+	* config.guess: update to version 2000-09-05 (aka 1.156) from
+	subversions.gnu.org plus some minor tweaks
+
+2000-09-20  Assar Westerlund  <assar@juguete.sics.se>
+
+	* Release 0.3c
+
+2000-09-19  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): bump version to
+	13:1:0
+
+	* lib/hdb/Makefile.am (libhdb_la_LDFLAGS): bump version to 6:2:0
+
+2000-09-17  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_req.c (krb5_decrypt_ticket): plug some memory leak
+	(krb5_rd_req): try not to return an allocated auth_context on error
+
+	* lib/krb5/log.c (krb5_vlog_msg): fix const-ness
+
+2000-09-10  Assar Westerlund  <assar@sics.se>
+
+	* kdc/524.c: re-organize
+	* kdc/kerberos5.c (tgs_rep2): try to avoid leaking auth_context
+	* kdc/kerberos4.c (valid_princ): check return value of functions
+	(encode_v4_ticket): add some const
+	* kdc/misc.c (db_fetch): check malloc
+	(free_ent): new function
+
+	* lib/krb5/log.c (krb5_vlog_msg): log just the format string it we
+	fail to allocate the actual string to log, should at least provide
+	some hint as to where things went wrong
+
+2000-09-10  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/log.c: use DEFAULT_LOG_DEST
+
+	* kdc/config.c: use _PATH_KDC_CONF
+
+	* kdc/kdc_locl.h: add macro constants for kdc.conf, and kdc.log
+
+2000-09-09  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/crypto.c (_key_schedule): re-use an existing schedule
+
+2000-09-06  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: fix dpagaix test
+
+2000-09-05  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: with_dce -> enable_dce.  noticed by Ake Sandgren
+ 	<ake@cs.umu.se>
+
+2000-09-01  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/kstash.8: update manual page
+
+	* kdc/kstash.c: fix typo, and remove unused option
+
+	* lib/krb5/kerberos.7: short kerberos intro page
+
+2000-08-27  Assar Westerlund  <assar@sics.se>
+
+	* include/bits.c: add __attribute__ for gcc's pleasure
+	* lib/hdb/keytab.c: re-write to delay the opening of the database
+	till it's known which principal is being sought, thereby allowing
+	the usage of multiple databases, however they need to be specified
+	in /etc/krb5.conf since all the programs using this keytab do not
+	read kdc.conf
+
+	* appl/test/test_locl.h (keytab): add
+	* appl/test/common.c: add --keytab
+	* lib/krb5/crypto.c: remove trailing commas
+	(KRB5_KU_USAGE_SEQ): renamed from KRB5_KU_USAGE_MIC
+
+2000-08-26  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/send_to_kdc.c (send_via_proxy): handle `http://' at the
+	beginning of the proxy specification.  use getaddrinfo correctly
+	(krb5_sendto): always return a return code
+
+	* lib/krb5/krb5.h (KRB5_KU_USAGE_MIC): rename to KRB5_KU_USAGE_SEQ
+	* lib/krb5/auth_context.c (krb5_auth_con_free): handle
+	auth_context == NULL
+
+2000-08-23  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos5.c (find_type): make sure of always setting
+	`ret_etype' correctly.  clean-up structure some
+
+2000-08-23  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/mcache.c: implement resolve
+
+2000-08-18  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kdecode_ticket.c: check return value from krb5_crypto_init
+	* kdc/kerberos5.c, kdc/524.c: check return value from krb5_crypto_init
+	* lib/krb5/*.c: check return value from krb5_crypto_init
+
+2000-08-16  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.3b
+
+2000-08-16  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: bump version to 13:0:0
+
+	* lib/hdb/Makefile.am: set version to 6:1:0
+
+	* configure.in: do getmsg testing the same way as in krb4
+
+	* lib/krb5/config_file.c (krb5_config_parse_file_debug): make sure
+ 	of closing the file on error
+
+	* lib/krb5/crypto.c (encrypt_internal_derived): free the checksum
+ 	after use
+
+	* lib/krb5/warn.c (_warnerr): initialize args to make third,
+ 	purify et al happy
+
+2000-08-13  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos5.c: re-write search for keys code.  loop over all
+	supported enctypes in order, looping over all keys of each type,
+	and picking the one with the v5 default salt preferably
+
+2000-08-10  Assar Westerlund  <assar@sics.se>
+
+	* appl/test/gss_common.c (enet_read): add and use
+	* lib/krb5/krb5.h (heimdal_version, heimdal_long_version): make
+	const
+
+	* lib/krb5/mk_req_ext.c (krb5_mk_req_internal): add comment on
+	checksum type selection
+
+	* lib/krb5/context.c (krb5_init_context): do not leak memory on
+	failure
+	(default_etypes): prefer arcfour-hmac-md5 to des-cbc-md5
+
+	* lib/krb5/principal.c: add fnmatch.h
+
+2000-08-09  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: call AC_PROG_CC and AC_PROG_CPP to make sure later
+	checks that should require them don't fail
+	* acconfig.h: add HAVE_UINT17_T
+
+2000-08-09  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/mit_dump.c: handle all sorts of weird MIT salt types
+
+2000-08-08  Johan Danielsson  <joda@pdc.kth.se>
+
+	* doc/setup.texi: port 212 -> 2121
+
+	* lib/krb5/principal.c: krb5_principal_match
+
+2000-08-04  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/asn1/der_get.c: add comment on *why* DCE sometimes used BER
+	encoding
+
+	* kpasswd/Makefile.am: link with pidfile library
+
+	* kpasswd/kpasswdd.c: write a pid file
+
+	* kpasswd/kpasswd_locl.h: util.h
+
+	* kdc/Makefile.am: link with pidfile library
+
+	* kdc/main.c: write a pid file
+
+	* kdc/headers.h: util.h
+
+2000-08-04  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (krb5_425_conv_principal_ext): always put
+	hostnames in lower case
+	(default_v4_name_convert): add imap
+
+2000-08-03  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/crc.c (_krb5_crc_update): const-ize (finally)
+
+2000-07-31  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: check for uint*_t
+	* include/bits.c: define uint*_t
+	
+2000-07-29  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos5.c (check_tgs_flags): set endtime correctly when
+	renewing, From Derrick J Brashear <shadow@dementia.org>
+
+2000-07-28  Assar Westerlund  <assar@juguete.sics.se>
+
+	* Release 0.3a
+
+2000-07-27  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hprop.c (dump_database): write an empty message to signal
+	end of dump
+
+2000-07-26  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/changepw.c (krb5_change_password): try to be more
+	careful when not to resend
+
+	* lib/hdb/db3.c: always create a cursor with db3.  From Derrick J
+	Brashear <shadow@dementia.org>
+
+2000-07-25  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/hdb/Makefile.am: bump version to 6:0:0
+
+	* lib/asn1/Makefile.am: bump version to 3:0:1
+
+	* lib/krb5/Makefile.am: bump version to 12:0:1
+
+	* lib/krb5/krb5_config.3: manpage
+
+	* lib/krb5/krb5_appdefault.3: manpage
+
+	* lib/krb5/appdefault.c: implementation of the krb5_appdefault set
+	of functions
+
+2000-07-23  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/init_creds_pw.c (change_password): reset forwardable
+	and proxiable.  copy preauthentication list correctly from
+	supplied options
+
+	* kdc/hpropd.c (main): check that the ticket was for `hprop/' for
+	paranoid reasons
+
+	* lib/krb5/sock_principal.c (krb5_sock_to_principal): look in
+	aliases for the real name
+
+2000-07-22  Johan Danielsson  <joda@pdc.kth.se>
+
+	* doc/setup.texi: say something about starting kadmind from the
+	command line
+
+2000-07-22  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd/kpasswdd.c: use kadm5_s_chpass_principal_cond instead of
+	mis-doing it here
+
+	* lib/krb5/changepw.c (krb5_change_password): make timeout 1 +
+	2^{0,1,...}.  also keep track if we got an old packet back and
+	then just wait without sending a new packet
+	* lib/krb5/changepw.c: use a datagram socket and remove the
+	sequence numbers
+	* lib/krb5/changepw.c (krb5_change_password): clarify an
+	expression, avoiding a warning
+
+2000-07-22  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kuser/klist.c: make -a and -n aliases for -v
+
+	* lib/krb5/write_message.c: ws
+
+	* kdc/hprop-common.c: nuke extra definitions of
+	krb5_read_priv_message et.al
+
+	* lib/krb5/read_message.c (krb5_read_message): return error if EOF
+
+2000-07-20  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd/kpasswd.c: print usage consistently
+	* kdc/hprop.h (HPROP_KEYTAB): use HDB for the keytab
+	* kdc/hpropd.c: add --keytab
+	* kdc/hpropd.c: don't care what principal we recvauth as
+
+	* lib/krb5/get_cred.c: be more careful of not returning creds at
+	all when an error is returned
+	* lib/krb5/fcache.c (fcc_gen_new): do mkstemp correctly
+
+2000-07-19  Johan Danielsson  <joda@pdc.kth.se>
+
+	* fix-export: use autoreconf
+
+	* configure.in: remove stuff that belong in roken, and remove some
+	obsolete constructs
+
+2000-07-18  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: fix some typos
+
+	* appl/Makefile.am: dceutil*s*
+
+	* missing: update to missing from automake 1.4a
+
+2000-07-17  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: try to get xlc flags from ibmcxx.cfg use
+	conditional for X use readline cf macro
+
+	* configure.in: subst AIX compiler flags
+
+2000-07-15  Johan Danielsson  <joda@pdc.kth.se>
+
+	* configure.in: pass sixth parameter to test-package; use some
+	newer autoconf constructs
+
+	* ltmain.sh: update to libtool 1.3c
+
+	* ltconfig: update to libtool 1.3c
+
+	* configure.in: update this to newer auto*/libtool
+
+	* appl/Makefile.am: use conditional for dce
+	
+	* lib/Makefile.am: use conditional for dce
+	
+2000-07-11  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/write_message.c: krb5_write_{priv,save}_message
+	* lib/krb5/read_message.c: krb5_read_{priv,save}_message
+	* lib/krb5/convert_creds.c: try port kerberos/88 if no response on
+	krb524/4444
+
+	* lib/krb5/convert_creds.c: use krb5_sendto
+
+	* lib/krb5/send_to_kdc.c: add more generic krb5_sendto that send
+	to a port at arbitrary list of hosts
+
+2000-07-10  Johan Danielsson  <joda@pdc.kth.se>
+
+	* doc/misc.texi: language; say something about kadmin del_enctype
+
+2000-07-10  Assar Westerlund  <assar@sics.se>
+
+	* appl/kf/Makefile.am: actually install
+
+2000-07-08  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (AM_INIT_AUTOMAKE): bump to 0.3a-pre
+	(AC_ROKEN): roken is now at 10
+
+	* lib/krb5/string-to-key-test.c: add a arcfour-hmac-md5 test case
+	* kdc/Makefile.am (INCLUDES): add ../lib/krb5
+	* configure.in: update for standalone roken
+	* lib/Makefile.am (SUBDIRS): make roken conditional
+	* kdc/hprop.c: update to new hdb_seal_keys_mkey
+	* lib/hdb/mkey.c (_hdb_unseal_keys_int, _hdb_seal_keys_int):
+	rename and export them
+
+	* kdc/headers.h: add krb5_locl.h (since we just use some stuff
+	from there)
+
+2000-07-08  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kuser/klist.1: update for -f and add some more text for -v
+
+	* kuser/klist.c: use rtbl to format cred listing, add -f and -s
+
+	* lib/krb5/crypto.c: fix type in des3-cbc-none
+
+	* lib/hdb/mkey.c: add key usage
+
+	* kdc/kstash.c: remove writing of old keyfile, and treat
+	--convert-file as just reading and writing the keyfile without
+	asking for a new key
+	
+	* lib/hdb/mkey.c (read_master_encryptionkey): handle old keytype
+	based files, and convert the key to cfb64
+
+	* lib/hdb/mkey.c (hdb_read_master_key): set mkey to NULL before
+	doing anything else
+
+	* lib/krb5/send_to_kdc.c: use krb5_eai_to_heim_errno
+
+	* lib/krb5/get_for_creds.c: use krb5_eai_to_heim_errno
+
+	* lib/krb5/changepw.c: use krb5_eai_to_heim_errno
+
+	* lib/krb5/addr_families.c: use krb5_eai_to_heim_errno
+
+	* lib/krb5/eai_to_heim_errno.c: convert getaddrinfo error codes to
+	something that can be passed to get_err_text
+
+2000-07-07  Assar Westerlund  <assar@sics.se>
+
+	* lib/hdb/hdb.c (hdb_next_enctype2key): make sure of skipping
+	`*key'
+
+	* kdc/kerberos4.c (get_des_key): rewrite some, be more careful
+
+2000-07-06  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos5.c (as_rep): be careful as to now overflowing when
+	calculating the end of lifetime of a ticket.
+
+	* lib/krb5/context.c (default_etypes): add ETYPE_ARCFOUR_HMAC_MD5
+
+	* lib/hdb/db3.c: only use a cursor when needed, from Derrick J
+	Brashear <shadow@dementia.org>
+
+	* lib/krb5/crypto.c: introduce the `special' encryption methods
+	that are not like all other encryption methods and implement
+	arcfour-hmac-md5
+
+2000-07-05  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/mit_dump.c: set initial master key version number to 0
+	instead of 1; if we lated bump the mkvno we don't risk using the
+	wrong key to decrypt
+
+	* kdc/hprop.c: only get master key if we're actually going to use
+	it; enable reading of MIT krb5 dump files
+	
+	* kdc/mit_dump.c: read MIT krb5 dump files
+	
+	* lib/hdb/mkey.c (read_master_mit): fix this
+	
+	* kdc/kstash.c: make this work with the new mkey code
+	
+	* lib/hdb/Makefile.am: add mkey.c, and bump version number
+	
+	* lib/hdb/hdb.h: rewrite master key handling
+	
+	* lib/hdb/mkey.c: rewrite master key handling
+	
+	* lib/krb5/crypto.c: add some more pseudo crypto types
+	
+	* lib/krb5/krb5.h: change some funny etypes to use negative
+	numbers, and add some more
+
+2000-07-04  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krbhst.c (get_krbhst): only try SRV lookup if there are
+	none in the configuration file
+
+2000-07-02  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/keytab_keyfile.c (akf_add_entry): remove unused
+	variable
+
+	* kpasswd/kpasswd-generator.c: new test program
+	* kpasswd/Makefile.am: add kpasswd-generator
+
+	* include/Makefile.am (CLEANFILES): add rc4.h
+
+	* kuser/generate-requests.c: new test program
+	* kuser/Makefile.am (noinst_PROGRAMS): add generate-requests
+
+2000-07-01  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: add --enable-dce and related stuff
+	* appl/Makefile.am (SUBDIRS): add $(APPL_dce)
+
+2000-06-29  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos4.c (get_des_key): fix thinkos/typos
+
+2000-06-29  Johan Danielsson  <joda@pdc.kth.se>
+
+	* admin/purge.c: use parse_time to parse age
+
+	* lib/krb5/log.c (krb5_vlog_msg): use krb5_format_time
+
+	* admin/list.c: add printing of timestamp and key data; some
+	cleanup
+
+	* lib/krb5/time.c (krb5_format_time): new function to format time
+
+	* lib/krb5/context.c (init_context_from_config_file): init
+	date_fmt, also do some cleanup
+
+	* lib/krb5/krb5.h: add date_fmt to context
+
+2000-06-28  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/{kerberos4,kaserver,524}.c (get_des_key): change to return
+	v4 or afs keys if possible
+
+2000-06-25  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/hprop.c (ka_convert): allow using null salt, and treat 0
+	pw_expire as never (from Derrick Brashear)
+
+2000-06-24  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/connect.c (add_standard_ports): only listen to port 750 if
+	serving v4 requests
+
+2000-06-22  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/lex.l: fix includes, and lex stuff
+	* lib/asn1/lex.h (error_message): update prototype
+	(yylex): add
+	* lib/asn1/gen_length.c (length_type): fail on malloc error
+	* lib/asn1/gen_decode.c (decode_type): fail on malloc error
+
+2000-06-21  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_for_creds.c: be more compatible with MIT code.
+	From Daniel Kouril <kouril@ics.muni.cz>
+	* lib/krb5/rd_cred.c: be more compatible with MIT code.  From
+	Daniel Kouril <kouril@ics.muni.cz>
+	* kdc/kerberos5.c (get_pa_etype_info): do not set salttype if it's
+	vanilla pw-salt, that keeps win2k happy.  also do the malloc check
+	correctly.  From Daniel Kouril <kouril@ics.muni.cz>
+
+2000-06-21  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/hprop.c: add hdb keytabs
+
+2000-06-20  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/principal.c: back out rev. 1.64
+
+2000-06-19  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/kerberos5.c: pa_* -> KRB5_PADATA_*
+
+	* kdc/hpropd.c: add realm override flag
+	
+	* kdc/v4_dump.c: code for reading krb4 dump files
+	
+	* kdc/hprop.c: generalize source database handing, add support for
+	non-standard local realms (from by Daniel Kouril
+	<kouril@ics.muni.cz> and Miroslav Ruda <ruda@ics.muni.cz>), and
+	support for using different ports (requested by the Czechs, but
+	implemented differently)
+
+	* lib/krb5/get_cred.c: pa_* -> KRB5_PADATA_*
+	
+	* lib/krb5/get_in_tkt.c: pa_* -> KRB5_PADATA_*
+	
+	* lib/krb5/krb5.h: use some definitions from asn1.h
+
+	* lib/hdb/hdb.asn1: use new import syntax
+	
+	* lib/asn1/k5.asn1: use distinguished value integers
+	
+	* lib/asn1/gen_length.c: support for distinguished value integers
+	
+	* lib/asn1/gen_encode.c: support for distinguished value integers
+	
+	* lib/asn1/gen_decode.c: support for distinguished value integers
+	
+	* lib/asn1/gen.c: support for distinguished value integers
+
+	* lib/asn1/lex.l: add support for more standards like import
+	statements
+
+	* lib/asn1/parse.y: add support for more standards like import
+	statements, and distinguished value integers
+	
+2000-06-11  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_for_creds.c (add_addrs): ignore addresses of
+	unknown type
+	* lib/krb5/get_for_creds.c (add_addrs): zero memory before
+	starting to copy memory
+
+2000-06-10  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/test_get_addrs.c: test program for get_addrs
+	* lib/krb5/get_addrs.c (find_all_addresses): remember to add in
+ 	the size of ifr->ifr_name when using SA_LEN.  noticed by Ken
+ 	Raeburn <raeburn@MIT.EDU>
+
+2000-06-07  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: add db3 detection stuff do not use streamsptys on
+	HP-UX 11
+	* lib/hdb/hdb.h (HDB): add dbc for db3
+	* kdc/connect.c (add_standard_ports): also listen on krb524 aka
+	4444
+	* etc/services.append (krb524): add
+	* lib/hdb/db3.c: add berkeley db3 interface.  contributed by
+	Derrick J Brashear <shadow@dementia.org>
+	* lib/hdb/hdb.h (struct HDB): add
+
+2000-06-07  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/524.c: if 524 is not enabled, just generate error reply and
+	exit
+
+	* kdc/kerberos4.c: if v4 is not enabled, just generate error reply
+	and exit
+
+	* kdc/connect.c: only listen to port 4444 if 524 is enabled
+	
+	* kdc/config.c: add options to enable/disable v4 and 524 requests
+	
+2000-06-06  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kdc/524.c: handle non-existant server principals (from Daniel
+	Kouril)
+
+2000-06-03  Assar Westerlund  <assar@sics.se>
+
+	* admin/ktutil.c: print name when failing to open keytab
+
+	* kuser/kinit.c: try also to fallback to v4 when no KDC is found
+
+2000-05-28  Assar Westerlund  <assar@sics.se>
+
+	* kuser/klist.c: continue even we have no v5 ccache.  make showing
+	your krb4 tickets the default (if build with krb4 support)
+	* kuser/kinit.c: add a fallback that tries to get a v4 ticket if
+	built with krb4 support and we got back a version error from the
+	KDC
+
+2000-05-23  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/keytab_keyfile.c: make this actually work
+
+2000-05-19  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/store_emem.c (emem_store): make it write-compatible
+	* lib/krb5/store_fd.c (fd_store): make it write-compatible
+	* lib/krb5/store_mem.c (mem_store): make it write-compatible
+	* lib/krb5/krb5.h (krb5_storage): make store write-compatible
+
+2000-05-18  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: add stdio.h in dbopen test
+
+2000-05-16  Assar Westerlund  <assar@assaris.sics.se>
+
+	* Release 0.2t
+
+2000-05-16  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): set version to 11:1:0
+	* lib/krb5/fcache.c: fix second lseek
+	* lib/krb5/principal.c (krb5_524_conv_principal): fix typo
+
+2000-05-15  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2s
+
+2000-05-15  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am (libkrb5_la_LDFLAGS): set version to 11:0:0
+	* lib/hdb/Makefile.am (libhdb_la_LDFLAGS): set version to 4:2:1
+	* lib/asn1/Makefile.am (libasn1_la_LDFLAGS): bump to 2:0:0
+	* lib/krb5/principal.c (krb5_524_conv_principal): comment-ize, and
+	simplify string copying
+
+2000-05-12  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/fcache.c (scrub_file): new function
+	(erase_file): re-write, use scrub_file
+	* lib/krb5/krb5.h (KRB5_DEFAULT_CCFILE_ROOT): add
+
+	* configure.in (dbopen): add header files
+
+	* lib/krb5/krb5.h (krb5_key_usage): add some more
+	* lib/krb5/fcache.c (erase_file): try to detect symlink games.
+	also call revoke.
+	* lib/krb5/changepw.c (krb5_change_password): remember to close
+	the socket on error
+
+	* kdc/main.c (main): also call sigterm on SIGTERM
+
+2000-05-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/config_file.c (krb5_config_vget_string_default,
+ 	krb5_config_get_string_default): add
+
+2000-04-25  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/fcache.c (fcc_initialize): just forget about
+	over-writing the old cred cache.  it's too much of a hazzle trying
+	to do this safely.
+
+2000-04-11  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/crypto.c (krb5_get_wrapped_length): rewrite into
+	different parts for the derived and non-derived cases
+	* lib/krb5/crypto.c (krb5_get_wrapped_length): the padding should
+	be done after having added confounder and checksum
+
+2000-04-09  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/get_addrs.c (find_all_addresses): apperently solaris
+	can return EINVAL when the buffer is too small.  cope.
+	* lib/asn1/Makefile.am (gen_files): add asn1_UNSIGNED.x
+	* lib/asn1/gen_locl.h (filename): add prototype
+	(init_generate): const-ize
+	* lib/asn1/gen.c (filename): new function clean-up a little bit.
+	* lib/asn1/parse.y: be more tolerant in ranges
+	* lib/asn1/lex.l: count lines correctly.
+	(error_message): print filename in messages
+
+2000-04-08  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_safe.c (krb5_rd_safe): increment sequence number
+	after comparing
+	* lib/krb5/rd_priv.c (krb5_rd_priv): increment sequence number
+	after comparing
+	* lib/krb5/mk_safe.c (krb5_mk_safe): make `tmp_seq' unsigned
+	* lib/krb5/mk_priv.c (krb5_mk_priv): make `tmp_seq' unsigned
+	* lib/krb5/generate_seq_number.c (krb5_generate_seq_number): make
+	`seqno' be unsigned
+	* lib/krb5/mk_safe.c (krb5_mk_safe): increment local sequence
+	number after the fact and only increment it if we were successful
+	* lib/krb5/mk_priv.c (krb5_mk_priv): increment local sequence
+	number after the fact and only increment it if we were successful
+	* lib/krb5/krb5.h (krb5_auth_context_data): make sequence number
+	unsigned
+
+	* lib/krb5/init_creds_pw.c (krb5_get_init_creds_password):
+	`in_tkt_service' can be NULL
+
+2000-04-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/asn1/parse.y: regonize INTEGER (0..UNIT_MAX).
+	(DOTDOT): add
+	* lib/asn1/lex.l (DOTDOT): add
+	* lib/asn1/k5.asn1 (UNSIGNED): add.  use UNSIGNED for all sequence
+	numbers.
+	* lib/asn1/gen_length.c (length_type): add TUInteger
+	* lib/asn1/gen_free.c (free_type): add TUInteger
+	* lib/asn1/gen_encode.c (encode_type, generate_type_encode): add
+	TUInteger
+	* lib/asn1/gen_decode.c (decode_type, generate_type_decode): add
+	TUInteger
+	* lib/asn1/gen_copy.c (copy_type): add TUInteger
+	* lib/asn1/gen.c (define_asn1): add TUInteger
+	* lib/asn1/der_put.c (encode_unsigned): add
+	* lib/asn1/der_length.c (length_unsigned): add
+	* lib/asn1/der_get.c (decode_unsigned): add
+	* lib/asn1/der.h (decode_unsigned, encode_unsigned,
+	length_unsigned): add prototypes
+
+	* lib/asn1/k5.asn1: update pre-authentication types
+	* lib/krb5/krb5_err.et: add some error codes from pkinit
+
+2000-04-05  Assar Westerlund  <assar@sics.se>
+
+	* lib/hdb/hdb.c: add support for hdb methods (aka back-ends).
+	include ldap.
+	* lib/hdb/hdb-ldap.c: tweak the ifdef to OPENLDAP
+	* lib/hdb/Makefile.am: add hdb-ldap.c and openldap
+	* kdc/Makefile.am, kpasswd/Makefile.am, kadmin/Makefile.am: add
+	* configure.in: bump version to 0.2s-pre add options and testing
+	for (open)ldap
+
+2000-04-04  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (krb4): fix the krb_mk_req test
+
+2000-04-03  Assar Westerlund  <assar@sics.se>
+
+	* configure.in (krb4): add test for const arguments to krb_mk_req
+	* lib/45/mk_req.c (krb_mk_req): conditionalize const-ness of
+	arguments
+
+2000-04-03  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2r
+
+2000-04-03  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: set version to 10:0:0
+	* lib/45/mk_req.c (krb_mk_req): const-ize the arguments
+	
+2000-03-30  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (krb5_425_conv_principal_ext): add some
+	comments.  add fall-back on adding the realm name in lower case.
+
+2000-03-29  Assar Westerlund  <assar@sics.se>
+
+	* kdc/connect.c: remember to repoint all descr->sa to _ss after
+	realloc as this might have moved the memory around.  problem
+	discovered and diagnosed by Brandon S. Allbery
+
+2000-03-27  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: recognize solaris 2.8
+	* config.guess, config.sub: update to current version from
+	:pserver:anoncvs@subversions.gnu.org:/home/cvs
+
+	* lib/krb5/init_creds_pw.c (print_expire): do not assume anything
+	about the size of time_t, i.e. make it 64-bit happy
+
+2000-03-13  Assar Westerlund  <assar@sics.se>
+
+	* kuser/klist.c: add support for display v4 tickets
+
+2000-03-11  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kaserver.c (do_authenticate, do_getticket): call check_flags
+	* kdc/kerberos4.c (do_version4): call check_flags.
+	* kdc/kerberos5.c (check_flags): make global
+
+2000-03-10  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/init_creds_pw.c (krb5_get_init_creds_password): evil
+	hack to avoid recursion
+
+2000-03-04  Assar Westerlund  <assar@sics.se>
+
+	* kuser/kinit.c: add `krb4_get_tickets' per realm. add --anonymous
+	* lib/krb5/krb5.h (krb5_get_init_creds_opt): add `anonymous' and
+	KRB5_GET_INIT_CREDS_OPT_ANONYMOUS
+	* lib/krb5/init_creds_pw.c (get_init_creds_common): set
+	request_anonymous flag appropriatly
+	* lib/krb5/init_creds.c (krb5_get_init_creds_opt_set_anonymous):
+	add
+
+	* lib/krb5/get_in_tkt.c (_krb5_extract_ticket): new parameter to
+	determine whetever to ignore client name of not.  always copy
+	client name from kdc.  fix callers.
+
+	* kdc: add support for anonymous tickets
+
+	* kdc/string2key.8: add man-page for string2key
+
+2000-03-03  Assar Westerlund  <assar@sics.se>
+
+	* kdc/hpropd.c (dump_krb4): get expiration date from `valid_end'
+	and not `pw_end'
+
+	* kdc/kadb.h (ka_entry): fix name pw_end -> valid_end.  add some
+	more fields
+
+	* kdc/hprop.c (v4_prop): set the `valid_end' from the v4
+	expiration date instead of the `pw_expire'
+	(ka_convert): set `valid_end' from ka expiration data and `pw_expire'
+	from pw_change + pw_expire
+	(main): add a default database for ka dumping
+
+2000-02-28  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/context.c (init_context_from_config_file): change
+	rfc2052 default to no.  2782 says that underscore should be used.
+
+2000-02-24  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/fcache.c (fcc_initialize, fcc_store_cred): verify that
+	stores and close succeed
+	* lib/krb5/store.c (krb5_store_creds): check to see that the
+	stores are succesful.
+
+2000-02-23  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2q
+
+2000-02-22  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: set version to 9:2:0
+	
+	* lib/krb5/expand_hostname.c (krb5_expand_hostname_realms): copy
+	the correct hostname
+
+	* kdc/connect.c (add_new_tcp): use the correct entries in the
+	descriptor table
+	* kdc/connect.c: initialize `descr' uniformly and correctly
+
+2000-02-20  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2p
+
+2000-02-19  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: set version to 9:1:0
+	
+	* lib/krb5/expand_hostname.c (krb5_expand_hostname): make sure
+	that realms is filled in even when getaddrinfo fails or does not
+	return any canonical name
+
+	* kdc/connect.c (descr): add sockaddr and string representation
+	(*): re-write to use the above mentioned
+
+2000-02-16  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/addr_families.c (krb5_parse_address): use
+	krb5_sockaddr2address to copy the result from getaddrinfo.
+
+2000-02-14  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2o
+
+2000-02-13  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: set version to 9:0:0
+
+	* kdc/kaserver.c (do_authenticate): return the kvno of the server
+	and not the client.  Thanks to Brandon S. Allbery KF8NH
+	<allbery@kf8nh.apk.net> and Chaskiel M Grundman
+	<cg2v@andrew.cmu.edu> for debugging.
+
+	* kdc/kerberos4.c (do_version4): if an tgs-req is received with an
+	old kvno, return an error reply and write a message in the log.
+	
+2000-02-12  Assar Westerlund  <assar@sics.se>
+
+	* appl/test/gssapi_server.c (proto): with `--fork', create a child
+	and send over/receive creds with export/import_sec_context
+	* appl/test/gssapi_client.c (proto): with `--fork', create a child
+	and send over/receive creds with export/import_sec_context
+	* appl/test/common.c: add `--fork' / `-f' (only used by gssapi)
+
+2000-02-11  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kdc_locl.h: remove keyfile add explicit_addresses
+	* kdc/connect.c (init_sockets): pay attention to
+	explicit_addresses some more comments.  better error messages.
+	* kdc/config.c: add some comments.
+	remove --key-file.
+	add --addresses.
+
+	* lib/krb5/context.c (krb5_set_extra_addresses): const-ize and use
+	proper abstraction
+
+2000-02-07  Johan Danielsson  <joda@pdc.kth.se>
+
+	* lib/krb5/changepw.c: use roken_getaddrinfo_hostspec
+
+2000-02-07  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2n
+
+2000-02-07  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: set version to 8:0:0
+	* lib/krb5/keytab.c (krb5_kt_default_name): use strlcpy
+	(krb5_kt_add_entry): set timestamp
+
+2000-02-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/krb5.h: add macros for accessing krb5_realm
+	* lib/krb5/time.c (krb5_timeofday): use `krb5_timestamp' instead
+	of `int32_t'
+
+	* lib/krb5/replay.c (checksum_authenticator): update to new API
+	for md5
+
+	* lib/krb5/krb5.h: remove des.h, it's not needed and applications
+	should not have to make sure to find it.
+
+2000-02-03  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/rd_req.c (get_key_from_keytab): rename parameter to
+	`out_key' to avoid conflicting with label.  reported by Sean Doran
+	<smd@ebone.net>
+
+2000-02-02  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/expand_hostname.c: remember to lower-case host names.
+	bug reported by <amu@mit.edu>
+
+	* kdc/kerberos4.c (do_version4): look at check_ticket_addresses
+	and emulate that by setting krb_ignore_ip_address (not a great
+	interface but it doesn't seem like the time to go around fixing
+	libkrb stuff now)
+
+2000-02-01  Johan Danielsson  <joda@pdc.kth.se>
+
+	* kuser/kinit.c: change --noaddresses into --no-addresses
+
+2000-01-28  Assar Westerlund  <assar@sics.se>
+
+	* kpasswd/kpasswd.c (main): make sure the ticket is not
+	forwardable and not proxiable
+
+2000-01-26  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/crypto.c: update to pseudo-standard APIs for
+	md4,md5,sha.  some changes to libdes calls to make them more
+	portable.
+
+2000-01-21  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/verify_init.c (krb5_verify_init_creds): make sure to
+ 	clean up the correct creds.
+
+2000-01-16  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (append_component): change parameter to
+	`const char *'.  check malloc
+	* lib/krb5/principal.c (append_component, va_ext_princ, va_princ):
+	const-ize
+	* lib/krb5/mk_req.c (krb5_mk_req): make `service' and `hostname'
+	const
+	* lib/krb5/principal.c (replace_chars): also add space here
+	* lib/krb5/principal.c: (quotable_chars): add space
+
+2000-01-12  Assar Westerlund  <assar@sics.se>
+
+	* kdc/kerberos4.c (do_version4): check if preauth was required and
+	bail-out if so since there's no way that could be done in v4.
+	Return NULL_KEY as an error to the client (which is non-obvious,
+	but what can you do?)
+
+2000-01-09  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/principal.c (krb5_sname_to_principal): use
+	krb5_expand_hostname_realms
+	* lib/krb5/mk_req.c (krb5_km_req): use krb5_expand_hostname_realms
+	* lib/krb5/expand_hostname.c (krb5_expand_hostname_realms): new
+	variant of krb5_expand_hostname that tries until it expands into
+	something that's digestable by krb5_get_host_realm, returning also
+	the result from that function.
+
+2000-01-08  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2m
+
+2000-01-08  Assar Westerlund  <assar@sics.se>
+
+	* configure.in: replace AC_C_BIGENDIAN with KRB_C_BIGENDIAN
+
+	* lib/krb5/Makefile.am: bump version to 7:1:0
+
+	* lib/krb5/principal.c (krb5_sname_to_principal): use
+	krb5_expand_hostname
+	* lib/krb5/expand_hostname.c (krb5_expand_hostname): handle
+	ai_canonname being set in any of the addresses returnedby
+	getaddrinfo.  glibc apparently returns the reverse lookup of every
+	address in ai_canonname.
+
+2000-01-06  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2l
+
+2000-01-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/Makefile.am: set version to 7:0:0
+	* lib/krb5/principal.c (krb5_sname_to_principal): remove `hp'
+
+	* lib/hdb/Makefile.am: set version to 4:1:1
+
+	* kdc/hpropd.c (dump_krb4): use `krb5_get_default_realms'
+	* lib/krb5/get_in_tkt.c (add_padata): change types to make
+	everything work out
+	(krb5_get_in_cred): remove const to make types match
+	* lib/krb5/crypto.c (ARCFOUR_string_to_key): correct signature
+	* lib/krb5/principal.c (krb5_sname_to_principal): handle not
+	getting back a canonname
+
+2000-01-06  Assar Westerlund  <assar@sics.se>
+
+	* Release 0.2k
+
+2000-01-06  Assar Westerlund  <assar@sics.se>
+
+	* lib/krb5/send_to_kdc.c (krb5_sendto_kdc): advance colon so that
+	we actually parse the port number.  based on a patch from Leif
+	Johansson <leifj@it.su.se>
+
+2000-01-02  Assar Westerlund  <assar@sics.se>
+
+	* admin/purge.c: remove all non-current and old entries from a
+	keytab
+
+	* admin: break up ktutil.c into files
+
+	* admin/ktutil.c (list): support --verbose (also listning time
+	stamps)
+	(kt_add, kt_get): set timestamp in newly created entries
+	(kt_change): add `change' command
+
+	* admin/srvconvert.c (srvconv): set timestamp in newly created
+	entries
+	* lib/krb5/keytab_keyfile.c (akf_next_entry): set timetsamp,
+	always go the a predicatble position on error
+	* lib/krb5/keytab.c (krb5_kt_copy_entry_contents): copy timestamp
+	* lib/krb5/keytab_file.c (fkt_add_entry): store timestamp
+	(fkt_next_entry_int): return timestamp
+	* lib/krb5/krb5.h (krb5_keytab_entry): add timestamp
diff --git a/crypto/heimdal/README b/crypto/heimdal/README
new file mode 100644
index 000000000000..f27b67f912b5
--- /dev/null
+++ b/crypto/heimdal/README
@@ -0,0 +1,19 @@
+$Id: README,v 1.1 2000/07/27 02:33:54 assar Exp $
+
+Heimdal is a Kerberos 5 implementation.
+
+Please see the manual in doc, by default installed in
+/usr/heimdal/info/heimdal.info for information on how to install.
+There are also briefer man pages for most of the commands.
+
+Bug reports and bugs are appreciated, see more under Bug reports in
+the manual on how we prefer them.
+
+For more information see the web-page at
+<http://www.pdc.kth.se/heimdal/> or the mailing lists:
+
+heimdal-announce@sics.se	low-volume announcement
+heimdal-discuss@sics.se		high-volume discussion
+
+send a mail to heimdal-announce-request@sics.se and
+heimdal-discuss-request@sics.se respectively to subscribe.
diff --git a/crypto/heimdal/appl/kf/kf.1 b/crypto/heimdal/appl/kf/kf.1
new file mode 100644
index 000000000000..27ca59f54e6f
--- /dev/null
+++ b/crypto/heimdal/appl/kf/kf.1
@@ -0,0 +1,92 @@
+.\" Things to fix:
+.\"   * correct section, and operating system
+.\"   * remove Op from mandatory flags
+.\"   * use better macros for arguments (like .Pa for files)
+.\"
+.Dd July  2, 2000
+.Dt KF 1
+.Os Heimdal
+.Sh NAME
+.Nm kf
+.Nd
+securly forward tickets
+.Sh SYNOPSIS
+.Nm
+.Oo Fl p Ar port \*(Ba Xo
+.Fl -port= Ns Ar port Oc
+.Xc
+.Oo Fl l Ar login \*(Ba Xo
+.Fl -login= Ns Ar login Oc
+.Xc
+.Oo Fl c Ar ccache \*(Ba Xo
+.Fl -ccache= Ns Ar ccache Oc
+.Xc
+.Op Fl F | Fl -forwardable
+.Op Fl G | Fl -no-forwardable
+.Op Fl h | Fl -help
+.Op Fl -version
+.Ar host ...
+.Sh DESCRIPTION
+The
+.Nm
+program forwards tickets to a remove host through an authenticated
+and encrypted stream. Options supported are:
+.Bl -tag -width Ds
+.It Xo
+.Fl p Ar port Ns ,
+.Fl -port= Ns Ar port
+.Xc
+port to connect to
+.It Xo
+.Fl l Ar login Ns ,
+.Fl -login= Ns Ar login
+.Xc
+remote login name
+.It Xo
+.Fl c Ar ccache Ns ,
+.Fl -ccache= Ns Ar ccache
+.Xc
+remote cred cache
+.It Xo
+.Fl F Ns ,
+.Fl -forwardable
+.Xc
+forward forwardable credentials
+.It Xo
+.Fl G Ns ,
+.Fl -no-forwardable
+.Xc
+do not forward forwardable credentials
+.It Xo
+.Fl h Ns ,
+.Fl -help
+.Xc
+.It Xo
+.Fl -version
+.Xc
+.El
+.Pp
+.Nm
+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.
+.Pp
+In order for
+.Nm
+to work you will need to acquire your initial ticket with forwardable
+flag, ie
+.Nm kinit Fl -forwardable .
+.Pp
+.Nm telnet
+is able to forward ticket by itself.
+.\".Sh ENVIRONMENT
+.\".Sh FILES
+.\".Sh EXAMPLES
+.\".Sh DIAGNOSTICS
+.Sh SEE ALSO
+.Xr kfd 8 ,
+.Xr kinit 1 ,
+.Xr telnet 1
+.\".Sh STANDARDS
+.\".Sh HISTORY
+.\".Sh AUTHORS
+.\".Sh BUGS
diff --git a/crypto/heimdal/appl/kf/kfd.8 b/crypto/heimdal/appl/kf/kfd.8
new file mode 100644
index 000000000000..3fca73bc9cd4
--- /dev/null
+++ b/crypto/heimdal/appl/kf/kfd.8
@@ -0,0 +1,59 @@
+.\" Things to fix:
+.\"   * correct section, and operating system
+.\"   * remove Op from mandatory flags
+.\"   * use better macros for arguments (like .Pa for files)
+.\"
+.Dd July  2, 2000
+.Dt KFD 8
+.Os Heimdal
+.Sh NAME
+.Nm kfd
+.Nd
+receive forwarded tickets
+.Sh SYNOPSIS
+.Nm
+.Oo Fl p Ar port \*(Ba Xo
+.Fl -port= Ns Ar port Oc
+.Xc
+.Op Fl i | Fl -inetd
+.Oo Fl R Ar regpag \*(Ba Xo
+.Fl -regpag= Ns Ar regpag Oc
+.Xc
+.Op Fl h | Fl -help
+.Op Fl -version
+.Sh DESCRIPTION
+This is the daemon for
+.Nm kf .
+Supported options:
+.Bl -tag -width Ds
+.It Xo
+.Fl p Ar port Ns ,
+.Fl -port= Ns Ar port
+.Xc
+port to listen to
+.It Xo
+.Fl i Ns ,
+.Fl -inetd
+.Xc
+not started from inetd
+.It Xo
+.Fl R Ar regpag Ns ,
+.Fl -regpag= Ns Ar regpag
+.Xc
+path to regpag binary
+.El
+.\".Sh ENVIRONMENT
+.\".Sh FILES
+.Sh EXAMPLES
+Put the following in
+.Pa /etc/inetd.conf :
+.Bd -literal
+kf	stream	tcp	nowait	root	/usr/heimdal/libexec/kfd	kfd
+.Ed
+.\".Sh DIAGNOSTICS
+.Sh SEE ALSO
+.Xr kf 1
+.\".Sh STANDARDS
+.\".Sh HISTORY
+.\".Sh AUTHORS
+.\".Sh BUGS
diff --git a/crypto/heimdal/appl/login/env.c b/crypto/heimdal/appl/login/env.c
new file mode 100644
index 000000000000..57f68b1c9a6c
--- /dev/null
+++ b/crypto/heimdal/appl/login/env.c
@@ -0,0 +1,98 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include "login_locl.h"
+RCSID("$Id: env.c,v 1.1 2000/06/28 12:27:38 joda Exp $");
+
+/*
+ * the environment we will send to execle and the shell.
+ */
+
+char **env;
+int num_env;
+
+void
+extend_env(char *str)
+{
+    env = realloc(env, (num_env + 1) * sizeof(*env));
+    if(env == NULL)
+	errx(1, "Out of memory!");
+    env[num_env++] = str;
+}
+
+void
+add_env(const char *var, const char *value)
+{
+    int i;
+    char *str;
+    asprintf(&str, "%s=%s", var, value);
+    if(str == NULL)
+	errx(1, "Out of memory!");
+    for(i = 0; i < num_env; i++)
+	if(strncmp(env[i], var, strlen(var)) == 0 && 
+	   env[i][strlen(var)] == '='){
+	    free(env[i]);
+	    env[i] = str;
+	    return;
+	}
+    
+    extend_env(str);
+}
+
+void
+copy_env(void)
+{
+    char **p;
+    for(p = environ; *p; p++)
+	extend_env(*p);
+}
+
+int
+login_read_env(const char *file)
+{
+    char **newenv;
+    char *p;
+    int i, j;
+    
+    newenv = NULL;
+    i = read_environment(file, &newenv);
+    for (j = 0; j < i; j++) {
+	p = strchr(newenv[j], '=');
+	*p++ = 0;
+	add_env(newenv[j], p);
+	*--p = '=';
+	free(newenv[j]);
+    }
+    free(newenv);
+    return 0;
+}
diff --git a/crypto/heimdal/appl/push/pfrom.1 b/crypto/heimdal/appl/push/pfrom.1
new file mode 100644
index 000000000000..c04d1116c19e
--- /dev/null
+++ b/crypto/heimdal/appl/push/pfrom.1
@@ -0,0 +1,25 @@
+.\" $Id: pfrom.1,v 1.2 2000/11/29 18:26:27 joda Exp $
+.\"
+.Dd Mars 4, 2000
+.Dt PFROM 1
+.Os HEIMDAL
+.Sh NAME
+.Nm pfrom
+.Nd
+fetch a list of the current mail via POP
+.Sh SYNOPSIS
+.Nm
+.Op Fl 4 | Fl -krb4
+.Op Fl 5 | Fl -krb5
+.Op Fl v | Fl -verbose
+.Op Fl c | -count
+.Op Fl -header
+.Oo Fl p Ar port-spec  \*(Ba Xo
+.Fl -port= Ns Ar port-spec
+.Xc
+.Oc
+.Sh DESCRIPTION
+.Nm
+is a script that does push --from.
+.Sh SEE ALSO
+.Xr push 8
diff --git a/crypto/heimdal/appl/rcp/ChangeLog b/crypto/heimdal/appl/rcp/ChangeLog
new file mode 100644
index 000000000000..06850618f1e2
--- /dev/null
+++ b/crypto/heimdal/appl/rcp/ChangeLog
@@ -0,0 +1,29 @@
+2001-01-29  Assar Westerlund  <assar@sics.se>
+
+	* util.c (roundup): add fallback definition
+
+	* rcp.c: remove non-STDC code
+	* rcp_locl.h: add sys/types.h and sys/wait.h
+
+	* rcp.c: no calls to err with NULL
+
+2001-01-28  Assar Westerlund  <assar@sics.se>
+
+	* rcp_locl.h: add
+
+	* Makefile.am (LDADD): remove unused libraries
+
+2001-01-27  Assar Westerlund  <assar@sics.se>
+
+	* util.c: replace vfork by fork
+
+	* rcp.c: add RCSID S_ISTXT -> S_ISVTX printf sizes of files with
+ 	%lu instead of %q (which is not portable)
+
+	* util.c: add RCSID do not use sig_t
+	* rcp.c: remove __P, use st_mtime et al from struct stat
+	* extern.h: remove __P
+
+	* initial import of port of bsd rcp changed to use existing rsh,
+	contributed by Richard Nyberg <rnyberg@it.su.se>
+
diff --git a/crypto/heimdal/appl/rcp/Makefile.am b/crypto/heimdal/appl/rcp/Makefile.am
new file mode 100644
index 000000000000..4ecf7a63b0f6
--- /dev/null
+++ b/crypto/heimdal/appl/rcp/Makefile.am
@@ -0,0 +1,11 @@
+# $Id: Makefile.am,v 1.2 2001/01/28 22:50:35 assar Exp $
+
+include $(top_srcdir)/Makefile.am.common
+
+INCLUDES += $(INCLUDE_krb4)
+
+bin_PROGRAMS = rcp
+
+rcp_SOURCES  = rcp.c util.c
+
+LDADD = $(LIB_roken)
diff --git a/crypto/heimdal/appl/rcp/Makefile.in b/crypto/heimdal/appl/rcp/Makefile.in
new file mode 100644
index 000000000000..f0ee15107a76
--- /dev/null
+++ b/crypto/heimdal/appl/rcp/Makefile.in
@@ -0,0 +1,559 @@
+# Makefile.in generated automatically by automake 1.4a from Makefile.am
+
+# Copyright (C) 1994, 1995-9, 2000 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.
+
+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
+
+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@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_FLAG =
+transform = @program_transform_name@
+
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+
+@SET_MAKE@
+host_alias = @host_alias@
+host_triplet = @host@
+AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
+AMDEP = @AMDEP@
+AMTAR = @AMTAR@
+AS = @AS@
+AWK = @AWK@
+CANONICAL_HOST = @CANONICAL_HOST@
+CATMAN = @CATMAN@
+CATMANEXT = @CATMANEXT@
+CC = @CC@
+CPP = @CPP@
+CXX = @CXX@
+CXXCPP = @CXXCPP@
+DBLIB = @DBLIB@
+DEPDIR = @DEPDIR@
+DIR_des = @DIR_des@
+DIR_roken = @DIR_roken@
+DLLTOOL = @DLLTOOL@
+EXEEXT = @EXEEXT@
+EXTRA_LIB45 = @EXTRA_LIB45@
+GROFF = @GROFF@
+INCLUDES_roken = @INCLUDES_roken@
+INCLUDE_ = @INCLUDE_@
+LEX = @LEX@
+LIBOBJS = @LIBOBJS@
+LIBTOOL = @LIBTOOL@
+LIB_ = @LIB_@
+LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
+LIB_des = @LIB_des@
+LIB_des_appl = @LIB_des_appl@
+LIB_kdb = @LIB_kdb@
+LIB_otp = @LIB_otp@
+LIB_roken = @LIB_roken@
+LIB_security = @LIB_security@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAKEINFO = @MAKEINFO@
+NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@
+NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@
+NROFF = @NROFF@
+OBJDUMP = @OBJDUMP@
+OBJEXT = @OBJEXT@
+PACKAGE = @PACKAGE@
+RANLIB = @RANLIB@
+STRIP = @STRIP@
+VERSION = @VERSION@
+VOID_RETSIGTYPE = @VOID_RETSIGTYPE@
+WFLAGS = @WFLAGS@
+WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
+WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
+YACC = @YACC@
+dpagaix_CFLAGS = @dpagaix_CFLAGS@
+dpagaix_LDADD = @dpagaix_LDADD@
+install_sh = @install_sh@
+
+# $Id: Makefile.am,v 1.2 2001/01/28 22:50:35 assar Exp $
+
+
+# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $
+
+
+# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $
+
+
+AUTOMAKE_OPTIONS = foreign no-dependencies
+
+SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x
+
+INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken) $(INCLUDE_krb4)
+
+AM_CFLAGS =  $(WFLAGS)
+
+CP = cp
+
+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_pidfile = @LIB_pidfile@
+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@
+
+LIBS = @LIBS@
+
+HESIODLIB = @HESIODLIB@
+HESIODINCLUDE = @HESIODINCLUDE@
+INCLUDE_hesiod = @INCLUDE_hesiod@
+LIB_hesiod = @LIB_hesiod@
+
+INCLUDE_krb4 = @INCLUDE_krb4@
+LIB_krb4 = @LIB_krb4@
+
+INCLUDE_openldap = @INCLUDE_openldap@
+LIB_openldap = @LIB_openldap@
+
+INCLUDE_readline = @INCLUDE_readline@
+
+LEXLIB = @LEXLIB@
+
+NROFF_MAN = groff -mandoc -Tascii
+
+@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
+
+@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
+@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
+@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la
+
+CHECK_LOCAL = $(PROGRAMS)
+
+bin_PROGRAMS = rcp
+
+rcp_SOURCES = rcp.c util.c
+
+LDADD = $(LIB_roken)
+subdir = appl/rcp
+mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
+CONFIG_HEADER = ../../include/config.h
+CONFIG_CLEAN_FILES = 
+bin_PROGRAMS =  rcp$(EXEEXT)
+PROGRAMS =  $(bin_PROGRAMS)
+
+
+DEFS = @DEFS@ -I. -I$(srcdir) -I../../include
+CPPFLAGS = @CPPFLAGS@
+LDFLAGS = @LDFLAGS@
+X_CFLAGS = @X_CFLAGS@
+X_LIBS = @X_LIBS@
+X_EXTRA_LIBS = @X_EXTRA_LIBS@
+X_PRE_LIBS = @X_PRE_LIBS@
+am_rcp_OBJECTS =  rcp.$(OBJEXT) util.$(OBJEXT)
+rcp_OBJECTS =  $(am_rcp_OBJECTS)
+rcp_LDADD = $(LDADD)
+rcp_DEPENDENCIES = 
+rcp_LDFLAGS = 
+COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+CFLAGS = @CFLAGS@
+CCLD = $(CC)
+LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
+DIST_SOURCES =  $(rcp_SOURCES)
+depcomp = 
+DIST_COMMON =  ChangeLog Makefile.am Makefile.in
+
+
+DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
+
+GZIP_ENV = --best
+SOURCES = $(rcp_SOURCES)
+OBJECTS = $(am_rcp_OBJECTS)
+
+all: all-redirect
+.SUFFIXES:
+.SUFFIXES: .1 .3 .5 .8 .c .cat1 .cat3 .cat5 .cat8 .et .h .lo .o .obj .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/rcp/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 \
+	    f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \
+	    echo " $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f"; \
+	    $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f; \
+	  else :; fi; \
+	done
+
+uninstall-binPROGRAMS:
+	@$(NORMAL_UNINSTALL)
+	@list='$(bin_PROGRAMS)'; for p in $$list; do \
+	  f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \
+	  echo " rm -f $(DESTDIR)$(bindir)/$$f"; \
+	  rm -f $(DESTDIR)$(bindir)/$$f; \
+	done
+
+mostlyclean-compile:
+	-rm -f *.o core *.core
+	-rm -f *.$(OBJEXT)
+
+clean-compile:
+
+distclean-compile:
+	-rm -f *.tab.c
+
+maintainer-clean-compile:
+
+mostlyclean-libtool:
+	-rm -f *.lo
+
+clean-libtool:
+	-rm -rf .libs _libs
+
+distclean-libtool:
+
+maintainer-clean-libtool:
+
+rcp$(EXEEXT): $(rcp_OBJECTS) $(rcp_DEPENDENCIES)
+	@rm -f rcp$(EXEEXT)
+	$(LINK) $(rcp_LDFLAGS) $(rcp_OBJECTS) $(rcp_LDADD) $(LIBS)
+.c.o:
+	$(COMPILE) -c $<
+.c.obj:
+	$(COMPILE) -c `cygpath -w $<`
+.c.lo:
+	$(LTCOMPILE) -c -o $@ $<
+
+tags: TAGS
+
+ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
+	list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \
+	unique=`for i in $$list; do \
+	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+	  done | \
+	  $(AWK) '    { files[$$0] = 1; } \
+	       END { for (i in files) print i; }'`; \
+	mkid -fID $$unique $(LISP)
+
+TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
+		$(TAGS_FILES) $(LISP)
+	tags=; \
+	here=`pwd`; \
+	list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \
+	unique=`for i in $$list; do \
+	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+	  done | \
+	  $(AWK) '    { files[$$0] = 1; } \
+	       END { for (i in files) print i; }'`; \
+	test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
+	  || etags $(ETAGS_ARGS) $$tags  $$unique $(LISP)
+
+mostlyclean-tags:
+
+clean-tags:
+
+distclean-tags:
+	-rm -f TAGS ID
+
+maintainer-clean-tags:
+
+distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
+
+distdir: $(DISTFILES)
+	@for file in $(DISTFILES); do \
+	  d=$(srcdir); \
+	  if test -d $$d/$$file; then \
+	    cp -pR $$d/$$file $(distdir) \
+	    || exit 1; \
+	  else \
+	    test -f $(distdir)/$$file \
+	    || cp -p $$d/$$file $(distdir)/$$file \
+	    || exit 1; \
+	  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
+	@$(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: uninstall-am
+all-am: Makefile $(PROGRAMS) all-local
+all-redirect: all-am
+install-strip:
+	$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
+installdirs:
+	$(mkinstalldirs)  $(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:
+	-rm -f Makefile.in
+mostlyclean-am:  mostlyclean-binPROGRAMS mostlyclean-compile \
+		mostlyclean-libtool mostlyclean-tags \
+		mostlyclean-generic
+
+mostlyclean: mostlyclean-am
+
+clean-am:  clean-binPROGRAMS clean-compile clean-libtool clean-tags \
+		clean-generic mostlyclean-am
+
+clean: clean-am
+
+distclean-am:  distclean-binPROGRAMS distclean-compile distclean-libtool \
+		distclean-tags distclean-generic clean-am
+	-rm -f libtool
+
+distclean: distclean-am
+
+maintainer-clean-am:  maintainer-clean-binPROGRAMS \
+		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-compile distclean-compile clean-compile \
+maintainer-clean-compile mostlyclean-libtool distclean-libtool \
+clean-libtool maintainer-clean-libtool 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-am install-exec install-data-local install-data-am \
+install-data install-am install uninstall-am uninstall all-local \
+all-redirect all-am all install-strip 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 \
+	echo "*"; \
+	echo "* Failed to install $$x setuid root"; \
+	echo "*"; \
+	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-cat-mans:
+	$(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_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
+
+# 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/rcp/extern.h b/crypto/heimdal/appl/rcp/extern.h
new file mode 100644
index 000000000000..a98456d305e2
--- /dev/null
+++ b/crypto/heimdal/appl/rcp/extern.h
@@ -0,0 +1,51 @@
+/*-
+ * 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.
+ *
+ *	@(#)extern.h	8.1 (Berkeley) 5/31/93
+ * $FreeBSD$
+ */
+
+typedef struct {
+	int cnt;
+	char *buf;
+} BUF;
+
+extern int iamremote;
+
+BUF	*allocbuf (BUF *, int, int);
+char	*colon (char *);
+void	 lostconn (int);
+void	 nospace (void);
+int	 okname (char *);
+void	 run_err (const char *, ...);
+int	 susystem (char *, int);
+void	 verifydir (char *);
diff --git a/crypto/heimdal/appl/rcp/rcp.c b/crypto/heimdal/appl/rcp/rcp.c
new file mode 100644
index 000000000000..1c532ad8e500
--- /dev/null
+++ b/crypto/heimdal/appl/rcp/rcp.c
@@ -0,0 +1,807 @@
+/*
+ * Copyright (c) 1983, 1990, 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.
+ */
+
+#include "rcp_locl.h"
+
+#define RSH_PROGRAM "rsh"
+#define	OPTIONS "5dfKpP:rtxz"
+
+struct  passwd *pwd;
+uid_t	userid;
+int     errs, remin, remout;
+int     pflag, iamremote, iamrecursive, targetshouldbedirectory;
+int     doencrypt, noencrypt;
+int     usebroken, usekrb5;
+char    *port;
+
+#define	CMDNEEDS	64
+char cmd[CMDNEEDS];		/* must hold "rcp -r -p -d\0" */
+
+int	 response (void);
+void	 rsource (char *, struct stat *);
+void	 sink (int, char *[]);
+void	 source (int, char *[]);
+void	 tolocal (int, char *[]);
+void	 toremote (char *, int, char *[]);
+void	 usage (void);
+
+int      do_cmd(char *host, char *remuser, char *cmd, int *fdin, int *fdout);
+
+int
+main(argc, argv)
+	int argc;
+	char *argv[];
+{
+	int ch, fflag, tflag;
+	char *targ;
+
+	fflag = tflag = 0;
+	while ((ch = getopt(argc, argv, OPTIONS)) != -1)
+		switch(ch) {			/* User-visible flags. */
+		case '5':
+			usekrb5 = 1;
+			break;
+		case 'K':
+			usebroken = 1;
+			break;
+		case 'P':
+			port = optarg;
+			break;			
+		case 'p':
+			pflag = 1;
+			break;
+		case 'r':
+			iamrecursive = 1;
+			break;
+		case 'x':
+			doencrypt = 1;
+			break;			
+		case 'z':
+			noencrypt = 1;
+			break;
+						/* Server options. */
+		case 'd':
+			targetshouldbedirectory = 1;
+			break;
+		case 'f':			/* "from" */
+			iamremote = 1;
+			fflag = 1;
+			break;
+		case 't':			/* "to" */
+			iamremote = 1;
+			tflag = 1;
+			break;
+		case '?':
+		default:
+			usage();
+		}
+	argc -= optind;
+	argv += optind;
+
+	if ((pwd = getpwuid(userid = getuid())) == NULL)
+		errx(1, "unknown user %d", (int)userid);
+
+	remin = STDIN_FILENO;		/* XXX */
+	remout = STDOUT_FILENO;
+
+	if (fflag) {			/* Follow "protocol", send data. */
+		(void)response();
+		(void)setuid(userid);
+		source(argc, argv);
+		exit(errs);
+	}
+
+	if (tflag) {			/* Receive data. */
+		(void)setuid(userid);
+		sink(argc, argv);
+		exit(errs);
+	}
+
+	if (argc < 2)
+		usage();
+	if (argc > 2)
+		targetshouldbedirectory = 1;
+
+	remin = remout = -1;
+	/* Command to be executed on remote system using "rsh". */
+	(void) sprintf(cmd, "rcp%s%s%s", iamrecursive ? " -r" : "", 
+		       pflag ? " -p" : "", targetshouldbedirectory ? " -d" : "");
+
+	(void)signal(SIGPIPE, lostconn);
+
+	if ((targ = colon(argv[argc - 1])))	/* Dest is remote host. */
+		toremote(targ, argc, argv);
+	else {
+		tolocal(argc, argv);		/* Dest is local host. */
+		if (targetshouldbedirectory)
+			verifydir(argv[argc - 1]);
+	}
+	exit(errs);
+}
+
+void
+toremote(targ, argc, argv)
+	char *targ, *argv[];
+	int argc;
+{
+	int i, len;
+	char *bp, *host, *src, *suser, *thost, *tuser;
+
+	*targ++ = 0;
+	if (*targ == 0)
+		targ = ".";
+
+	if ((thost = strchr(argv[argc - 1], '@'))) {
+		/* user@host */
+		*thost++ = 0;
+		tuser = argv[argc - 1];
+		if (*tuser == '\0')
+			tuser = NULL;
+		else if (!okname(tuser))
+			exit(1);
+	} else {
+		thost = argv[argc - 1];
+		tuser = NULL;
+	}
+
+	for (i = 0; i < argc - 1; i++) {
+		src = colon(argv[i]);
+		if (src) {			/* remote to remote */
+			*src++ = 0;
+			if (*src == 0)
+				src = ".";
+			host = strchr(argv[i], '@');
+			len = strlen(_PATH_RSH) + strlen(argv[i]) +
+			    strlen(src) + (tuser ? strlen(tuser) : 0) +
+			    strlen(thost) + strlen(targ) + CMDNEEDS + 20;
+			if (!(bp = malloc(len)))
+				err(1, "malloc");
+			if (host) {
+				*host++ = 0;
+				suser = argv[i];
+				if (*suser == '\0')
+					suser = pwd->pw_name;
+				else if (!okname(suser))
+					continue;
+				(void)snprintf(bp, len,
+				    "%s %s -l %s -n %s %s '%s%s%s:%s'",
+				    _PATH_RSH, host, suser, cmd, src,
+				    tuser ? tuser : "", tuser ? "@" : "",
+				    thost, targ);
+			} else
+				(void)snprintf(bp, len,
+				    "exec %s %s -n %s %s '%s%s%s:%s'",
+				    _PATH_RSH, argv[i], cmd, src,
+				    tuser ? tuser : "", tuser ? "@" : "",
+				    thost, targ);
+			(void)susystem(bp, userid);
+			(void)free(bp);
+		} else {			/* local to remote */
+			if (remin == -1) {
+				len = strlen(targ) + CMDNEEDS + 20;
+				if (!(bp = malloc(len)))
+					err(1, "malloc");
+				(void)snprintf(bp, len, "%s -t %s", cmd, targ);
+				host = thost;
+
+				if (do_cmd(host, tuser, bp, &remin, &remout) < 0)
+					exit(1);
+
+				if (response() < 0)
+					exit(1);
+				(void)free(bp);
+				(void)setuid(userid);
+			}
+			source(1, argv+i);
+		}
+	}
+}
+
+void
+tolocal(argc, argv)
+	int argc;
+	char *argv[];
+{
+	int i, len;
+	char *bp, *host, *src, *suser;
+
+	for (i = 0; i < argc - 1; i++) {
+		if (!(src = colon(argv[i]))) {		/* Local to local. */
+			len = strlen(_PATH_CP) + strlen(argv[i]) +
+			    strlen(argv[argc - 1]) + 20;
+			if (!(bp = malloc(len)))
+				err(1, "malloc");
+			(void)snprintf(bp, len, "exec %s%s%s %s %s", _PATH_CP,
+			    iamrecursive ? " -PR" : "", pflag ? " -p" : "",
+			    argv[i], argv[argc - 1]);
+			if (susystem(bp, userid))
+				++errs;
+			(void)free(bp);
+			continue;
+		}
+		*src++ = 0;
+		if (*src == 0)
+			src = ".";
+		if ((host = strchr(argv[i], '@')) == NULL) {
+			host = argv[i];
+			suser = pwd->pw_name;
+		} else {
+			*host++ = 0;
+			suser = argv[i];
+			if (*suser == '\0')
+				suser = pwd->pw_name;
+			else if (!okname(suser))
+				continue;
+		}
+		len = strlen(src) + CMDNEEDS + 20;
+		if ((bp = malloc(len)) == NULL)
+			err(1, "malloc");
+		(void)snprintf(bp, len, "%s -f %s", cmd, src);
+		if (do_cmd(host, suser, bp, &remin, &remout) < 0) {
+			(void)free(bp);
+			++errs;
+			continue;
+		}
+		(void)free(bp);
+		sink(1, argv + argc - 1);
+		(void)seteuid(0);
+		(void)close(remin);
+		remin = remout = -1;
+	}
+}
+
+void
+source(argc, argv)
+	int argc;
+	char *argv[];
+{
+	struct stat stb;
+	static BUF buffer;
+	BUF *bp;
+	off_t i;
+	int amt, fd, haderr, indx, result;
+	char *last, *name, buf[BUFSIZ];
+
+	for (indx = 0; indx < argc; ++indx) {
+                name = argv[indx];
+		if ((fd = open(name, O_RDONLY, 0)) < 0)
+			goto syserr;
+		if (fstat(fd, &stb)) {
+syserr:			run_err("%s: %s", name, strerror(errno));
+			goto next;
+		}
+		switch (stb.st_mode & S_IFMT) {
+		case S_IFREG:
+			break;
+		case S_IFDIR:
+			if (iamrecursive) {
+				rsource(name, &stb);
+				goto next;
+			}
+			/* FALLTHROUGH */
+		default:
+			run_err("%s: not a regular file", name);
+			goto next;
+		}
+		if ((last = strrchr(name, '/')) == NULL)
+			last = name;
+		else
+			++last;
+		if (pflag) {
+			/*
+			 * Make it compatible with possible future
+			 * versions expecting microseconds.
+			 */
+			(void)snprintf(buf, sizeof(buf), "T%ld 0 %ld 0\n",
+			    (long)stb.st_mtime,
+			    (long)stb.st_atime);
+			(void)write(remout, buf, strlen(buf));
+			if (response() < 0)
+				goto next;
+		}
+#define	MODEMASK	(S_ISUID|S_ISGID|S_ISVTX|S_IRWXU|S_IRWXG|S_IRWXO)
+		(void)snprintf(buf, sizeof(buf), "C%04o %lu %s\n",
+		    stb.st_mode & MODEMASK, (unsigned long)stb.st_size, last);
+		(void)write(remout, buf, strlen(buf));
+		if (response() < 0)
+			goto next;
+		if ((bp = allocbuf(&buffer, fd, BUFSIZ)) == NULL) {
+next:			(void)close(fd);
+			continue;
+		}
+
+		/* Keep writing after an error so that we stay sync'd up. */
+		for (haderr = i = 0; i < stb.st_size; i += bp->cnt) {
+			amt = bp->cnt;
+			if (i + amt > stb.st_size)
+				amt = stb.st_size - i;
+			if (!haderr) {
+				result = read(fd, bp->buf, amt);
+				if (result != amt)
+					haderr = result >= 0 ? EIO : errno;
+			}
+			if (haderr)
+				(void)write(remout, bp->buf, amt);
+			else {
+				result = write(remout, bp->buf, amt);
+				if (result != amt)
+					haderr = result >= 0 ? EIO : errno;
+			}
+		}
+		if (close(fd) && !haderr)
+			haderr = errno;
+		if (!haderr)
+			(void)write(remout, "", 1);
+		else
+			run_err("%s: %s", name, strerror(haderr));
+		(void)response();
+	}
+}
+
+void
+rsource(name, statp)
+	char *name;
+	struct stat *statp;
+{
+	DIR *dirp;
+	struct dirent *dp;
+	char *last, *vect[1], path[MAXPATHLEN];
+
+	if (!(dirp = opendir(name))) {
+		run_err("%s: %s", name, strerror(errno));
+		return;
+	}
+	last = strrchr(name, '/');
+	if (last == 0)
+		last = name;
+	else
+		last++;
+	if (pflag) {
+		(void)snprintf(path, sizeof(path), "T%ld 0 %ld 0\n",
+		    (long)statp->st_mtime,
+		    (long)statp->st_atime);
+		(void)write(remout, path, strlen(path));
+		if (response() < 0) {
+			closedir(dirp);
+			return;
+		}
+	}
+	(void)snprintf(path, sizeof(path),
+	    "D%04o %d %s\n", statp->st_mode & MODEMASK, 0, last);
+	(void)write(remout, path, strlen(path));
+	if (response() < 0) {
+		closedir(dirp);
+		return;
+	}
+	while ((dp = readdir(dirp))) {
+		if (dp->d_ino == 0)
+			continue;
+		if (!strcmp(dp->d_name, ".") || !strcmp(dp->d_name, ".."))
+			continue;
+		if (strlen(name) + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) {
+			run_err("%s/%s: name too long", name, dp->d_name);
+			continue;
+		}
+		(void)snprintf(path, sizeof(path), "%s/%s", name, dp->d_name);
+		vect[0] = path;
+		source(1, vect);
+	}
+	(void)closedir(dirp);
+	(void)write(remout, "E\n", 2);
+	(void)response();
+}
+
+void
+sink(argc, argv)
+	int argc;
+	char *argv[];
+{
+	static BUF buffer;
+	struct stat stb;
+	struct timeval tv[2];
+	enum { YES, NO, DISPLAYED } wrerr;
+	BUF *bp;
+	off_t i, j, size;
+	int amt, count, exists, first, mask, mode, ofd, omode;
+	int setimes, targisdir, wrerrno = 0;
+	char ch, *cp, *np, *targ, *why, *vect[1], buf[BUFSIZ];
+
+#define	atime	tv[0]
+#define	mtime	tv[1]
+#define	SCREWUP(str)	{ why = str; goto screwup; }
+
+	setimes = targisdir = 0;
+	mask = umask(0);
+	if (!pflag)
+		(void)umask(mask);
+	if (argc != 1) {
+		run_err("ambiguous target");
+		exit(1);
+	}
+	targ = *argv;
+	if (targetshouldbedirectory)
+		verifydir(targ);
+	(void)write(remout, "", 1);
+	if (stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode))
+		targisdir = 1;
+	for (first = 1;; first = 0) {
+		cp = buf;
+		if (read(remin, cp, 1) <= 0)
+			return;
+		if (*cp++ == '\n')
+			SCREWUP("unexpected <newline>");
+		do {
+			if (read(remin, &ch, sizeof(ch)) != sizeof(ch))
+				SCREWUP("lost connection");
+			*cp++ = ch;
+		} while (cp < &buf[BUFSIZ - 1] && ch != '\n');
+		*cp = 0;
+
+		if (buf[0] == '\01' || buf[0] == '\02') {
+			if (iamremote == 0)
+				(void)write(STDERR_FILENO,
+				    buf + 1, strlen(buf + 1));
+			if (buf[0] == '\02')
+				exit(1);
+			++errs;
+			continue;
+		}
+		if (buf[0] == 'E') {
+			(void)write(remout, "", 1);
+			return;
+		}
+
+		if (ch == '\n')
+			*--cp = 0;
+
+		cp = buf;
+		if (*cp == 'T') {
+			setimes++;
+			cp++;
+			mtime.tv_sec = strtol(cp, &cp, 10);
+			if (!cp || *cp++ != ' ')
+				SCREWUP("mtime.sec not delimited");
+			mtime.tv_usec = strtol(cp, &cp, 10);
+			if (!cp || *cp++ != ' ')
+				SCREWUP("mtime.usec not delimited");
+			atime.tv_sec = strtol(cp, &cp, 10);
+			if (!cp || *cp++ != ' ')
+				SCREWUP("atime.sec not delimited");
+			atime.tv_usec = strtol(cp, &cp, 10);
+			if (!cp || *cp++ != '\0')
+				SCREWUP("atime.usec not delimited");
+			(void)write(remout, "", 1);
+			continue;
+		}
+		if (*cp != 'C' && *cp != 'D') {
+			/*
+			 * Check for the case "rcp remote:foo\* local:bar".
+			 * In this case, the line "No match." can be returned
+			 * by the shell before the rcp command on the remote is
+			 * executed so the ^Aerror_message convention isn't
+			 * followed.
+			 */
+			if (first) {
+				run_err("%s", cp);
+				exit(1);
+			}
+			SCREWUP("expected control record");
+		}
+		mode = 0;
+		for (++cp; cp < buf + 5; cp++) {
+			if (*cp < '0' || *cp > '7')
+				SCREWUP("bad mode");
+			mode = (mode << 3) | (*cp - '0');
+		}
+		if (*cp++ != ' ')
+			SCREWUP("mode not delimited");
+
+		for (size = 0; isdigit(*cp);)
+			size = size * 10 + (*cp++ - '0');
+		if (*cp++ != ' ')
+			SCREWUP("size not delimited");
+		if (targisdir) {
+			static char *namebuf;
+			static int cursize;
+			size_t need;
+
+			need = strlen(targ) + strlen(cp) + 250;
+			if (need > cursize) {
+				if (!(namebuf = malloc(need)))
+					run_err("%s", strerror(errno));
+			}
+			(void)snprintf(namebuf, need, "%s%s%s", targ,
+			    *targ ? "/" : "", cp);
+			np = namebuf;
+		} else
+			np = targ;
+		exists = stat(np, &stb) == 0;
+		if (buf[0] == 'D') {
+			int mod_flag = pflag;
+			if (exists) {
+				if (!S_ISDIR(stb.st_mode)) {
+					errno = ENOTDIR;
+					goto bad;
+				}
+				if (pflag)
+					(void)chmod(np, mode);
+			} else {
+				/* Handle copying from a read-only directory */
+				mod_flag = 1;
+				if (mkdir(np, mode | S_IRWXU) < 0)
+					goto bad;
+			}
+			vect[0] = np;
+			sink(1, vect);
+			if (setimes) {
+				setimes = 0;
+				if (utimes(np, tv) < 0)
+				    run_err("%s: set times: %s",
+					np, strerror(errno));
+			}
+			if (mod_flag)
+				(void)chmod(np, mode);
+			continue;
+		}
+		omode = mode;
+		mode |= S_IWRITE;
+		if ((ofd = open(np, O_WRONLY|O_CREAT, mode)) < 0) {
+bad:			run_err("%s: %s", np, strerror(errno));
+			continue;
+		}
+		(void)write(remout, "", 1);
+		if ((bp = allocbuf(&buffer, ofd, BUFSIZ)) == NULL) {
+			(void)close(ofd);
+			continue;
+		}
+		cp = bp->buf;
+		wrerr = NO;
+		for (count = i = 0; i < size; i += BUFSIZ) {
+			amt = BUFSIZ;
+			if (i + amt > size)
+				amt = size - i;
+			count += amt;
+			do {
+				j = read(remin, cp, amt);
+				if (j <= 0) {
+					run_err("%s", j ? strerror(errno) :
+					    "dropped connection");
+					exit(1);
+				}
+				amt -= j;
+				cp += j;
+			} while (amt > 0);
+			if (count == bp->cnt) {
+				/* Keep reading so we stay sync'd up. */
+				if (wrerr == NO) {
+					j = write(ofd, bp->buf, count);
+					if (j != count) {
+						wrerr = YES;
+						wrerrno = j >= 0 ? EIO : errno;
+					}
+				}
+				count = 0;
+				cp = bp->buf;
+			}
+		}
+		if (count != 0 && wrerr == NO &&
+		    (j = write(ofd, bp->buf, count)) != count) {
+			wrerr = YES;
+			wrerrno = j >= 0 ? EIO : errno;
+		}
+		if (ftruncate(ofd, size)) {
+			run_err("%s: truncate: %s", np, strerror(errno));
+			wrerr = DISPLAYED;
+		}
+		if (pflag) {
+			if (exists || omode != mode)
+				if (fchmod(ofd, omode))
+					run_err("%s: set mode: %s",
+					    np, strerror(errno));
+		} else {
+			if (!exists && omode != mode)
+				if (fchmod(ofd, omode & ~mask))
+					run_err("%s: set mode: %s",
+					    np, strerror(errno));
+		}
+		(void)close(ofd);
+		(void)response();
+		if (setimes && wrerr == NO) {
+			setimes = 0;
+			if (utimes(np, tv) < 0) {
+				run_err("%s: set times: %s",
+				    np, strerror(errno));
+				wrerr = DISPLAYED;
+			}
+		}
+		switch(wrerr) {
+		case YES:
+			run_err("%s: %s", np, strerror(wrerrno));
+			break;
+		case NO:
+			(void)write(remout, "", 1);
+			break;
+		case DISPLAYED:
+			break;
+		}
+	}
+screwup:
+	run_err("protocol error: %s", why);
+	exit(1);
+}
+
+int
+response()
+{
+	char ch, *cp, resp, rbuf[BUFSIZ];
+
+	if (read(remin, &resp, sizeof(resp)) != sizeof(resp))
+		lostconn(0);
+
+	cp = rbuf;
+	switch(resp) {
+	case 0:				/* ok */
+		return (0);
+	default:
+		*cp++ = resp;
+		/* FALLTHROUGH */
+	case 1:				/* error, followed by error msg */
+	case 2:				/* fatal error, "" */
+		do {
+			if (read(remin, &ch, sizeof(ch)) != sizeof(ch))
+				lostconn(0);
+			*cp++ = ch;
+		} while (cp < &rbuf[BUFSIZ] && ch != '\n');
+
+		if (!iamremote)
+			(void)write(STDERR_FILENO, rbuf, cp - rbuf);
+		++errs;
+		if (resp == 1)
+			return (-1);
+		exit(1);
+	}
+	/* NOTREACHED */
+}
+
+void
+usage()
+{
+	(void)fprintf(stderr, "%s\n%s\n",
+		      "usage: rcp [-5FKpx] [-P port] f1 f2",
+		      "       rcp [-5FKprx] [-P port] f1 ... fn directory");
+	exit(1);
+}
+
+#include <stdarg.h>
+
+void
+run_err(const char *fmt, ...)
+{
+	static FILE *fp;
+	va_list ap;
+	va_start(ap, fmt);
+
+	++errs;
+	if (fp == NULL && !(fp = fdopen(remout, "w")))
+		return;
+	(void)fprintf(fp, "%c", 0x01);
+	(void)fprintf(fp, "rcp: ");
+	(void)vfprintf(fp, fmt, ap);
+	(void)fprintf(fp, "\n");
+	(void)fflush(fp);
+
+	if (!iamremote)
+		vwarnx(fmt, ap);
+
+	va_end(ap);
+}
+
+/*
+ * This function executes the given command as the specified user on the
+ * given host.  This returns < 0 if execution fails, and >= 0 otherwise. This
+ * assigns the input and output file descriptors on success.
+ *
+ * If it cannot create necessary pipes it exits with error message.
+ */
+
+int 
+do_cmd(char *host, char *remuser, char *cmd, int *fdin, int *fdout)
+{
+	int pin[2], pout[2], reserved[2];
+
+	/*
+	 * Reserve two descriptors so that the real pipes won't get
+	 * descriptors 0 and 1 because that will screw up dup2 below.
+	 */
+	pipe(reserved);
+
+	/* Create a socket pair for communicating with rsh. */
+	if (pipe(pin) < 0) {
+		perror("pipe");
+		exit(255);
+	}
+	if (pipe(pout) < 0) {
+		perror("pipe");
+		exit(255);
+	}
+
+	/* Free the reserved descriptors. */
+	close(reserved[0]);
+	close(reserved[1]);
+
+	/* For a child to execute the command on the remote host using rsh. */
+	if (fork() == 0) {
+		char *args[100];
+		unsigned int i;
+
+		/* Child. */
+		close(pin[1]);
+		close(pout[0]);
+		dup2(pin[0], 0);
+		dup2(pout[1], 1);
+		close(pin[0]);
+		close(pout[1]);
+
+		i = 0;
+		args[i++] = RSH_PROGRAM;
+		if (usekrb5)
+			args[i++] = "-5";
+		if (usebroken)
+			args[i++] = "-K";
+		if (doencrypt)
+			args[i++] = "-x";
+		if (noencrypt)
+			args[i++] = "-z";
+		if (port != NULL) {
+			args[i++] = "-p";
+			args[i++] = port;
+		}
+		if (remuser != NULL) {
+			args[i++] = "-l";
+			args[i++] = remuser;
+		}
+		args[i++] = host;
+		args[i++] = cmd;
+		args[i++] = NULL;
+
+		execvp(RSH_PROGRAM, args);
+		perror(RSH_PROGRAM);
+		exit(1);
+	}
+	/* Parent.  Close the other side, and return the local side. */
+	close(pin[0]);
+	*fdout = pin[1];
+	close(pout[1]);
+	*fdin = pout[0];
+	return 0;
+}
diff --git a/crypto/heimdal/appl/rcp/rcp_locl.h b/crypto/heimdal/appl/rcp/rcp_locl.h
new file mode 100644
index 000000000000..4397c9f461ac
--- /dev/null
+++ b/crypto/heimdal/appl/rcp/rcp_locl.h
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 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: rcp_locl.h,v 1.3 2001/01/29 05:59:24 assar Exp $ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <sys/param.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/time.h>
+#include <sys/wait.h>
+
+#include <ctype.h>
+#include <dirent.h>
+#include <err.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <pwd.h>
+#include <signal.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <string.h>
+#include <unistd.h>
+
+#include <roken.h>
+
+#include "extern.h"
+
+#define	_PATH_CP	"/bin/cp"
+#define	_PATH_RSH	"/usr/bin/rsh"
diff --git a/crypto/heimdal/appl/rcp/util.c b/crypto/heimdal/appl/rcp/util.c
new file mode 100644
index 000000000000..9d0f6d5ea3a0
--- /dev/null
+++ b/crypto/heimdal/appl/rcp/util.c
@@ -0,0 +1,165 @@
+/*-
+ * 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.
+ */
+
+#if 0
+#ifndef lint
+#if 0
+static char sccsid[] = "@(#)util.c	8.2 (Berkeley) 4/2/94";
+#endif
+static const char rcsid[] =
+  "$FreeBSD$";
+#endif /* not lint */
+#endif
+
+#include "rcp_locl.h"
+
+RCSID("$Id: util.c,v 1.5 2001/01/29 23:36:37 assar Exp $");
+
+char *
+colon(cp)
+	char *cp;
+{
+	if (*cp == ':')		/* Leading colon is part of file name. */
+		return (0);
+
+	for (; *cp; ++cp) {
+		if (*cp == ':')
+			return (cp);
+		if (*cp == '/')
+			return (0);
+	}
+	return (0);
+}
+
+void
+verifydir(cp)
+	char *cp;
+{
+	struct stat stb;
+
+	if (!stat(cp, &stb)) {
+		if (S_ISDIR(stb.st_mode))
+			return;
+		errno = ENOTDIR;
+	}
+	run_err("%s: %s", cp, strerror(errno));
+	exit(1);
+}
+
+int
+okname(cp0)
+	char *cp0;
+{
+	int c;
+	char *cp;
+
+	cp = cp0;
+	do {
+		c = *cp;
+		if (c & 0200)
+			goto bad;
+		if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-')
+			goto bad;
+	} while (*++cp);
+	return (1);
+
+bad:	warnx("%s: invalid user name", cp0);
+	return (0);
+}
+
+int
+susystem(s, userid)
+	int userid;
+	char *s;
+{
+	void (*istat)(int), (*qstat)(int);
+	int status;
+	pid_t pid;
+
+	pid = fork();
+	switch (pid) {
+	case -1:
+		return (127);
+
+	case 0:
+		(void)setuid(userid);
+		execl(_PATH_BSHELL, "sh", "-c", s, NULL);
+		_exit(127);
+	}
+	istat = signal(SIGINT, SIG_IGN);
+	qstat = signal(SIGQUIT, SIG_IGN);
+	if (waitpid(pid, &status, 0) < 0)
+		status = -1;
+	(void)signal(SIGINT, istat);
+	(void)signal(SIGQUIT, qstat);
+	return (status);
+}
+
+#ifndef roundup
+#define	roundup(x, y)	((((x)+((y)-1))/(y))*(y))
+#endif
+
+BUF *
+allocbuf(bp, fd, blksize)
+	BUF *bp;
+	int fd, blksize;
+{
+	struct stat stb;
+	size_t size;
+
+	if (fstat(fd, &stb) < 0) {
+		run_err("fstat: %s", strerror(errno));
+		return (0);
+	}
+	size = roundup(stb.st_blksize, blksize);
+	if (size == 0)
+		size = blksize;
+	if (bp->cnt >= size)
+		return (bp);
+	if ((bp->buf = realloc(bp->buf, size)) == NULL) {
+		bp->cnt = 0;
+		run_err("%s", strerror(errno));
+		return (0);
+	}
+	bp->cnt = size;
+	return (bp);
+}
+
+void
+lostconn(signo)
+	int signo;
+{
+	if (!iamremote)
+		warnx("lost connection");
+	exit(1);
+}
diff --git a/crypto/heimdal/cf/aix.m4 b/crypto/heimdal/cf/aix.m4
new file mode 100644
index 000000000000..25aaa2aed62a
--- /dev/null
+++ b/crypto/heimdal/cf/aix.m4
@@ -0,0 +1,39 @@
+dnl
+dnl $Id: aix.m4,v 1.5 2000/11/05 17:15:46 joda Exp $
+dnl
+
+AC_DEFUN(KRB_AIX,[
+aix=no
+case "$host" in 
+*-*-aix3*)
+	aix=3
+	;;
+*-*-aix4*)
+	aix=4
+	;;
+esac
+AM_CONDITIONAL(AIX, test "$aix" != no)dnl
+AM_CONDITIONAL(AIX4, test "$aix" = 4)
+aix_dynamic_afs=yes
+AM_CONDITIONAL(AIX_DYNAMIC_AFS, test "$aix_dynamic_afs" = yes)dnl
+
+AC_FIND_FUNC_NO_LIBS(dlopen, dl)
+
+if test "$aix" != no; then
+	if test "$aix_dynamic_afs" = yes; then
+		if test "$ac_cv_funclib_dlopen" = yes; then
+			AIX_EXTRA_KAFS=
+		elif test "$ac_cv_funclib_dlopen" != no; then
+			AIX_EXTRA_KAFS="$ac_cv_funclib_dlopen"
+		else
+			AIX_EXTRA_KAFS=-lld
+		fi
+	else
+		AIX_EXTRA_KAFS=
+	fi
+fi
+
+AM_CONDITIONAL(HAVE_DLOPEN, test "$ac_cv_funclib_dlopen" != no)dnl
+AC_SUBST(AIX_EXTRA_KAFS)dnl
+
+])
\ No newline at end of file
diff --git a/crypto/heimdal/cf/broken-getnameinfo.m4 b/crypto/heimdal/cf/broken-getnameinfo.m4
new file mode 100644
index 000000000000..da206c04a06e
--- /dev/null
+++ b/crypto/heimdal/cf/broken-getnameinfo.m4
@@ -0,0 +1,28 @@
+dnl $Id: broken-getnameinfo.m4,v 1.2 2000/12/05 09:09:00 joda Exp $
+dnl
+dnl test for broken AIX getnameinfo
+
+AC_DEFUN(rk_BROKEN_GETNAMEINFO,[
+AC_CACHE_CHECK([if getnameinfo is broken], ac_cv_func_getnameinfo_broken,
+AC_TRY_RUN([[#include <stdio.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <netdb.h>
+
+int
+main(int argc, char **argv)
+{
+  struct sockaddr_in sin;
+  char host[256];
+  memset(&sin, 0, sizeof(sin));
+#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN
+  sin.sin_len = sizeof(sin);
+#endif
+  sin.sin_family = AF_INET;
+  sin.sin_addr.s_addr = 0xffffffff;
+  sin.sin_port = 0;
+  return getnameinfo((struct sockaddr*)&sin, sizeof(sin), host, sizeof(host),
+	      NULL, 0, 0);
+}
+]], ac_cv_func_getnameinfo_broken=no, ac_cv_func_getnameinfo_broken=yes))])
diff --git a/crypto/heimdal/cf/broken-realloc.m4 b/crypto/heimdal/cf/broken-realloc.m4
new file mode 100644
index 000000000000..15692559b2a2
--- /dev/null
+++ b/crypto/heimdal/cf/broken-realloc.m4
@@ -0,0 +1,26 @@
+dnl
+dnl $Id: broken-realloc.m4,v 1.1 2000/07/15 18:05:36 joda Exp $
+dnl
+dnl Test for realloc that doesn't handle NULL as first parameter
+dnl
+AC_DEFUN(rk_BROKEN_REALLOC, [
+AC_CACHE_CHECK(if realloc if broken, ac_cv_func_realloc_broken, [
+ac_cv_func_realloc_broken=no
+AC_TRY_RUN([
+#include <stddef.h>
+#include <stdlib.h>
+
+int main()
+{
+	return realloc(NULL, 17) == NULL;
+}
+],:, ac_cv_func_realloc_broken=yes, :)
+])
+if test "$ac_cv_func_realloc_broken" = yes ; then
+	AC_DEFINE(BROKEN_REALLOC, 1, [Define if realloc(NULL) doesn't work.])
+fi
+AH_BOTTOM([#ifdef BROKEN_REALLOC
+#define realloc(X, Y) isoc_realloc((X), (Y))
+#define isoc_realloc(X, Y) ((X) ? realloc((X), (Y)) : malloc(Y))
+#endif])
+])
diff --git a/crypto/heimdal/cf/broken2.m4 b/crypto/heimdal/cf/broken2.m4
new file mode 100644
index 000000000000..78a3dcbc357e
--- /dev/null
+++ b/crypto/heimdal/cf/broken2.m4
@@ -0,0 +1,35 @@
+dnl $Id: broken2.m4,v 1.1 2000/12/15 14:27:33 assar Exp $
+dnl
+dnl AC_BROKEN but with more arguments
+
+dnl AC_BROKEN2(func, includes, arguments)
+AC_DEFUN(AC_BROKEN2,
+[for ac_func in $1
+do
+AC_MSG_CHECKING([for $ac_func])
+AC_CACHE_VAL(ac_cv_func_$ac_func,
+[AC_TRY_LINK([$2],
+[
+/* The GNU C library defines this for functions which it implements
+    to always fail with ENOSYS.  Some functions are actually named
+    something starting with __ and the normal name is an alias.  */
+#if defined (__stub_$1) || defined (__stub___$1)
+choke me
+#else
+$ac_func($3)
+#endif
+], [eval "ac_cv_func_$ac_func=yes"], [eval "ac_cv_func_$ac_func=no"])])
+if eval "test \"\${ac_cv_func_$ac_func}\" = yes"; then
+  ac_tr_func=HAVE_[]upcase($ac_func)
+  AC_DEFINE_UNQUOTED($ac_tr_func)
+  AC_MSG_RESULT(yes)
+else
+  AC_MSG_RESULT(no)
+  LIBOBJS[]="$LIBOBJS ${ac_func}.o"
+fi
+done
+if false; then
+	AC_CHECK_FUNCS($1)
+fi
+AC_SUBST(LIBOBJS)dnl
+])
diff --git a/crypto/heimdal/cf/db.m4 b/crypto/heimdal/cf/db.m4
new file mode 100644
index 000000000000..c147569c51d6
--- /dev/null
+++ b/crypto/heimdal/cf/db.m4
@@ -0,0 +1,40 @@
+dnl $Id: db.m4,v 1.1 2000/07/19 11:21:07 joda Exp $
+dnl
+dnl tests for various db libraries
+dnl
+AC_DEFUN([rk_DB],[berkeley_db=db
+AC_ARG_WITH(berkeley-db,
+[  --without-berkeley-db   if you don't want berkeley db],[
+if test "$withval" = no; then
+	berkeley_db=""
+fi
+])
+if test "$berkeley_db"; then
+  AC_CHECK_HEADERS([				\
+	db.h					\
+	db_185.h				\
+  ])
+fi
+
+AC_FIND_FUNC_NO_LIBS2(dbopen, $berkeley_db, [
+#include <stdio.h>
+#if defined(HAVE_DB_185_H)
+#include <db_185.h>
+#elif defined(HAVE_DB_H)
+#include <db.h>
+#endif
+],[NULL, 0, 0, 0, NULL])
+
+AC_FIND_FUNC_NO_LIBS(dbm_firstkey, $berkeley_db gdbm ndbm)
+AC_FIND_FUNC_NO_LIBS(db_create, $berkeley_db)
+
+DBLIB="$LIB_dbopen"
+if test "$LIB_dbopen" != "$LIB_db_create"; then
+        DBLIB="$DBLIB $LIB_db_create"
+fi
+if test "$LIB_dbopen" != "$LIB_dbm_firstkey"; then
+	DBLIB="$DBLIB $LIB_dbm_firstkey"
+fi
+AC_SUBST(DBLIB)dnl
+
+])
diff --git a/crypto/heimdal/cf/install-catman.sh b/crypto/heimdal/cf/install-catman.sh
new file mode 100755
index 000000000000..c48cc208af5b
--- /dev/null
+++ b/crypto/heimdal/cf/install-catman.sh
@@ -0,0 +1,25 @@
+#!/bin/sh
+#
+# $Id: install-catman.sh,v 1.1 2000/11/30 01:38:17 joda Exp $
+#
+# install preformatted manual pages
+
+INSTALL_DATA="$1"; shift
+mkinstalldirs="$1"; shift
+srcdir="$1"; shift
+mandir="$1"; shift
+suffix="$1"; shift
+
+for f in "$@"; do
+	base=`echo "$f" | sed 's/\(.*\)\.\([^.]*\)$/\1/'`
+	section=`echo "$f" | sed 's/\(.*\)\.\([^.]*\)$/\2/'`
+	catdir="$mandir/cat$section"
+	c="$base.cat$section"
+	if test -f "$srcdir/$c"; then
+		if test \! -d "$catdir"; then
+			eval "$mkinstalldirs $catdir"
+		fi
+		eval "echo $INSTALL_DATA $srcdir/$c $catdir/$base.$suffix"
+		eval "$INSTALL_DATA $srcdir/$c $catdir/$base.$suffix"
+	fi
+done
diff --git a/crypto/heimdal/cf/krb-irix.m4 b/crypto/heimdal/cf/krb-irix.m4
new file mode 100644
index 000000000000..cdde69c147b0
--- /dev/null
+++ b/crypto/heimdal/cf/krb-irix.m4
@@ -0,0 +1,12 @@
+dnl
+dnl $Id: krb-irix.m4,v 1.2 2000/12/13 12:48:45 assar Exp $
+dnl
+
+dnl requires AC_CANONICAL_HOST
+AC_DEFUN(KRB_IRIX,[
+irix=no
+case "$host_os" in
+irix*) irix=yes ;;
+esac
+AM_CONDITIONAL(IRIX, test "$irix" != no)dnl
+])
diff --git a/crypto/heimdal/cf/krb-readline.m4 b/crypto/heimdal/cf/krb-readline.m4
new file mode 100644
index 000000000000..6d0f0b211f5d
--- /dev/null
+++ b/crypto/heimdal/cf/krb-readline.m4
@@ -0,0 +1,43 @@
+dnl $Id: krb-readline.m4,v 1.2 2000/11/15 00:47:08 assar Exp $
+dnl
+dnl Tests for readline functions
+dnl
+
+dnl el_init
+
+AC_DEFUN(KRB_READLINE,[
+AC_FIND_FUNC_NO_LIBS(el_init, edit, [], [], [$LIB_tgetent])
+if test "$ac_cv_func_el_init" = yes ; then
+	AC_CACHE_CHECK(for four argument el_init, ac_cv_func_el_init_four,[
+		AC_TRY_COMPILE([#include <stdio.h>
+			#include <histedit.h>],
+			[el_init("", NULL, NULL, NULL);],
+			ac_cv_func_el_init_four=yes,
+			ac_cv_func_el_init_four=no)])
+	if test "$ac_cv_func_el_init_four" = yes; then
+		AC_DEFINE(HAVE_FOUR_VALUED_EL_INIT, 1, [Define if el_init takes four arguments.])
+	fi
+fi
+
+dnl readline
+
+ac_foo=no
+if test "$with_readline" = yes; then
+	:
+elif test "$ac_cv_func_readline" = yes; then
+	:
+elif test "$ac_cv_func_el_init" = yes; then
+	ac_foo=yes
+	LIB_readline="\$(top_builddir)/lib/editline/libel_compat.la $LIB_el_init"
+else
+	LIB_readline='$(top_builddir)/lib/editline/libeditline.la'
+fi
+AM_CONDITIONAL(el_compat, test "$ac_foo" = yes)
+if test "$readline_libdir"; then
+	LIB_readline="-rpath $readline_libdir $LIB_readline"
+fi
+LIB_readline="$LIB_readline \$(LIB_tgetent)"
+AC_DEFINE(HAVE_READLINE, 1, 
+	[Define if you have a readline compatible library.])dnl
+
+])
\ No newline at end of file
diff --git a/crypto/heimdal/cf/retsigtype.m4 b/crypto/heimdal/cf/retsigtype.m4
new file mode 100644
index 000000000000..4c3ecbdff017
--- /dev/null
+++ b/crypto/heimdal/cf/retsigtype.m4
@@ -0,0 +1,18 @@
+dnl
+dnl $Id: retsigtype.m4,v 1.1 2000/07/15 18:05:56 joda Exp $
+dnl
+dnl Figure out return type of signal handlers, and define SIGRETURN macro
+dnl that can be used to return from one
+dnl
+AC_DEFUN(rk_RETSIGTYPE,[
+AC_TYPE_SIGNAL
+if test "$ac_cv_type_signal" = "void" ; then
+	AC_DEFINE(VOID_RETSIGTYPE, 1, [Define if signal handlers return void.])
+fi
+AC_SUBST(VOID_RETSIGTYPE)
+AH_BOTTOM([#ifdef VOID_RETSIGTYPE
+#define SIGRETURN(x) return
+#else
+#define SIGRETURN(x) return (RETSIGTYPE)(x)
+#endif])
+])
\ No newline at end of file
diff --git a/crypto/heimdal/cf/roken-frag.m4 b/crypto/heimdal/cf/roken-frag.m4
new file mode 100644
index 000000000000..c6b552e6e059
--- /dev/null
+++ b/crypto/heimdal/cf/roken-frag.m4
@@ -0,0 +1,586 @@
+dnl $Id: roken-frag.m4,v 1.19 2000/12/15 14:29:54 assar Exp $
+dnl
+dnl some code to get roken working
+dnl
+dnl rk_ROKEN(subdir)
+dnl
+AC_DEFUN(rk_ROKEN, [
+
+AC_REQUIRE([rk_CONFIG_HEADER])
+
+DIR_roken=roken
+LIB_roken='$(top_builddir)/$1/libroken.la'
+INCLUDES_roken='-I$(top_builddir)/$1 -I$(top_srcdir)/$1'
+
+dnl Checks for programs
+AC_REQUIRE([AC_PROG_CC])
+AC_REQUIRE([AC_PROG_AWK])
+AC_REQUIRE([AC_OBJEXT])
+AC_REQUIRE([AC_EXEEXT])
+AC_REQUIRE([AC_PROG_LIBTOOL])
+
+AC_REQUIRE([AC_MIPS_ABI])
+
+dnl C characteristics
+
+AC_REQUIRE([AC_C___ATTRIBUTE__])
+AC_REQUIRE([AC_C_INLINE])
+AC_REQUIRE([AC_C_CONST])
+AC_WFLAGS(-Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs)
+
+AC_REQUIRE([rk_DB])
+
+dnl C types
+
+AC_REQUIRE([AC_TYPE_SIZE_T])
+AC_CHECK_TYPE_EXTRA(ssize_t, int, [#include <unistd.h>])
+AC_REQUIRE([AC_TYPE_PID_T])
+AC_REQUIRE([AC_TYPE_UID_T])
+AC_HAVE_TYPE([long long])
+
+AC_REQUIRE([rk_RETSIGTYPE])
+
+dnl Checks for header files.
+AC_REQUIRE([AC_HEADER_STDC])
+AC_REQUIRE([AC_HEADER_TIME])
+
+AC_CHECK_HEADERS([\
+	arpa/inet.h				\
+	arpa/nameser.h				\
+	config.h				\
+	crypt.h					\
+	dbm.h					\
+	db.h					\
+	dirent.h				\
+	errno.h					\
+	err.h					\
+	fcntl.h					\
+	gdbm/ndbm.h				\
+	grp.h					\
+	ifaddrs.h				\
+	ndbm.h					\
+	net/if.h				\
+	netdb.h					\
+	netinet/in.h				\
+	netinet/in6.h				\
+	netinet/in_systm.h			\
+	netinet6/in6.h				\
+	netinet6/in6_var.h			\
+	paths.h					\
+	pwd.h					\
+	resolv.h				\
+	rpcsvc/dbm.h				\
+	rpcsvc/ypclnt.h				\
+	shadow.h				\
+	sys/ioctl.h				\
+	sys/param.h				\
+	sys/proc.h				\
+	sys/resource.h				\
+	sys/socket.h				\
+	sys/sockio.h				\
+	sys/stat.h				\
+	sys/sysctl.h				\
+	sys/time.h				\
+	sys/tty.h				\
+	sys/types.h				\
+	sys/uio.h				\
+	sys/utsname.h				\
+	sys/wait.h				\
+	syslog.h				\
+	termios.h				\
+	unistd.h				\
+	userconf.h				\
+	usersec.h				\
+	util.h					\
+	vis.h					\
+	winsock.h				\
+])
+	
+AC_REQUIRE([CHECK_NETINET_IP_AND_TCP])
+
+AM_CONDITIONAL(have_err_h, test "$ac_cv_header_err_h" = yes)
+AM_CONDITIONAL(have_fnmatch_h, test "$ac_cv_header_fnmatch_h" = yes)
+AM_CONDITIONAL(have_ifaddrs_h, test "$ac_cv_header_ifaddrs_h" = yes)
+AM_CONDITIONAL(have_vis_h, test "$ac_cv_header_vis_h" = yes)
+
+dnl Check for functions and libraries
+
+AC_KRB_IPV6
+
+AC_FIND_FUNC(socket, socket)
+AC_FIND_FUNC(gethostbyname, nsl)
+AC_FIND_FUNC(syslog, syslog)
+AC_FIND_FUNC(gethostbyname2, inet6 ip6)
+
+AC_FIND_FUNC(res_search, resolv,
+[
+#include <stdio.h>
+#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#ifdef HAVE_NETINET_IN_H
+#include <netinet/in.h>
+#endif
+#ifdef HAVE_ARPA_NAMESER_H
+#include <arpa/nameser.h>
+#endif
+#ifdef HAVE_RESOLV_H
+#include <resolv.h>
+#endif
+],
+[0,0,0,0,0])
+
+AC_FIND_FUNC(dn_expand, resolv,
+[
+#include <stdio.h>
+#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#ifdef HAVE_NETINET_IN_H
+#include <netinet/in.h>
+#endif
+#ifdef HAVE_ARPA_NAMESER_H
+#include <arpa/nameser.h>
+#endif
+#ifdef HAVE_RESOLV_H
+#include <resolv.h>
+#endif
+],
+[0,0,0,0,0])
+
+AC_BROKEN_SNPRINTF
+AC_BROKEN_VSNPRINTF
+
+AC_BROKEN_GLOB
+if test "$ac_cv_func_glob_working" != yes; then
+	LIBOBJS="$LIBOBJS glob.o"
+fi
+AM_CONDITIONAL(have_glob_h, test "$ac_cv_func_glob_working" = yes)
+
+
+AC_CHECK_FUNCS([				\
+	asnprintf				\
+	asprintf				\
+	cgetent					\
+	getconfattr				\
+	getrlimit				\
+	getspnam				\
+	strsvis					\
+	strunvis				\
+	strvis					\
+	strvisx					\
+	svis					\
+	sysconf					\
+	sysctl					\
+	uname					\
+	unvis					\
+	vasnprintf				\
+	vasprintf				\
+	vis					\
+])
+
+if test "$ac_cv_func_cgetent" = no; then
+	LIBOBJS="$LIBOBJS getcap.o"
+fi
+
+AC_REQUIRE([AC_FUNC_GETLOGIN])
+
+AC_FIND_FUNC_NO_LIBS(getsockopt,,
+[#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
+#endif],
+[0,0,0,0,0])
+AC_FIND_FUNC_NO_LIBS(setsockopt,,
+[#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
+#endif],
+[0,0,0,0,0])
+
+AC_FIND_IF_NOT_BROKEN(hstrerror, resolv,
+[#ifdef HAVE_NETDB_H
+#include <netdb.h>
+#endif],
+17)
+if test "$ac_cv_func_hstrerror" = yes; then
+AC_NEED_PROTO([
+#ifdef HAVE_NETDB_H
+#include <netdb.h>
+#endif],
+hstrerror)
+fi
+
+dnl sigh, wish this could be done in a loop
+if test "$ac_cv_func_asprintf" = yes; then
+AC_NEED_PROTO([
+#include <stdio.h>
+#include <string.h>],
+asprintf)dnl
+fi
+if test "$ac_cv_func_vasprintf" = yes; then
+AC_NEED_PROTO([
+#include <stdio.h>
+#include <string.h>],
+vasprintf)dnl
+fi
+if test "$ac_cv_func_asnprintf" = yes; then
+AC_NEED_PROTO([
+#include <stdio.h>
+#include <string.h>],
+asnprintf)dnl
+fi
+if test "$ac_cv_func_vasnprintf" = yes; then
+AC_NEED_PROTO([
+#include <stdio.h>
+#include <string.h>],
+vasnprintf)dnl
+fi
+
+AC_FIND_FUNC_NO_LIBS(pidfile,util,
+[#ifdef HAVE_UTIL_H
+#include <util.h>
+#endif],0)
+
+AC_BROKEN([					\
+	chown					\
+	copyhostent				\
+	daemon					\
+	err					\
+	errx					\
+	fchown					\
+	flock					\
+	fnmatch					\
+	freeaddrinfo				\
+	freehostent				\
+	gai_strerror				\
+	getaddrinfo				\
+	getcwd					\
+	getdtablesize				\
+	getegid					\
+	geteuid					\
+	getgid					\
+	gethostname				\
+	getifaddrs				\
+	getipnodebyaddr				\
+	getipnodebyname				\
+	getnameinfo				\
+	getopt					\
+	gettimeofday				\
+	getuid					\
+	getusershell				\
+	initgroups				\
+	innetgr					\
+	iruserok				\
+	lstat					\
+	memmove					\
+	mkstemp					\
+	putenv					\
+	rcmd					\
+	readv					\
+	recvmsg					\
+	sendmsg					\
+	setegid					\
+	setenv					\
+	seteuid					\
+	strcasecmp				\
+	strdup					\
+	strerror				\
+	strftime				\
+	strlcat					\
+	strlcpy					\
+	strlwr					\
+	strncasecmp				\
+	strndup					\
+	strnlen					\
+	strptime				\
+	strsep					\
+	strsep_copy				\
+	strtok_r				\
+	strupr					\
+	swab					\
+	unsetenv				\
+	verr					\
+	verrx					\
+	vsyslog					\
+	vwarn					\
+	vwarnx					\
+	warn					\
+	warnx					\
+	writev					\
+])
+
+AC_BROKEN2(inet_aton,
+[#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],
+[0,0])
+
+AC_BROKEN2(inet_ntop,
+[#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],
+[0, 0, 0, 0])
+
+AC_BROKEN2(inet_pton,
+[#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],
+[0,0,0])
+
+dnl
+dnl Check for sa_len in struct sockaddr, 
+dnl needs to come before the getnameinfo test
+dnl
+AC_HAVE_STRUCT_FIELD(struct sockaddr, sa_len, [#include <sys/types.h>
+#include <sys/socket.h>])
+
+if test "$ac_cv_func_getnameinfo" = "yes"; then
+  rk_BROKEN_GETNAMEINFO
+  if test "$ac_cv_func_getnameinfo_broken" = yes; then
+    LIBOBJS="$LIBOBJS getnameinfo.o"
+  fi
+fi
+
+AC_NEED_PROTO([#include <stdlib.h>], setenv)
+AC_NEED_PROTO([#include <stdlib.h>], unsetenv)
+AC_NEED_PROTO([#include <unistd.h>], gethostname)
+AC_NEED_PROTO([#include <unistd.h>], mkstemp)
+AC_NEED_PROTO([#include <unistd.h>], getusershell)
+
+AC_NEED_PROTO([
+#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],
+inet_aton)
+
+AC_FIND_FUNC_NO_LIBS(crypt, crypt)dnl
+
+AC_REQUIRE([rk_BROKEN_REALLOC])dnl
+
+dnl AC_KRB_FUNC_GETCWD_BROKEN
+
+dnl
+dnl Checks for prototypes and declarations
+dnl
+
+AC_PROTO_COMPAT([
+#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
+],
+gethostbyname, struct hostent *gethostbyname(const char *))
+
+AC_PROTO_COMPAT([
+#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
+],
+gethostbyaddr, struct hostent *gethostbyaddr(const void *, size_t, int))
+
+AC_PROTO_COMPAT([
+#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
+],
+getservbyname, struct servent *getservbyname(const char *, const char *))
+
+AC_PROTO_COMPAT([
+#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
+#endif
+],
+getsockname, int getsockname(int, struct sockaddr*, socklen_t*))
+
+AC_PROTO_COMPAT([
+#ifdef HAVE_SYSLOG_H
+#include <syslog.h>
+#endif
+],
+openlog, void openlog(const char *, int, int))
+
+AC_NEED_PROTO([
+#ifdef HAVE_CRYPT_H
+#include <crypt.h>
+#endif
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif
+],
+crypt)
+
+AC_NEED_PROTO([
+#include <string.h>
+],
+strtok_r)
+
+AC_NEED_PROTO([
+#include <string.h>
+],
+strsep)
+
+dnl variables
+
+rk_CHECK_VAR(h_errno, 
+[#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#ifdef HAVE_NETDB_H
+#include <netdb.h>
+#endif])
+
+rk_CHECK_VAR(h_errlist, 
+[#ifdef HAVE_NETDB_H
+#include <netdb.h>
+#endif])
+
+rk_CHECK_VAR(h_nerr, 
+[#ifdef HAVE_NETDB_H
+#include <netdb.h>
+#endif])
+
+rk_CHECK_VAR([__progname], 
+[#ifdef HAVE_ERR_H
+#include <err.h>
+#endif])
+
+AC_CHECK_DECLARATION([#include <stdlib.h>
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif], optarg)
+AC_CHECK_DECLARATION([#include <stdlib.h>
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif], optind)
+AC_CHECK_DECLARATION([#include <stdlib.h>
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif], opterr)
+AC_CHECK_DECLARATION([#include <stdlib.h>
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif], optopt)
+
+AC_CHECK_DECLARATION([#include <stdlib.h>], environ)
+
+dnl
+dnl Check for fields in struct tm
+dnl
+
+AC_HAVE_STRUCT_FIELD(struct tm, tm_gmtoff, [#include <time.h>])
+AC_HAVE_STRUCT_FIELD(struct tm, tm_zone, [#include <time.h>])
+
+dnl
+dnl or do we have a variable `timezone' ?
+dnl
+
+rk_CHECK_VAR(timezone,[#include <time.h>])
+
+AC_HAVE_TYPE([sa_family_t],[#include <sys/socket.h>])
+AC_HAVE_TYPE([socklen_t],[#include <sys/socket.h>])
+AC_HAVE_TYPE([struct sockaddr], [#include <sys/socket.h>])
+AC_HAVE_TYPE([struct sockaddr_storage], [#include <sys/socket.h>])
+AC_HAVE_TYPE([struct addrinfo], [#include <netdb.h>])
+AC_HAVE_TYPE([struct ifaddrs], [#include <ifaddrs.h>])
+
+dnl
+dnl Check for struct winsize
+dnl
+
+AC_KRB_STRUCT_WINSIZE
+
+dnl
+dnl Check for struct spwd
+dnl
+
+AC_KRB_STRUCT_SPWD
+
+dnl won't work with automake
+dnl moved to AC_OUTPUT in configure.in
+dnl AC_CONFIG_FILES($1/Makefile)
+
+LIB_roken="${LIB_roken} \$(LIB_crypt) \$(LIB_dbopen)"
+
+AC_SUBST(DIR_roken)dnl
+AC_SUBST(LIB_roken)dnl
+AC_SUBST(INCLUDES_roken)dnl
+])
\ No newline at end of file
diff --git a/crypto/heimdal/cf/roken.m4 b/crypto/heimdal/cf/roken.m4
new file mode 100644
index 000000000000..f5a867846c39
--- /dev/null
+++ b/crypto/heimdal/cf/roken.m4
@@ -0,0 +1,64 @@
+dnl $Id: roken.m4,v 1.2 2000/07/08 15:50:34 assar Exp $
+dnl
+dnl try to look for an installed roken library with sufficient stuff
+dnl
+dnl set LIB_roken to the what we should link with
+dnl set DIR_roken to if the directory should be built
+dnl set CPPFLAGS_roken to stuff to add to CPPFLAGS
+
+dnl AC_ROKEN(version,directory-to-try,roken-dir,fallback-library,fallback-cppflags)
+AC_DEFUN(AC_ROKEN, [
+
+AC_ARG_WITH(roken,
+[  --with-roken=dir	use the roken library in dir],
+[if test "$withval" = "no"; then
+  AC_MSG_ERROR(roken is required)
+fi])
+
+save_CPPFLAGS="${CPPFLAGS}"
+
+case $with_roken in
+yes|"")
+  dirs="$2" ;;
+*)
+  dirs="$with_roken" ;;
+esac
+
+roken_installed=no
+
+for i in $dirs; do
+
+AC_MSG_CHECKING(for roken in $i)
+
+CPPFLAGS="-I$i/include ${CPPFLAGS}"
+
+AC_TRY_CPP(
+[#include <roken.h>
+#if ROKEN_VERSION < $1
+#error old roken version, should be $1
+fail
+#endif
+],[roken_installed=yes; break])
+
+AC_MSG_RESULT($roken_installed)
+
+done
+
+CPPFLAGS="$save_CPPFLAGS"
+
+if test "$roken_installed" != "yes"; then
+  DIR_roken="roken"
+  LIB_roken='$4'
+  CPPFLAGS_roken='$5'
+  AC_CONFIG_SUBDIRS(lib/roken)
+else
+  LIB_roken="$i/lib/libroken.la"
+  CPPFLAGS_roken="-I$i/include"
+fi
+
+LIB_roken="${LIB_roken} \$(LIB_crypt) \$(LIB_dbopen)"
+
+AC_SUBST(LIB_roken)dnl
+AC_SUBST(DIR_roken)dnl
+AC_SUBST(CPPFLAGS_roken)dnl
+])
diff --git a/crypto/heimdal/doc/migration.texi b/crypto/heimdal/doc/migration.texi
new file mode 100644
index 000000000000..90deed775335
--- /dev/null
+++ b/crypto/heimdal/doc/migration.texi
@@ -0,0 +1,43 @@
+@c $Id: migration.texi,v 1.2 2001/01/28 22:03:36 assar Exp $
+
+@node Migration, Windows 2000 compatability, Kerberos 4 issues, Top
+@chapter Migration
+
+@section General issues
+
+When migrating from a Kerberos 4 KDC.
+
+@section Order in what to do things:
+
+@itemize @bullet
+
+@item Convert the database, check all principals that hprop complains
+about.
+
+@samp{hprop -n --source=<NNN>| hpropd -n}
+
+Replace <NNN> with whatever source you have, like krb4-db or krb4-dump.
+
+@item Run a Kerberos 5 slave for a while.
+
+@c XXX Add you slave first to your kdc list in you kdc.
+
+@item Figure out if it does everything you want it to.
+
+Make sure that all things that you use works for you.
+
+@item Let a small number of controlled users use Kerberos 5 tools.
+
+Find a sample population of your users and check what programs they use,
+you can also check the kdc-log to check what ticket are checked out.
+
+@item Burn the bridge and change the master.
+@item Let all users use the Kerberos 5 tools by default.
+@item Turn off services that do not need Kerberos 4 authentication.
+
+Things that might be hard to get away is old programs with support for
+Kerberos 4. Example applications are old Eudora installations using
+KPOP, and Zephyr. Eudora can use the Kerberos 4 kerberos in the Heimdal
+kdc.
+
+@end itemize
diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
new file mode 100644
index 000000000000..85d745684b2a
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on July 17, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
new file mode 100644
index 000000000000..202d44e8639c
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
@@ -0,0 +1,587 @@
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-03.txt              Microsoft 
+Category: Informational                                       June 2000 
+ 
+ 
+           The Windows 2000 RC4-HMAC Kerberos encryption type 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1]. 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. 
+    
+1. Abstract 
+    
+   The Windows 2000 implementation of Kerberos introduces a new 
+   encryption type based on the RC4 encryption algorithm and using an 
+   MD5 HMAC for checksum. This is offered as an alternative to using 
+   the existing DES based encryption types. 
+    
+   The RC4-HMAC encryption types are used to ease upgrade of existing 
+   Windows NT environments, provide strong crypto (128-bit key 
+   lengths), and provide exportable (meet United States government 
+   export restriction requirements) encryption. 
+    
+   The Windows 2000 implementation of Kerberos contains new encryption 
+   and checksum types for two reasons: for export reasons early in the 
+   development process, 56 bit DES encryption could not be exported, 
+   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
+   accounts will not have the appropriate DES keying material to do the 
+   standard DES encryption. Furthermore, 3DES is not available for 
+   export, and there was a desire to use a single flavor of encryption 
+   in the product for both US and international products. 
+    
+   As a result, there are two new encryption types and one new checksum 
+   type introduced in Windows 2000. 
+    
+    
+2. Conventions used in this document 
+    
+
+  
+Swift                  Category - Informational                      1 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+3. Key Generation 
+    
+   On upgrade from existing Windows NT domains, the user accounts would 
+   not have a DES based key available to enable the use of DES base 
+   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
+   the same as the existing Windows NT key (NT Password Hash) for 
+   compatibility reasons. Once the account password is changed, the DES 
+   based keys are created and maintained. Once the DES keys are 
+   available DES based encryption types can be used with Kerberos.  
+    
+   The RC4-HMAC String to key function is defined as follow: 
+    
+   String2Key(password) 
+    
+        K = MD4(UNICODE(password)) 
+         
+   The RC4-HMAC keys are generated by using the Windows UNICODE version 
+   of the password. Each Windows UNICODE character is encoded in 
+   little-endian format of 2 octets each. Then performing an MD4 [6] 
+   hash operation on just the UNICODE characters of the password (not 
+   including the terminating zero octets). 
+    
+   For an account with a password of "foo", this String2Key("foo") will 
+   return: 
+    
+        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
+        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
+    
+4. Basic Operations 
+    
+   The MD5 HMAC function is defined in [3]. It is used in this 
+   encryption type for checksum operations. Refer to [3] for details on 
+   its operation. In this document this function is referred to as 
+   HMAC(Key, Data) returning the checksum using the specified key on 
+   the data. 
+    
+   The basic MD5 hash operation is used in this encryption type and 
+   defined in [7]. In this document this function is referred to as 
+   MD5(Data) returning the checksum of the data. 
+    
+   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
+   compatible cipher is described in [8]. In this document the function 
+   is referred to as RC4(Key, Data) returning the encrypted data using 
+   the specified key on the data. 
+    
+   These encryption types use key derivation as defined in [9] (RFC-
+   1510BIS) in Section titled "Key Derivation". With each message, the 
+   message type (T) is used as a component of the keying material. This 
+   summarizes the different key derivation values used in the various 
+  
+Swift                  Category - Informational                      2 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   operations. Note that these differ from the key derivations used in 
+   other Kerberos encryption types. 
+    
+        T = 1 for TS-ENC-TS in the AS-Request 
+        T = 8 for the AS-Reply  
+        T = 7 for the Authenticator in the TGS-Request 
+        T = 8 for the TGS-Reply  
+        T = 2 for the Server Ticket in the AP-Request 
+        T = 11 for the Authenticator in the AP-Request 
+        T = 12 for the Server returned AP-Reply 
+        T = 15 in the generation of checksum for the MIC token 
+        T = 0 in the generation of sequence number for the MIC token  
+        T = 13 in the generation of checksum for the WRAP token 
+        T = 0 in the generation of sequence number for the WRAP token  
+        T = 0 in the generation of encrypted data for the WRAPPED token 
+    
+   All strings in this document are ASCII unless otherwise specified. 
+   The lengths of ASCII encoded character strings include the trailing 
+   terminator character (0). 
+    
+   The concat(a,b,c,...) function will return the logical concatenation 
+   (left to right) of the values of the arguments. 
+    
+   The nonce(n) function returns a pseudo-random number of "n" octets. 
+    
+5. Checksum Types 
+    
+   There is one checksum type used in this encryption type. The 
+   Kerberos constant for this type is: 
+        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
+    
+   The function is defined as follows: 
+    
+   K - is the Key 
+   T - the message type, encoded as a little-endian four byte integer 
+    
+   CHKSUM(K, T, data) 
+    
+        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
+        tmp = MD5(concat(T, data)) 
+        CHKSUM = HMAC(Ksign, tmp) 
+    
+    
+6. Encryption Types 
+    
+   There are two encryption types used in these encryption types. The 
+   Kerberos constants for these types are: 
+        #define KERB_ETYPE_RC4_HMAC             23 
+        #define KERB_ETYPE_RC4_HMAC_EXP         24 
+    
+   The basic encryption function is defined as follow: 
+    
+   T = the message type, encoded as a little-endian four byte integer. 
+  
+Swift                  Category - Informational                      3 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+    
+        BYTE L40[14] = "fortybits"; 
+        BYTE SK = "signaturekey"; 
+         
+        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 10 + 4, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            add_8_random_bytes(data, data_len, conf_plus_data); 
+            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
+            HMAC (K1, checksum, 16, K3); 
+            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
+            memcpy (edata, checksum, 16); 
+            edata_len = 16 + 8 + data_len; 
+        }         
+         
+        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            HMAC (K1, edata, 16, K3); // checksum is at edata 
+            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
+            data_len = edata_len - 16 - 8; 
+            memcpy (data, edata + 16 + 8, data_len); 
+             
+            // verify generated and received checksums 
+            HMAC (K2, edata + 16, edata_len - 16, checksum); 
+            if (memcmp(edata, checksum, 16) != 0)  
+                printf("CHECKSUM ERROR  !!!!!!\n"); 
+        } 
+    
+   The header field on the encrypted data in KDC messages is: 
+    
+        typedef struct _RC4_MDx_HEADER { 
+            UCHAR Checksum[16]; 
+            UCHAR Confounder[8]; 
+        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
+         
+   The KDC message is encrypted using the ENCRYPT function not 
+   including the Checksum in the RC4_MDx_HEADER. 
+    
+  
+Swift                  Category - Informational                      4 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+7. Key Strength Negotiation 
+    
+   A Kerberos client and server can negotiate over key length if they 
+   are using mutual authentication. If the client is unable to perform 
+   full strength encryption, it may propose a key in the "subkey" field 
+   of the authenticator, using a weaker encryption type. The server 
+   must then either return the same key or suggest its own key in the 
+   subkey field of the AP reply message. The key used to encrypt data 
+   is derived from the key returned by the server. If the client is 
+   able to perform strong encryption but the server is not, it may 
+   propose a subkey in the AP reply without first being sent a subkey 
+   in the authenticator. 
+ 
+8. GSSAPI Kerberos V5 Mechanism Type  
+ 
+8.1 Mechanism Specific Changes 
+    
+   The GSSAPI per-message tokens also require new checksum and 
+   encryption types. The GSS-API per-message tokens must be changed to 
+   support these new encryption types (See [5] Section 1.2.2). The 
+   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
+   is: 
+        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
+    
+   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
+        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
+    
+   The only support quality of protection is: 
+        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
+    
+   In addition, when using an RC4 based encryption type, the sequence 
+   number is sent in big-endian rather than little-endian order. 
+    
+   The Windows 2000 implementation also defines new GSSAPI flags in the 
+   initial token passed when initializing a security context. These 
+   flags are passed in the checksum field of the authenticator (See [5] 
+   Section 1.1.1). 
+    
+   GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s 
+   implementation of DCE RPC, which initially expected three legs of 
+   authentication. Setting this flag causes an extra AP reply to be 
+   sent from the client back to the server after receiving the server’s 
+   AP reply. In addition, the context negotiation tokens do not have 
+   GSSAPI framing - they are raw AP message and do not include object 
+   identifiers. 
+        #define GSS_C_DCE_STYLE                 0x1000 
+    
+
+  
+Swift                  Category - Informational                      5 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
+   server that it should only allow the server application to identify 
+   the client by name and ID, but not to impersonate the client. 
+        #define GSS_C_IDENTIFY_FLAG             0x2000 
+         
+   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
+   client wants to be informed of extended error information. In 
+   particular, Windows 2000 status codes may be returned in the data 
+   field of a Kerberos error message. This allows the client to 
+   understand a server failure more precisely. In addition, the server 
+   may return errors to the client that are normally handled at the 
+   application layer in the server, in order to let the client try to 
+   recover. After receiving an error message, the client may attempt to 
+   resubmit an AP request. 
+        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
+    
+   These flags are only used if a client is aware of these conventions 
+   when using the SSPI on the Windows platform, they are not generally 
+   used by default. 
+    
+   When NetBIOS addresses are used in the GSSAPI, they are identified 
+   by the GSS_C_AF_NETBIOS value. This value is defined as: 
+        #define GSS_C_AF_NETBIOS                0x14 
+   NetBios addresses are 16-octet addresses typically composed of 1 to 
                                                                 th
   15 characters, trailing blank (ascii char 20) filled, with a 16  
+   octet of 0x0. 
+    
+8.2 GSSAPI Checksum Type 
+    
+   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
+   the first 8 octets of the checksum are used. The resulting checksum 
+   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
+   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
+    
+        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
+             MIC_seq, MIC_checksum) 
+        { 
+            HMAC (K, SK, 13, K4); 
+            T = 15; 
+            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
+            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
+                                                // 0101 1100 FFFFFFFF 
+            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
+            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
+            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
+            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K5); 
+            }else{ 
+                HMAC (K, &T, 4, K5); 
+  
+Swift                  Category - Informational                      6 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            } 
+            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
+            HMAC(K5, MIT_checksum, 8, K6); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K6, seq_plus_direction, 8, MIC_seq); 
+        } 
+    
+8.3 GSSAPI Encryption Types 
+    
+   There are two encryption types for GSSAPI message tokens, one that 
+   is 128 bits in strength, and one that is 56 bits in strength as 
+   defined in Section 6. 
+    
+   All padding is rounded up to 1 byte. One byte is needed to say that 
+   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
+   padding. See [5] Section 1.2.2.3. 
+    
+   The encryption mechanism used for GSS wrap based messages is as 
+   follow: 
+    
+    
+        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
+              WRAP_seq, WRAP_checksum, edata, edata_len) 
+        { 
+            HMAC (K, SK, 13, K7); 
+            T = 13; 
+            PAD = 1; 
+            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
+            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
+        FFFFFFFF 
+            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
+            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
+            MD5 (T_hdr_conf_msg_pad, 
+                 4 + 8 + 8 + msg_len + 1, 
+                 MD5_of_T_hdr_conf_msg_pad); 
+            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
+            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
+        bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K8); 
+            }else{ 
+                HMAC (K, &T, 4, K8); 
+            } 
+            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
+            HMAC(K8, WRAP_checksum, 8, K9); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+  
+Swift                  Category - Informational                      7 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
+          
+            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
+        of key with 0xF0 
+            T = 0; 
+            if (fRC4_EXP){ 
+                *(DWORD *)(L40+10) = T; 
+                HMAC(K10, L40, 14, K11); 
+                memset(K11+7, 0xAB, 9); 
+            }else{ 
+                HMAC(K10, &T, 4, K11);  
+            } 
+            HMAC(K11, seq_num, 4, K12); 
+            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
+        edata); /* skip T & hdr */ 
+            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
+         } 
+          
+    
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+9. Security Considerations 
+ 
+   Care must be taken in implementing this encryption type because it 
+   uses a stream cipher. If a different IV isn’t used in each direction 
+   when using a session key, the encryption is weak. By using the 
+   sequence number as an IV, this is avoided. 
+    
+10. Acknowledgements 
+    
+   We would like to thank Salil Dangi for the valuable input in 
+   refining the descriptions of the functions and review input. 
+     
+11. References 
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
+      Message Authentication", RFC 2104, February 1997 
+    
+   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
+      Service (V5)", RFC 1510, September 1993 
+ 
+ 
+  
+Swift                  Category - Informational                      8 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+ 
+   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
+      June 1996 
+ 
+   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
+      1992 
+ 
+   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
+      1992 
+ 
+   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
+      Algorithm", Work in Progress. 
+ 
+   9  RC4 is a proprietary encryption algorithm available under license 
+      from RSA Data Security Inc.  For licensing information, contact: 
+       
+         RSA Data Security, Inc. 
+         100 Marine Parkway 
+         Redwood City, CA 94065-1031 
+ 
+   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      04.txt, June 25, 1999 
+ 
+    
+12. Author's Addresses 
+    
+   Mike Swift 
+   Dept. of Computer Science 
+   Sieg Hall 
+   University of Washington 
+   Seattle, WA 98105 
+   Email: mikesw@cs.washington.edu  
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      9 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+    
+13. Full Copyright Statement 
+ 
+   "Copyright (C) The Internet Society (2000). All Rights Reserved. 
+    
+   This document and translations of it may be copied and          
+   furnished to others, and derivative works that comment on or          
+   otherwise explain it or assist in its implementation may be          
+   prepared, copied, published and distributed, in whole or in          
+   part, without restriction of any kind, provided that the above          
+   copyright notice and this paragraph are included on all such          
+   copies and derivative works.  However, this document itself may          
+   not be modified in any way, such as by removing the copyright          
+   notice or references to the Internet Society or other Internet          
+   organizations, except as needed for the purpose of developing          
+   Internet standards in which case the procedures for copyrights          
+   defined in the Internet Standards process must be followed, or          
+   as required to translate it into languages other than English. 
+    
+   The limited permissions granted above are perpetual and will          
+   not be revoked by the Internet Society or its successors or          
+   assigns. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                     10 
+
diff --git a/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
new file mode 100644
index 000000000000..89e64524c475
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
@@ -0,0 +1,1594 @@
+
+DHC Working Group                                          Ken Hornstein
+INTERNET-DRAFT                                                       NRL
+Category: Standards Track                                      Ted Lemon
+<draft-hornstein-dhc-kerbauth-02.txt>             Internet Engines, Inc.
+20 February 2000                                           Bernard Aboba
+Expires: September 1, 2000                                     Microsoft
+                                                        Jonathan Trostle
+                                                           Cisco Systems
+
+                   DHCP Authentication Via Kerberos V
+
+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.
+
+The distribution of this memo is unlimited.
+
+1.  Copyright Notice
+
+Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+2.  Abstract
+
+The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
+host configuration. In some circumstances, it is useful for the DHCP
+client and server to be able to mutually authenticate as well as to
+guarantee the integrity of DHCP packets in transit.  This document
+describes how Kerberos V may be used in order to allow a DHCP client and
+server to mutually authenticate as well as to protect the integrity of
+the DHCP exchange. The protocol described in this document is capable of
+handling both intra-realm and inter-realm authentication.
+
+
+
+
+
+
+Hornstein, et al.            Standards Track                    [Page 1]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+3.  Introduction
+
+The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
+host configuration. In some circumstances, it is useful for the DHCP
+client and server to be able to mutually authenticate as well as to
+guarantee the integrity of DHCP packets in transit.  This document
+describes how Kerberos V may be used in order to allow a DHCP client and
+server to mutually authenticate as well as to protect the integrity of
+the DHCP exchange.  The protocol described in this document is capable
+of handling both intra-realm and inter-realm authentication.
+
+3.1.  Terminology
+
+This document uses the following terms:
+
+DHCP client
+          A DHCP client or "client" is an Internet host using DHCP to
+          obtain configuration parameters such as a network address.
+
+DHCP server
+          A DHCP server or "server" is an Internet host that returns
+          configuration parameters to DHCP clients.
+
+Home KDC  The KDC corresponding to the DHCP client's realm.
+
+Local KDC The KDC corresponding to the DHCP server's realm.
+
+3.2.  Requirements language
+
+In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
+"recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
+described in [1].
+
+4.  Protocol overview
+
+In DHCP authentication via Kerberos V, DHCP clients and servers utilize
+a Kerberos session key in order to compute a message integrity check
+value included within the DHCP authentication option. The message
+integrity check serves to authenticate as well as integrity protect the
+messages, while remaining compatible with the operation of a DHCP relay.
+Replay protection is also provided by a replay counter within the
+authentication option, as described in [3].
+
+Each server maintains a list of session keys and identifiers for
+clients, so that the server can retrieve the session key and identifier
+used by a client to which the server has provided previous configuration
+information.  Each server MUST save the replay counter from the previous
+authenticated message. To avoid replay attacks, the server MUST discard
+
+
+
+Hornstein, et al.            Standards Track                    [Page 2]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+any incoming message whose replay counter is not strictly greater than
+the replay counter from the previous message.
+
+DHCP authentication, described in [3], must work within the existing
+DHCP state machine described in [4].  For a client in INIT state, this
+means that the client must obtain a valid TGT, as well as a session key,
+within the two round-trips provided by the
+DHCPDISCOVER/OFFER/REQUEST/ACK sequence.
+
+In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP
+server within the DHCPDISCOVER message.  The DHCP server then completes
+the AS_REQ using the IP address to be assigned to the client, and
+submits this to the client's home KDC in order to obtain a TGT on the
+client's behalf. Once the home KDC responds with an AS_REP, the DHCP
+server extracts the client TGT and submits this along with its own TGT
+to the home KDC, in order to obtain a user-to-user ticket to the DHCP
+client. The AS_REP as well as the AP_REQ are included by the DHCP server
+in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain
+a home realm TGT and TGT session key, using the latter to decrypt the
+user-to-user ticket to obtain the user-to-user session key. It is the
+user-to-user session key that is used to authenticate and integrity
+protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly,
+this same session key is used to compute the integrity attribute in the
+server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3].
+
+In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit
+the home realm TGT in the DHCPREQUEST, along with authenticating and
+integrity protecting the message using an integrity attribute within the
+authentication option. The integrity attribute is computed using the
+existing session key.  The DHCP server can then return a renewed user-
+to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST
+message from a client in INIT-REBOOT state can only be validated by
+servers that used the same session key to compute the integrity
+attribute in their DHCPOFFER messages.
+
+Other servers will discard the DHCPREQUEST messages. Thus, only servers
+that used the user-to-user session key selected by the client will be
+able to determine that their offered configuration information was not
+selected, returning the offered network address to the server's pool of
+available addresses.  The servers that cannot validate the DHCPREQUEST
+message will eventually return their offered network addresses to their
+pool of available addresses as described in section 3.1 of the DHCP
+specification [4].
+
+When sending a DHCPINFORM, there are two possible procedures.  If the
+client knows the DHCP server it will be interacting with, then it can
+obtain a ticket to the DHCP server from the local realm KDC. This will
+require obtaining a TGT to its home realm, as well as possibly a cross-
+
+
+
+Hornstein, et al.            Standards Track                    [Page 3]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+realm TGT to the local realm if the local and home realms differ. Once
+the DHCP client has a local realm TGT, it can then request a DHCP server
+ticket in a TGS_REQ. The DHCP client can then include AP_REQ and
+integrity attributes within the DHCPINFORM. The integrity attribute is
+computed as described in [3], using the session key obtained from the
+TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated
+using the same session key.
+
+If the DHCP client does not know the DHCP server it is interacting with
+then it will not be able to obtain a ticket to it and a different
+procedure is needed.  In this case, the client will include in the
+DHCPINFORM an authentication option with a ticket attribute containing
+its home realm TGT. The DHCP server will then use this TGT in order to
+request a user-to-user ticket from the home KDC in a TGS_REQ.  The DHCP
+server will return the user-to-user ticket and will authenticate and
+integrity protect the DHCPACK/DHCPNAK message. This is accomplished by
+including AP_REQ and integrity attributes within the authentication
+option included with the DHCPACK/DHCPNAK messages.
+
+In order to support the DHCP client's ability to authenticate the DHCP
+server in the case where the server name is unknown, the Kerberos
+principal name for the DHCP server must be of type KRB_NT_SRV_HST with
+the service name component equal to 'dhcp'. For example, the DHCP server
+principal name for the host srv.foo.org would be of the form
+dhcp/srv.foo.org.  The client MUST validate that the DHCP server
+principal name has the above format. This convention requires that the
+administrator ensure that non-DHCP server principals do not have names
+that match the above format.
+
+4.1.  Authentication Option Format
+
+A summary of the authentication option  format for DHCP authentication
+via Kerberos V is shown below.  The fields are transmitted from left to
+right.
+
+0                   1                   2                   3
+0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|     Code      |     Length    |   Protocol    | Algorithm     |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                      Global Replay Counter                    |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                      Global Replay Counter                    |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                           Attributes...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Code
+
+
+
+Hornstein, et al.            Standards Track                    [Page 4]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   TBD - DHCP Authentication
+
+Length
+
+   The length field is a single octet and indicates the length of the
+   Protocol, Algorith, and Authentication Information fields.  Octets
+   outside the range of the length field should be ignored on reception.
+
+Protocol
+
+   TBD - DHCP Kerberos V authentication
+
+Algorithm
+
+   The algorithm field is a single octet and defines the specific
+   algorithm to be used for computation of the authentication option.
+   Values for the field are as follows:
+
+   0 - reserved
+   1 - HMAC-MD5
+   2 - HMAC-SHA
+   3 - 255 reserved
+
+Global Replay Counter
+
+   As described in [3], the global replay counter field is 8 octets in
+   length. It MUST be set to the value of a monotonically increasing
+   counter. Using a counter value such as the current time of day (e.g.,
+   an NTP-format timestamp [10]) can reduce the danger of replay
+   attacks.
+
+Attributes
+
+   The attributes field consists of type-length-value attributes of the
+   following format:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |  Reserved     |       Payload Length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Attribute value...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Type
+   The type field is a single octet and is defined as follows:
+
+   0  - Integrity check
+
+
+
+Hornstein, et al.            Standards Track                    [Page 5]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   1  - TICKET
+   2  - Authenticator
+   3  - EncTicketPart
+   10 - AS_REQ
+   11 - AS_REP
+   12 - TGS_REQ
+   13 - TGS_REP
+   14 - AP_REQ
+   15 - AP_REP
+   20 - KRB_SAFE
+   21 - KRB_PRIV
+   22 - KRB_CRED
+   25 - EncASRepPart
+   26 - EncTGSRepPart
+   27 - EncAPRepPart
+   28 - EncKrbPrvPart
+   29 - EncKrbCredPart
+   30 - KRB_ERROR
+
+   Note that the values of the Type field are the same as in the
+   Kerberos MSG-TYPE field. As a result, no new number spaces are
+   created for IANA administration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornstein, et al.            Standards Track                    [Page 6]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   The following attribute types are allowed within the following
+   messages:
+
+   DISCOVER  OFFER  REQUEST  DECLINE   #    Attribute
+   --------------------------------------------------------
+      0        1       1        1      0    Integrity check
+      0        0      0-1       0      1    Ticket
+      1        0       0        0     10    AS_REQ
+      0        1       0        0     11    AS_REP
+      0        1       0        0     14    AP_REQ
+      0       0-1      0        0     30    KRB_ERROR
+
+   RELEASE   ACK   NAK    INFORM   INFORM      #    Attribute
+                          w/known  w/unknown
+                          server   server
+   ---------------------------------------------------------------
+      1       1     1        1        0        0    Integrity check
+      0       0     0        0        1        1    Ticket
+      0       0     0        0        0       10    AS_REQ
+      0       0     0        0        0       11    AS_REP
+      0      0-1    0        1        0       14    AP_REQ
+      0       0    0-1       0        0       30    KRB_ERROR
+
+4.2.  Client behavior
+
+The following section, which incorporates material from [3], describes
+client behavior in detail.
+
+4.2.1.  INIT state
+
+When in INIT state, the client behaves as follows:
+
+
+[1]  As described in [3], the client MUST include the authentication
+     request option in its DHCPDISCOVER message along with option 61
+     [11] to identify itself uniquely to the server. An AS_REQ attribute
+     MUST be included within the authentication request option. This
+     (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags
+     and MAY include pre-authentication data (PADATA) if the client
+     knows what PADATA its home KDC will require. The ADDRESSES field in
+     the AS_REQ will be ommitted since the client does not yet know its
+     IP address. The ETYPE field will be set to an encryption type that
+     the client can accept.
+
+[2]  The client MUST validate DHCPOFFER messages that include an
+     authentication option. Messages including an authentication option
+     with a KRB_ERROR attribute and no integrity attribute are treated
+     as though they are unauthenticated. More typically, authentication
+
+
+
+Hornstein, et al.            Standards Track                    [Page 7]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+     options within the DHCPOFFER message will include AS_REP, AP_REQ,
+     and integrity attributes. To validate the authentication option,
+     the client decrypts the enc-part of the AS_REP in order to obtain
+     the TGT session key. This is used to decrypt the enc-part of the
+     AP_REQ in order to obtain the user-to-user session key. The user-
+     to-user session key is then used to compute the message integrity
+     check as described in [3], and the computed value is compared to
+     the value within the integrity attribute. The client MUST discard
+     any messages which fail to pass validation and MAY log the
+     validation failure.
+
+     As described in [3], the client selects one DHCPOFFER message as
+     its selected configuration. If none of the DHCPOFFER messages
+     received by the client include an authentication option, the client
+     MAY choose an unauthenticated message as its selected
+     configuration.  DHCPOFFER messages including an authentication
+     option with a KRB_ERROR attribute and no integrity attribute are
+     treated as though they are unauthenticated.  The client SHOULD be
+     configurable to accept or reject unauthenticated DHCPOFFER
+     messages.
+
+[3]  The client replies with a DHCPREQUEST message that MUST include an
+     authentication option. The authentication option MUST include an
+     integrity attribute, computed as described in [3], using the user
+     to user session key recovered in step 2.
+
+[4]  As noted in [3], the client MUST validate a DHCPACK message from
+     the server that includes an authentication option. DHCPACK or
+     DHCPNAK messages including an authentication option with a
+     KRB_ERROR attribute and no integrity attribute are treated as
+     though they are unauthenticated. The client MUST silently discard
+     the DHCPACK if the message fails to pass validation and MAY log the
+     validation failure. If the DHCPACK fails to pass validation, the
+     client MUST revert to the INIT state and return to step 1. The
+     client MAY choose to remember which server replied with an invalid
+     DHCPACK message and discard subsequent messages from that server.
+
+4.2.2.  INIT-REBOOT state
+
+When in INIT-REBOOT state, if the user-to-user ticket is still valid,
+the client MUST re-use the session key from the DHCP server user-to-user
+ticket in its DHCPREQUEST message. This is used to generate the
+integrity attribute contained within the authentication option, as
+described in [3]. In the DHCPREQUEST, the DHCP client also includes its
+home realm TGT in a ticket attribute in the authentication option in
+order to assist the DHCP server in renewing the user-to-user ticket.  To
+ensure that the user-to-user ticket remains valid throughout the DHCP
+lease period so that the renewal process can proceed, the Kerberos
+
+
+
+Hornstein, et al.            Standards Track                    [Page 8]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+ticket lifetime SHOULD be set to exceed the DHCP lease time.  If the
+user-to-user ticket is expired, then the client MUST return to the INIT
+state.
+
+The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
+if no authenticated messages were received. DHCPACK/DHCPNAK messages
+with an authentication option containing a KRB_ERROR attribute and no
+integrity attribute are treated as though they are unauthenticated. The
+client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
+messages as specified in section 3.2 of the DHCP specification [4].
+
+4.2.3.  RENEWING state
+
+When in RENEWING state, the DHCP client can be assumed to have a valid
+IP address, as well as a TGT to the home realm, a user-to-user ticket
+provided by the DHCP server, and a session key with the DHCP server, all
+obtained during the original DHCP conversation.  If the user-to-user
+ticket is still valid, the client MUST re-use the session key from the
+user-to-user ticket in its DHCPREQUEST message to generate the integrity
+attribute contained within the authentication option.
+
+Since the DHCP client can renew the TGT to the home realm, it is
+possible for it to continue to hold a valid home realm TGT.  However,
+since the DHCP client did not obtain the user-to-user ticket on its own,
+it will need to rely on the DHCP server to renew this ticket. In the
+DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
+attribute in the authentication option in order to assist the DHCP
+server in renewing the user-to-user ticket.
+
+If the DHCP server user-to-user ticket is expired, then the client MUST
+return to INIT state.  To ensure that the user-to-user ticket remains
+valid throughout the DHCP lease period so that the renewal process can
+proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
+lease time.  If client receives no DHCPACK messages or none of the
+DHCPACK messages pass validation, the client behaves as if it had not
+received a DHCPACK message in section 4.4.5 of the DHCP specification
+[4].
+
+4.2.4.  REBINDING state
+
+When in REBINDING state, the DHCP client can be assumed to have a valid
+IP address, as well as a TGT to the home realm, a user-to-user ticket
+and a session key with the DHCP server, all obtained during the original
+DHCP conversation.  If the user-to-user ticket is still valid, the
+client MUST re-use the session key from the user-to-user ticket in its
+DHCPREQUEST message to generate the integrity attribute contained within
+the authentication option, as described in [3].
+
+
+
+
+Hornstein, et al.            Standards Track                    [Page 9]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+Since the DHCP client can renew the TGT to the home realm, it is
+possible for it to continue to hold a valid home realm TGT.  However,
+since the DHCP client did not obtain the user-to-user ticket on its own,
+it will need to rely on the DHCP server to renew this ticket. In the
+DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
+attribute in the authentication option in order to assist the DHCP
+server in renewing the user-to-user ticket.
+
+If the user-to-user ticket is expired, then the client MUST return to
+INIT state.  To ensure that the user-to-user ticket remains valid
+throughout the DHCP lease period so that the renewal process can
+proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
+lease time.  If client receives no DHCPACK messages or none of the
+DHCPACK messages pass validation, the client behaves as if it had not
+received a DHCPACK message in section 4.4.5 of the DHCP specification
+[4].
+
+4.2.5.  DHCPRELEASE message
+
+Clients sending a DHCPRELEASE MUST include an authentication option. The
+authentication option MUST include an integrity attribute, computed as
+described in [3], using the user to user session key.
+
+4.2.6.  DHCPDECLINE message
+
+Clients sending a DHCPDECLINE MUST include an authentication option. The
+authentication option MUST include an integrity attribute, computed as
+described in [3], using the user to user session key.
+
+4.2.7.  DHCPINFORM message
+
+Since the client already has some configuration information, it can be
+assumed that it has the ability to obtain a home or local realm TGT
+prior to sending the DHCPINFORM.
+
+If the DHCP client knows which DHCP server it will be interacting with,
+then it SHOULD include an authentication option containing AP_REQ and
+integrity attributes within the DHCPINFORM.  The DHCP client first
+requests a TGT to the local realm via an AS_REQ and then using the TGT
+returned in the AS_REP to request a ticket to the DHCP server from the
+local KDC in a TGS_REQ. The session key obtained from the TGS_REP will
+be used to generate the integrity attribute as described in [3].
+
+If the DHCP client does not know what DHCP server it will be talking to,
+then it cannot obtain a ticket to the DHCP server. In this case, the
+DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an
+authentication option including a ticket attribute only.  The ticket
+attribute includes a TGT for the home realm. The client MUST validate
+
+
+
+Hornstein, et al.            Standards Track                   [Page 10]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+that the DHCP server name in the received Kerberos AP_REQ message is of
+the form dhcp/.... as described in section 4.
+
+The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
+if no authenticated messages were received. DHCPACK/DHCPNAK messages
+with an authentication option containing a KRB_ERROR attribute and no
+integrity attribute are treated as though they are unauthenticated. The
+client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
+messages as specified in section 3.2 of the DHCP specification [4].
+
+4.3.  Server behavior
+
+This section, which relies on material from [3], describes the behavior
+of a server in response to client messages.
+
+4.3.1.  After receiving a DHCPDISCOVER message
+
+For installations where IP addresses are required within tickets, the
+DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field
+based on the IP address that it will include in the DHCPOFFER.  The DHCP
+server sends the AS_REQ to the home KDC with the FORWARDABLE flag set.
+The home KDC then replies to the DHCP server with an AS_REP.  The DHCP
+server extracts the client TGT from the AS_REP and forms a TGS_REQ,
+which it sends to  the home KDC.
+
+If the DHCP server and client are in different realms, then the DHCP
+server will need to obtain a TGT to the home realm from the KDC of its
+own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the
+DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag
+set and includes the client home realm TGT in the ADDITIONAL-TICKETS
+field, thus requesting a user-to ticket to the DHCP client.  The home
+KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user
+ticket is encrypted in the client's home realm TGT session key.
+
+In order to recover the user-to-user session key, the DHCP server
+decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP
+server uses the session key that it shares with the home realm, obtained
+in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to
+the home realm.
+
+The DHCP server then sends a DHCPOFFER to the client, including AS_REP,
+AP_REQ and integrity attributes within the authentication option.  The
+AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the
+home KDC. The AP_REQ attribute includes an AP_REQ constructed by the
+DHCP server based on the TGS_REP sent to it by the home KDC. The server
+also includes an integrity attribute generated as specified in [3] from
+the user-to-user session key.  The server MUST record the user-to-user
+session key selected for the client and use that session key for
+
+
+
+Hornstein, et al.            Standards Track                   [Page 11]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+validating subsequent messages with the client.
+
+4.3.2.  After receiving a DHCPREQUEST message
+
+The DHCP server uses the user-to-user session key in order to validate
+the integrity attribute contained within the authentication option,
+using the method specified in [3]. If the message fails to pass
+validation, it MUST discard the message and MAY choose to log the
+validation failure.
+
+If the message passes the validation procedure, the server responds as
+described in [4], including an integrity attribute computed as specified
+in [3] within the DHCPACK or DHCPNAK message.
+
+If the authentication option included within the DHCPREQUEST message
+contains a ticket attribute then the DHCP server will use the home realm
+TGT included in the ticket attribute in order to renew the user-to-user
+ticket, which it returns in an AP_REQ attribute within the DHCPACK.
+DHCPACK or DHCPNAK messages then include an integrity attribute
+generated as specified in [3], using the new user-to-user session key
+included within the AP_REQ.
+
+4.3.3.  After receiving a DHCPINFORM message
+
+The server MAY choose to accept unauthenticated DHCPINFORM messages, or
+only accept authenticated DHCPINFORM messages based on a site policy.
+
+When a client includes an authentication option in a DHCPINFORM message,
+the server MUST respond with an authenticated DHCPACK or DHCPNAK
+message. If the DHCPINFORM message includes an authentication option
+including AP_REQ and integrity attributes, the DHCP server decrypts the
+AP_REQ attribute and then recovers the session key. The DHCP server than
+validates the integrity attribute included in the authentication option
+using the session key. If the integrity attribute is invalid then the
+DHCP server MUST silently discard the DHCPINFORM message.
+
+If the authentication option only includes a ticket attribute and no
+integrity or AP_REQ attributes, then the DHCP server should assume that
+the client needs the server to obtain a user-to-user ticket from the
+home realm KDC.  In this case, the DHCP server includes the client home
+realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC.
+It then receives a user-to-user ticket from the home realm KDC in a
+TGS_REP. The DHCP server will then include AP_REQ and integrity
+attributes within the DHCPACK/DHCPNAK.
+
+If the client does not include an authentication option in the
+DHCPINFORM, the server can either respond with an unauthenticated
+DHCPACK message, or a DHCPNAK if the server does not accept
+
+
+
+Hornstein, et al.            Standards Track                   [Page 12]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+unauthenticated clients.
+
+4.3.4.  After receiving a DHCPRELEASE message
+
+The DHCP server uses the session key in order to validate the integrity
+attribute contained within the authentication option, using the method
+specified in [3]. If the message fails to pass validation, it MUST
+discard the message and MAY choose to log the validation failure.
+
+If the message passes the validation procedure, the server responds as
+described in [4], marking the client's network address as not allocated.
+
+4.3.5.  After receiving a DHCPDECLINE message
+
+The DHCP server uses the session key in order to validate the integrity
+attribute contained within the authentication option, using the method
+specified in [3]. If the message fails to pass validation, it MUST
+discard the message and MAY choose to log the validation failure.
+
+If the message passes the validation procedure, the server proceeds as
+described in [4].
+
+4.4.  Error handling
+
+When an error condition occurs during a Kerberos exchange, Kerberos
+error messages can be returned by either side.  These Kerberos error
+messages MAY be logged by the receiving and sending parties.
+
+In some cases, it may be possible for these error messages to be
+included within the authentication option via the KRB_ERROR attribute.
+However, in most cases, errors will result in messages being silently
+discarded and so no response will be returned.
+
+For example, if the home KDC returns a KRB_ERROR in response to the
+AS_REQ submitted by the DHCP server on the client's behalf, then the
+DHCP server will conclude that the DHCPDISCOVER was not authentic, and
+will silently discard it.
+
+However, if the AS_REQ included PADATA and the home KDC responds with an
+AS_REP, then the DHCP server can conclude that the client is authentic.
+If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by
+the home KDC in the TGS_REP, then the fault may lie with the DHCP server
+rather than with the client. In this case, the DHCP server MAY choose to
+return a KRB_ERROR within the authentication option included in the
+DHCPOFFER. The client will then treat this as an unauthenticated
+DHCPOFFER.
+
+
+
+
+
+Hornstein, et al.            Standards Track                   [Page 13]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+Similarly, if the integrity attribute contained in the DHCPOFFER proves
+invalid, the client will silently discard the DHCPOFFER and instead
+accept an offer from another server if one is available. If the
+integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then
+the client behaves as if it did not receive a DHCPACK/DHCPNAK.
+
+When in INIT-REBOOT, REBINDING or RENEWING state, the client will
+include a ticket attribute and integrity attribute within the
+authentication option of the DHCPREQUEST, in order to assist the DHCP
+server in renewing the user-to-user ticket.  If the integrity attribute
+is invalid, then the DHCP server MUST silently discard the DHCPREQUEST.
+
+However, if the integrity attribute is successfully validated by the
+DHCP server, but the home realm TGT included in the ticket attribute is
+invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in
+response to its TGS_REQ to the home KDC.  In this case, the DHCP server
+MAY respond with a DHCPNAK including a KRB_ERROR attribute and no
+integrity attribute within the authentication option. This will force
+the client back to the INIT state, where it can receive a valid home
+realm TGT.
+
+Where the client included PADATA in the AS_REQ attribute of the
+authentication option within the DHCPDISCOVER and the AS_REQ was
+successfully validated by the KDC, the DHCP server will conclude that
+the DHCP client is authentic. In this case if the client successfully
+validates the integrity attribute in the DHCPOFFER, but the server does
+not validate the integrity attribute in the client's DHCPREQUEST, the
+server MAY choose to respond with an authenticated DHCPNAK containing a
+KRB_ERROR attribute.
+
+4.5.  PKINIT issues
+
+When public key authentication is supported with Kerberos as described
+in [8], the client certificate and a signature accompany the initial
+request in the preauthentication fields.  As a result, it is conceivable
+that the incomplete AS_REQ included in the DHCPDISCOVER packet may
+exceed the size of a single DHCP option, or even the MTU size.  As noted
+in [4], a single option may be as large as 255 octets. If the value to
+be passed is larger than this the client concatenates together the
+values of multiple instances of the same option.
+
+4.6.  Examples
+
+4.6.1.  INIT state
+
+In the intra-realm case where the DHCP Kerberos mutual authentication is
+successful, the conversation will appear as follows:
+
+
+
+
+Hornstein, et al.            Standards Track                   [Page 14]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                      <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                      <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the case where the KDC returns a KRB_ERROR in response to the AS_REQ,
+the server will silently discard the DHCPDISCOVER and the conversation
+will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                     <- KRB_ERROR
+
+In the inter-realm case where the DHCP Kerberos mutual authentication is
+successful, the conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+DHCPDISCOVER
+(Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+
+
+
+Hornstein, et al.            Standards Track                   [Page 15]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                                           <- TGS_REP
+
+                   TGS_REQ
+                    U-2-U ->
+                                <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the case where the client includes PADATA in the AS_REQ attribute
+within the authentication option of the DHCPDISCOVER and the KDC returns
+an error-free AS_REP indicating successful validation of the PADATA, the
+DHCP server will conclude that the DHCP client is authentic.  If the KDC
+then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault
+that lies with the DHCP server, the server MAY choose not to silently
+discard the DHCPDISCOVER.  Instead it MAY respond with a DHCPOFFER
+including a KRB_ERROR attribute within the authentication option. The
+client will then treat this as an unauthenticated DHCPOFFER.  The
+conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ
+ w/PADATA)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- KRB_ERROR
+                <- DHCPOFFER,
+                    (KRB_ERROR)
+DHCPREQUEST ->
+                <- DHCPACK
+
+In the intra-realm case where the client included PADATA in the AS_REQ
+attribute of the authentication option and the AS_REQ was successfully
+validated by the KDC, the DHCP server will conclude that the DHCP client
+is authentic. In this case if the client successfully validates the
+integrity attribute in the DHCPOFFER, but the server does not validate
+the integrity attribute in the client's DHCPREQUEST, the server MAY
+
+
+
+Hornstein, et al.            Standards Track                   [Page 16]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+choose to respond with an authenticated DHCPNAK containing a KRB_ERROR
+attribute.  The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ
+ w/PADATA)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCNAK
+                    (KRB_ERROR,
+                     Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+In the intra-realm case where the DHCP client cannot validate the
+integrity attribute in the DHCPOFFER, the client silently discards the
+DHCPOFFER. The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPOFFER,
+                   (AS_REP,
+                   AP_REQ,
+                   Integrity)
+DHCPREQUEST
+
+
+
+Hornstein, et al.            Standards Track                   [Page 17]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+ [To another server]
+ (Integrity) ->
+
+In the intra-realm case where the DHCP client cannot validate the
+integrity attribute in the DHCPACK, the client reverts to INIT state.
+The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+(Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+4.6.2.  INIT-REBOOT, RENEWING or REBINDING
+
+In the intra-realm or inter-realm case where the original user-to-user
+ticket is still valid, and the DHCP server still has a valid TGT to the
+home realm, the conversation will appear as follows:
+
+   DHCP               DHCP             Home
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+
+
+
+Hornstein, et al.            Standards Track                   [Page 18]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                    Integrity)
+
+In the intra-realm or inter-realm case where the DHCP server validates
+the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in
+response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to
+silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK
+to the client instead, using the user-to-user session key previously
+established with the client. The conversation appears as follows:
+
+   DHCP               DHCP             Home
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+                   TGS_REQ
+                    U-2-U ->
+                                     <- KRB_ERROR
+                <- DHCPNAK
+                    (KRB_ERROR,
+                    Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+In the intra-realm or inter-realm case where the DHCP server cannot
+validate the integrity attribute in the DHCPREQUEST, the DHCP server
+MUST silently discard the DHCPREQUEST and the conversation will appear
+as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+                   Silent discard
+[Sequence repeats
+ until timeout]
+
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+In the intra-realm or inter-realm case where the original user-to-user
+ticket is still valid, the server validates the integrity attribute in
+
+
+
+Hornstein, et al.            Standards Track                   [Page 19]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+the DHCPREQUEST, but the client fails to validate the integrity
+attribute in the DHCPACK, the client will silently discard the DHCPACK.
+The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+4.6.3.  DHCPINFORM (with known DHCP server)
+
+In the case where the DHCP client knows the DHCP server it will be
+interacting with, the DHCP client will obtain a ticket to the DHCP
+server and will include AP_REQ and integrity attributes within the
+DHCPINFORM.
+
+Where the DHCP Kerberos mutual authentication is successful, the
+conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+AS_REQ ->
+                                     <- AS_REP
+TGS_REQ ->
+                                     <- TGS_REP
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the inter-realm case where the DHCP Kerberos mutual authentication is
+successful, the conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+
+
+
+Hornstein, et al.            Standards Track                   [Page 20]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+AS_REQ ->
+                                          <- AS_REP
+TGS_REQ ->
+                                          <- TGS_REP
+TGS_REQ ->
+                               <- TGS_REP
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the inter-realm case where the DHCP server fails to validate the
+integrity attribute in the DHCPINFORM, the server MUST silently discard
+the DHCPINFORM. The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+TGS_REQ ->
+                                          <- TGS_REP
+TGS_REQ ->
+                               <- TGS_REP
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+
+In the inter-realm case where the DHCP client fails to validate the
+integrity attribute in the DHCPACK, the client MUST silently discard the
+DHCPACK.  The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+TGS_REQ ->
+                                          <- TGS_REP
+TGS_REQ ->
+                               <- TGS_REP
+DHCPINFORM
+
+
+
+Hornstein, et al.            Standards Track                   [Page 21]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+ (AP_REQ,
+ Integrity) ->
+
+4.6.4.  DHCPINFORM (with unknown DHCP server)
+
+In the case where the DHCP client does not know the DHCP server it will
+be interacting with, the DHCP client will only include a ticket
+attribute within the DHCPINFORM.  Thus the DHCP server will not be able
+to validate the authentication option.
+
+Where the DHCP client is able to validate the DHCPACK and no error
+occur, the onversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+AS_REQ ->
+                                     <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+
+In the inter-realm case where the DHCP server needs to obtain a TGT to
+the home realm, and where the client successfully validates the DHCPACK,
+the conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+                                           <- TGS_REP
+
+                   TGS_REQ
+                    U-2-U ->
+
+
+
+Hornstein, et al.            Standards Track                   [Page 22]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                                <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+
+In the inter-realm case where the local KDC returns a KRB_ERROR in
+response to the TGS_REQ from the DHCP server, the DHCP server MAY return
+a KRB_ERROR within the DHCP authentication option included in a DHCPNAK.
+The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+                                           <- KRB_ERROR
+                <- DHCPNAK
+                    (KRB_ERROR)
+
+
+In the inter-realm case where the DHCP client fails to validate the
+integrity attribute in the DHCPACK, the client MUST silently discard the
+DHCPACK.  The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+                                           <- TGS_REP
+
+                   TGS_REQ
+
+
+
+Hornstein, et al.            Standards Track                   [Page 23]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                    U-2-U ->
+                                <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+DHCPINFORM
+ (Ticket) ->
+
+5.  References
+
+
+[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+     Levels", BCP 14, RFC 2119, March 1997.
+
+[2]  Kohl, J., Neuman, C., "The Kerberos Network Authentication Service
+     (V5)", RFC 1510, September 1993.
+
+[3]  Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
+     Internet draft (work in progress), draft-ietf-dhc-
+     authentication-11.txt, June 1999.
+
+[4]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
+     1997.
+
+[5]  Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
+     Extensions", RFC 2132, March 1997.
+
+[6]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
+
+[7]  Jain, V., Congdon, P., Roese, J., "Network Port Authentication",
+     IEEE 802.1 PAR submission, June 1999.
+
+[8]  Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray,
+     J., Trostle, J., "Public Key Cryptography for Initial
+     Authentication in Kerberos", Internet draft (work in progress),
+     draft-ietf-cat-kerberos-pk-init-09.txt, June 1999.
+
+[9]  Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B.,
+     Medvinsky, A., Hur, M.,  "Public Key Cryptography for Cross-Realm
+     Authentication in Kerberos", Internet draft (work in progress),
+     draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999.
+
+[10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
+     1992.
+
+[11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft
+     (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt,
+     November 1998.
+
+
+
+Hornstein, et al.            Standards Track                   [Page 24]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+6.  Security Considerations
+
+DHCP authentication, described in [3], addresses the following threats:
+
+     Modification of messages
+     Rogue servers
+     Unauthorized clients
+
+This section describes how DHCP authentication via Kerberos V addresses
+each of these threats.
+
+6.1.  Client security
+
+As noted in [3], it may be desirable to ensure that IP addresses are
+only allocated to authorized clients. This can serve to protect against
+denial of service attacks. To address this issue it is necessary for
+DHCP client messages to be authenticated. In order to guard against
+message modification, it is also necessary for DHCP client messages to
+be integrity protected.
+
+Note that this protocol does not make use of KRB_SAFE, so as to allow
+modification of mutable fields by the DHCP relay. Replay protection is
+therefore provided within the DHCP authentication option itself.
+
+In DHCP authentication via Kerberos V the DHCP client will authenticate,
+integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and
+DHCPRELEASE messages using a user-to-user session key obtained by the
+DHCP server from the home KDC. If the DHCP client knows the DHCP server
+it will be interacting with, then the DHCP client MAY also authenticate,
+integrity and replay-protect the DHCPINFORM message using a session key
+obtained from the local realm KDC for the DHCP server it expects to
+converse with.
+
+Since the client has not yet obtained a session key, DHCPDISCOVER
+packets cannot be authenticated using the session key. However, the
+client MAY include pre-authentication data in the PADATA field included
+in the DHCPDISCOVER packet. Since the PADATA will then be used by the
+DHCP server to request a ticket on the client's behalf, the DHCP server
+will learn from the AS_REP whether the PADATA was acceptable or not.
+Therefore in this case, the DHCPDISCOVER will be authenticated but not
+integrity protected.
+
+Where the DHCP client does not know the DHCP server it will be
+interacting with ahead of time, the DHCPINFORM message will not be
+authenticated, integrity or replay protected.
+
+Note that snooping of PADATA and TGTs on the wire may provide an
+attacker with a means of mounting a dictionary attack, since these items
+
+
+
+Hornstein, et al.            Standards Track                   [Page 25]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+are typically encrypted with a key derived from the user's password.
+Thus use of strong passwords and/or pre-authentication methods utilizing
+strong cryptography (see [8]) are recommended.
+
+6.2.  Network access control
+
+DHCP authentication has been proposed as a method of limiting access to
+network media that are not physically secured such as wireless LANs and
+ports in college residence halls.  However, it is not particularly well
+suited to this purpose since even if address allocation is denied an
+inauthentic client may use a statically assigned IP address instead, or
+may attempt to access the network using non-IP protocols.  As a result,
+other methods, described in [6]-[7], have been proposed for controlling
+access to wireless media and switched LANs.
+
+6.3.  Server security
+
+As noted in [3], it may be desirable to protect against rogue DHCP
+servers put on the network either intentionally or by accident.  To
+address this issue it is necessary for DHCP server messages to be
+authenticated. In order to guard against message modification, it is
+also necessary for DHCP server messages to be integrity protected.
+Replay protection is also provided within the DHCP authentication
+option.
+
+All messages sent by the DHCP server are authenticated and integrity and
+replaly protected using a session key.  This includes the DHCPOFFER,
+DHCPACK, and DHCPNAK messages.  The session key is used to compute the
+DHCP authentication option, which is verified by the client.
+
+In order to provide protection against rogue servers it is necessary to
+prevent rogue servers from obtaining the credentials necessary to act as
+a DHCP server. As noted in Section 4, the Kerberos principal name for
+the DHCP server  must be of type KRB_NT_SRV_HST with  the service name
+component equal to 'dhcp'. The client MUST validate that the DHCP server
+principal name has the above  format. This convention requires that the
+administrator ensure that non-DHCP  server principals do not have names
+that match the above format.
+
+7.  IANA Considerations
+
+This draft does not create any new number spaces for IANA
+administration.
+
+8.  Acknowledgements
+
+The authors would like to acknowledge Ralph Droms and William Arbaugh,
+authors of the DHCP authentication draft [3]. This draft incorporates
+
+
+
+Hornstein, et al.            Standards Track                   [Page 26]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+material from their work; however, any mistakes in this document are
+solely the responsibility of the authors.
+
+9.  Authors' Addresses
+
+Ken Hornstein
+US Naval Research Laboratory
+Bldg A-49, Room 2
+4555 Overlook Avenue
+Washington DC  20375 USA
+
+Phone: +1 (202) 404-4765
+EMail: kenh@cmf.nrl.navy.mil
+
+Ted Lemon
+Internet Engines, Inc.
+950 Charter Street
+Redwood City, CA 94063
+
+Phone: +1 (650) 779 6031
+Email: mellon@iengines.net
+
+Bernard Aboba
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+Phone: +1 (425) 936-6605
+EMail: bernarda@microsoft.com
+
+Jonathan Trostle
+170 W. Tasman Dr.
+San Jose, CA 95134, U.S.A.
+
+Email: jtrostle@cisco.com
+Phone: +1 (408) 527-6201
+
+
+10.  Intellectual Property Statement
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to  pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights.  Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11.  Copies of claims of
+
+
+
+Hornstein, et al.            Standards Track                   [Page 27]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard.  Please address the information to the IETF Executive
+Director.
+
+11.  Full Copyright Statement
+
+Copyright (C) The Internet Society (2000).  All Rights Reserved.
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it or
+assist in its implmentation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are included
+on all such copies and derivative works.  However, this document itself
+may not be modified in any way, such as by removing the copyright notice
+or references to the Internet Society or other Internet organizations,
+except as needed for the purpose of developing Internet standards in
+which case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to translate it into
+languages other than English.  The limited permissions granted above are
+perpetual and will not be revoked by the Internet Society or its
+successors or assigns.  This document and the information contained
+herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
+INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+12.  Expiration Date
+
+This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>,  and
+expires October 1, 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Hornstein, et al.            Standards Track                   [Page 28]
+
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt
new file mode 100644
index 000000000000..208d057f24c8
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt
@@ -0,0 +1,301 @@
+INTERNET-DRAFT                                        Mike Swift
+draft-ietf-cat-iakerb-04.txt                          Microsoft
+Updates: RFC 1510                                     Jonathan Trostle
+July 2000					      Cisco Systems
+                                  
+
+         Initial Authentication and Pass Through Authentication 
+                Using Kerberos V5 and the GSS-API (IAKERB)
+
+
+0. 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.
+
+   This draft expires on January 31st, 2001.
+
+
+1. Abstract
+
+   This document defines an extension to the Kerberos protocol
+   specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 
+   1964 [2]) that enables a client to obtain Kerberos tickets for 
+   services where:
+
+   (1) The client knows its principal name and password, but not
+   its realm name (applicable in the situation where a user is already 
+   on the network but needs to authenticate to an ISP, and the user  
+   does not know his ISP realm name).
+   (2) The client is able to obtain the IP address of the service in 
+   a realm which it wants to send a request to, but is otherwise unable 
+   to locate or communicate with a KDC in the service realm or one of 
+   the intermediate realms. (One example would be a dial up user who 
+   does not have direct IP connectivity).
+   (3) The client does not know the realm name of the service.
+
+
+2. Motivation
+
+   When authenticating using Kerberos V5, clients obtain tickets from
+   a KDC and present them to services. This method of operation works
+
+   well in many situations, but is not always applicable since it
+   requires the client to know its own realm, the realm of the target 
+   service, the names of the KDC's, and to be able to connect to the 
+   KDC's. 
+  
+   This document defines an extension to the Kerberos protocol
+   specification (RFC 1510) [1] that enables a client to obtain
+   Kerberos tickets for services where:
+
+   (1) The client knows its principal name and password, but not
+   its realm name (applicable in the situation where a user is already 
+   on the network but needs to authenticate to an ISP, and the user 
+   does not know his ISP realm name).
+   (2) The client is able to obtain the IP address of the service in 
+   a realm which it wants to send a request to, but is otherwise unable 
+   to locate or communicate with a KDC in the service realm or one of 
+   the intermediate realms. (One example would be a dial up user who 
+   does not have direct IP connectivity).
+   (3) The client does not know the realm name of the service.
+
+   In this proposal, the client sends KDC request messages directly 
+   to application servers if one of the above failure cases develops. 
+   The application server acts as a proxy, forwarding messages back
+   and forth between the client and various KDC's (see Figure 1).
+
+
+           Client <---------> App Server <----------> KDC
+                               proxies
+
+
+                     Figure 1: IAKERB proxying
+
+
+   In the case where the client has sent a TGS_REQ message to the 
+   application server without a realm name in the request, the 
+   application server will forward an error message to the client 
+   with its realm name in the e-data field of the error message. 
+   The client will attempt to proceed using conventional Kerberos. 
+
+3. When Clients Should Use IAKERB
+
+   We list several, but possibly not all, cases where the client
+   should use IAKERB. In general, the existing Kerberos paradigm
+   where clients contact the KDC to obtain service tickets should
+   be preserved where possible.
+
+   (a) AS_REQ cases:
+
+   (i) The client is unable to locate the user's KDC or the KDC's
+   in the user's realm are not responding, or
+   (ii) The user has not entered a name which can be converted 
+   into a realm name (and the realm name cannot be derived from
+   a certificate). 
+
+   (b) TGS_REQ cases:
+
+   (i) the client determines that the KDC(s) in either an 
+   intermediate realm or the service realm are not responding or
+
+   the client is unable to locate a KDC, 
+
+   (ii) the client is not able to generate the application server 
+   realm name. 
+
+
+4. GSSAPI Encapsulation
+
+   The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the 
+   mechanism proposed by SPNEGO for negotiating protocol variations, is:
+   {iso(1) member-body(2) United States(840) mit(113554) infosys(1) 
+   gssapi(2) krb5(2) initialauth(4)}
+
+   The AS request, AS reply, TGS request, and TGS reply messages are all 
+   encapsulated using the format defined by RFC1964 [2].  This consists 
+   of the GSS-API token framing defined in appendix B of RFC1508 [3]: 
+
+   InitialContextToken ::= 
+   [APPLICATION 0] IMPLICIT SEQUENCE { 
+           thisMech        MechType 
+                   -- MechType is OBJECT IDENTIFIER 
+                   -- representing "Kerberos V5" 
+           innerContextToken ANY DEFINED BY thisMech
+                   -- contents mechanism-specific;
+                   -- ASN.1 usage within innerContextToken
+                   -- is not required
+           }
+
+   The innerContextToken consists of a 2-byte TOK_ID field (defined 
+   below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, 
+   KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field
+   shall be one of the following values, to denote that the message is 
+   either a request to the KDC or a response from the KDC.
+
+   Message         TOK_ID
+   KRB-KDC-REQ      00 03
+   KRB-KDC-REP      01 03
+   
+
+5. The Protocol
+
+   a. The user supplies a password (AS_REQ): Here the Kerberos client
+      will send an AS_REQ message to the application server if it cannot
+      locate a KDC for the user's realm, or such KDC's do not respond,
+      or the user does not enter a name from which the client can derive
+      the user's realm name. The client sets the realm field of the 
+      request equal to its own realm if the realm name is known, 
+      otherwise the realm length is set to 0. Upon receipt of the AS_REQ 
+      message, the application server checks if the client has included 
+      a realm. 
+
+      If the realm was not included in the original request, the 
+      application server must determine the realm and add it to the 
+      AS_REQ message before forwarding it. If the application server 
+      cannot determine the client realm, it returns the 
+      KRB_AP_ERR_REALM_REQUIRED error-code in an error message to 
+      the client:
+
+            KRB_AP_ERR_REALM_REQUIRED         77  
+
+      The error message can be sent in response to either an AS_REQ
+      message, or in response to a TGS_REQ message, in which case the 
+      realm and principal name of the application server are placed
+      into the realm and sname fields respectively, of the KRB-ERROR 
+      message. In the AS_REQ case, once the realm is filled in, the 
+      application server forwards the request to a KDC in the user's 
+      realm. It will retry the request if necessary, and forward the 
+      KDC response back to the client.
+
+      At the time the user enters a username and password, the client
+      should create a new credential with an INTERNAL NAME [3] that can
+      be used as an input into the GSS_Acquire_cred function call.
+
+      This functionality is useful when there is no trust relationship
+      between the user's logon realm and the target realm (Figure 2).
+
+
+                                     User Realm KDC        
+                                      /                
+                                     /                
+                                    /                
+                                   / 2,3   
+                      1,4         /      
+           Client<-------------->App Server
+
+
+      1 Client sends AS_REQ to App Server
+      2 App server forwards AS_REQ to User Realm KDC
+      3 App server receives AS_REP from User Realm KDC
+      4 App server sends AS_REP back to Client
+
+
+                      Figure 2: IAKERB AS_REQ
+
+
+
+   b. The user does not supply a password (TGS_REQ): The user includes a 
+      TGT targetted at the user's realm, or an intermediate realm, in a 
+      TGS_REQ message. The TGS_REQ message is sent to the application 
+      server. 
+
+      If the client has included the realm name in the TGS request, then
+      the application server will forward the request to a KDC in the
+      request TGT srealm. It will forward the response back to the client.
+
+      If the client has not included the realm name in the TGS request,
+      then the application server will return its realm name and principal 
+      name to the client using the KRB_AP_ERR_REALM_REQUIRED error 
+      described above. Sending a TGS_REQ message to the application server 
+      without a realm name in the request, followed by a TGS request using 
+      the returned realm name and then sending an AP request with a mutual 
+      authentication flag should be subject to a local policy decision 
+      (see security considerations below). Using the returned server 
+      principal name in a TGS request followed by sending an AP request 
+      message using the received ticket MUST NOT set any mutual 
+      authentication flags.
+
+
+6. Addresses in Tickets
+
+   In IAKERB, the machine sending requests to the KDC is the server and 
+   not the client. As a result, the client should not include its 
+   addresses in any KDC requests for two reasons. First, the KDC may
+   reject the forwarded request as being from the wrong client. Second,
+   in the case of initial authentication for a dial-up client, the client
+   machine may not yet possess a network address. Hence, as allowed by 
+   RFC1510 [1], the addresses field of the AS and TGS requests should be
+   blank and the caddr field of the ticket should similarly be left blank. 
+
+
+7. Combining IAKERB with Other Kerberos Extensions
+   
+   This protocol is usable with other proposed Kerberos extensions such as 
+   PKINIT (Public Key Cryptography for Initial Authentication in Kerberos 
+   [4]). In such cases, the messages which would normally be sent to the 
+   KDC by the GSS runtime are instead sent by the client application to the 
+   server, which then forwards them to a KDC.
+
+
+8. Security Considerations
+
+   A principal is identified by its principal name and realm. A client
+   that sends a TGS request to an application server without the request
+   realm name will only be able to mutually authenticate the server
+   up to its principal name. Thus when requesting mutual authentication, 
+   it is preferable if clients can either determine the server realm name 
+   beforehand, or apply some policy checks to the realm name obtained from 
+   the returned error message.
+   
+
+9. Bibliography
+ 
+   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
+   Service (V5). Request for Comments 1510.
+
+   [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism. Request 
+   for Comments 1964 
+
+   [3]  J. Linn. Generic Security Service Application Program Interface.  
+   Request for Comments 1508 
+
+   [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 
+   J. Trostle, Public Key Cryptography for Initial Authentication in 
+   Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-
+   pkinit-10.txt.
+
+
+10. This draft expires on January 31st, 2001. 
+
+
+11. Authors' Addresses
+
+   Michael Swift
+   Microsoft
+   One Microsoft Way
+   Redmond, Washington, 98052, U.S.A.
+   Email: mikesw@microsoft.com
+
+   Jonathan Trostle
+   170 W. Tasman Dr. 
+   San Jose, CA 95134, U.S.A.
+   Email: jtrostle@cisco.com
+   Phone: (408) 527-6201
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
new file mode 100644
index 000000000000..b3ec336b6513
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
@@ -0,0 +1,174 @@
+INTERNET-DRAFT                                        Jonathan Trostle
+draft-ietf-cat-kerberos-extra-tgt-02.txt              Cisco Systems
+Updates: RFC 1510                                     Michael M. Swift
+expires January 30, 2000                              University of WA
+
+
+    Extension to Kerberos V5 For Additional Initial Encryption
+
+0. 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.
+
+1. Abstract
+
+   This document defines an extension to the Kerberos protocol
+   specification (RFC 1510) [1] to enable a preauthentication field in
+   the AS_REQ message to carry a ticket granting ticket. The session
+   key from this ticket granting ticket will be used to
+   cryptographically strengthen the initial exchange in either the
+   conventional Kerberos V5 case or in the case the user stores their
+   encrypted private key on the KDC [2].
+
+
+2. Motivation
+
+   In Kerberos V5, the initial exchange with the KDC consists of the
+   AS_REQ and AS_REP messages. For users, the encrypted part of the
+   AS_REP message is encrypted in a key derived from a password.
+   Although a password policy may be in place to prevent dictionary
+   attacks, brute force attacks may still be a concern due to
+   insufficient key length.
+
+   This draft specifies an extension to the Kerberos V5 protocol to
+   allow a ticket granting ticket to be included in an AS_REQ message
+   preauthentication field. The session key from this ticket granting
+   ticket will be used to cryptographically strengthen the initial
+
+   exchange in either the conventional Kerberos V5 case or in the case
+   the user stores their encrypted private key on the KDC [2]. The
+   session key from the ticket granting ticket is combined with the
+   user password key (key K2 in the encrypted private key on KDC
+   option) using HMAC to obtain a new triple des key that is used in
+   place of the user key in the initial exchange. The ticket granting
+   ticket could be obtained by the workstation using its host key.
+
+3. The Extension
+
+   The following new preauthentication type is proposed:
+
+      PA-EXTRA-TGT                         22
+
+   The preauthentication-data field contains a ticket granting ticket
+   encoded as an ASN.1 octet string. The server realm of the ticket
+   granting ticket must be equal to the realm in the KDC-REQ-BODY of
+   the AS_REQ message. In the absence of a trust relationship, the
+   local Kerberos client should send the AS_REQ message without this
+   extension.
+
+   In the conventional (non-pkinit) case, we require the RFC 1510
+   PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
+   If neither it or the PA-PK-KEY-REQ preauthentication field is
+   included in the AS_REQ message, the KDC will reply with a
+   KDC_ERR_PREAUTH_FAILED error message.
+
+   We propose the following new etypes:
+
+     des3-cbc-md5-xor                              16
+     des3-cbc-sha1-xor                             17
+
+   The encryption key is obtained by:
+
+   (1) Obtaining an output M from the HMAC-SHA1 function [3] using
+       the user password key (the key K2 in the encrypted private
+       key on KDC option of pkinit) as the text and the triple des
+       session key as the K input in HMAC:
+
+       M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
+
+       The session key from the accompanying ticket granting ticket
+       must be a triple des key when one of the triple des xor
+       encryption types is used.
+   (2) Concatenate the output M (20 bytes) with the first 8 non-parity
+       bits of the triple-des ticket granting ticket session key to
+       get 168 bits that will be used for the new triple-des encryption
+       key.
+   (3) Set the parity bits of the resulting key.
+
+   The resulting triple des key is used to encrypt the timestamp
+   for the PA-ENC-TIMESTAMP preauthentication value (or in the
+   encrypted private key on KDC option of pkinit, it is used in
+   place of the key K2 to both sign in the PA-PK-KEY-REQ and for
+   encryption in the PA-PK-KEY-REP preauthentication types).
+
+   If the KDC decrypts the encrypted timestamp and it is not within
+   the appropriate clock skew period, the KDC will reply with the
+   KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
+   the above ticket granting ticket fails to decrypt properly, or if
+   it is not a valid ticket.
+
+   The KDC will create the shared triple des key from the ticket
+   granting ticket session key and the user password key (the key K2
+   in the encrypted private key on KDC case) using HMAC as specified
+   above and use it to validate the AS_REQ message and then to
+   encrypt the encrypted part of the AS_REP message (use it in place
+   of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
+   field).
+
+   Local workstation policy will determine the exact behaviour of
+   the Kerberos client with respect to the extension protocol. For
+   example, the client should consult policy to decide when to use
+   use the extension. This policy could be dependent on the user
+   identity, or whether the workstation is in the same realm as the
+   user. One possibility is for the workstation logon to fail if
+   the extension is not used. Another possibility is for the KDC
+   to set a flag in tickets issued when this extension is used.
+
+   A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
+   preauthentication field containing a ticket granting ticket,
+   a randomly generated subkey encrypted in the session key from
+   the ticket, and a timestamp structure encrypted in the user
+   password and then the randomly generated subkey was proposed.
+   Some advantages of the current proposal are that the KDC has two
+   fewer decryptions to perform per request and the client does not
+   have to generate a random key.
+
+4. Bibliography
+
+   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
+   Service (V5). Request for Comments 1510.
+
+   [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
+   Public Key Cryptography for Initial Authentication in Kerberos.
+   ftp://ds.internic.net/internet-drafts/
+   draft-ietf-cat-kerberos-pkinit-08.txt
+
+   [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
+   Message Authentication. Request for Comments 2104.
+
+   [4] J. Pato. Using Pre-authentication to Avoid Password Guessing
+   Attacks. OSF DCE SIG Request for Comments 26.0.
+
+5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
+
+6. Expires January 30, 2000.
+
+7. Authors' Addresses
+
+   Jonathan Trostle
+   170 W. Tasman Dr.
+   San Jose, CA 95134, U.S.A.
+
+   Email: jtrostle@cisco.com
+   Phone: (408) 527-6201
+
+   Michael Swift
+   Email: mikesw@cs.washington.edu
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
new file mode 100644
index 000000000000..d09a2ded5bc5
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
new file mode 100644
index 000000000000..1ab2b03e079d
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
@@ -0,0 +1,523 @@
+
+INTERNET-DRAFT                                               Matthew Hur
+draft-ietf-cat-kerberos-pk-cross-06.txt            CyberSafe Corporation
+Updates: RFC 1510                                             Brian Tung
+expires October 10, 2000                                  Tatyana Ryutov
+                                                         Clifford Neuman
+                                                             Gene Tsudik
+                                                                     ISI
+                                                           Ari Medvinsky
+                                                                Keen.com
+                                                         Bill Sommerfeld
+                                                         Hewlett-Packard
+
+
+    Public Key Cryptography for Cross-Realm Authentication in Kerberos
+
+
+0.  Status Of this Memo
+
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC 2026.  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 on ftp.ietf.org (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-cross-06.txt, and expires May 15, 1999.
+    Please send comments to the authors.
+
+
+1.  Abstract
+
+    This document defines extensions to the Kerberos protocol 
+    specification [1] to provide a method for using public key 
+    cryptography to enable cross-realm authentication.  The methods 
+    defined here specify the way in which message exchanges are to be 
+    used to transport cross-realm secret keys protected by encryption 
+    under public keys certified as belonging to KDCs.
+
+
+2.  Introduction
+
+    The Kerberos authentication protocol [2]  can leverage the 
+    advantages provided by public key cryptography.  PKINIT [3] 
+    describes the use of public key cryptography in the initial 
+    authentication exchange in Kerberos.  PKTAPP [4] describes how an 
+    application service can essentially issue a kerberos ticket to 
+    itself after utilizing public key cryptography for authentication. 
+    Another informational document species the use of public key 
+    crypography for anonymous authentication in Kerberos [5].  This 
+    specification describes the use of public key crpytography in cross- 
+    realm authentication.
+
+    Without the use of public key cryptography, administrators must 
+    maintain separate keys for every realm which wishes to exchange 
+    authentication information with another realm (which implies n(n-1) 
+    keys), or they must utilize a hierachichal arrangement of realms, 
+    which may complicate the trust model by requiring evaluation of 
+    transited realms.
+
+    Even with the multi-hop cross-realm authentication, there must be 
+    some way to locate the path by which separate realms are to be 
+    transited.  The current method, which makes use of the DNS-like 
+    realm names typical to Kerberos, requires trust of the intermediate 
+    KDCs.
+
+    PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify 
+    the administrative burden of maintaining cross-realm keys.  Such 
+    usage leverages a PKI for a non-centrally-administratable environment 
+    (namely, inter-realm).  Thus, a shared key for cross-realm 
+    authentication can be established for a set period of time, and a 
+    remote realm is able to issue policy information that is returned to 
+    itself when a client requests cross-realm authentication. Such policy 
+    information may be in the form of restrictions [7].  Furthermore, 
+    these methods are transparent to the client; therefore, only the KDCs 
+    need to be modified to use them.  In this way, we take advantage of 
+    the the distributed trust management capabilities of public key 
+    crypography while maintaining the advantages of localized trust 
+    management provided by Kerberos.
+
+
+    Although this specification utilizes the protocol specfied in the 
+    PKINIT specification, it is not necessary to implement client 
+    changes in order to make use of the changes in this document.
+
+
+3.  Objectives
+
+    The objectives of this specification are as follows:
+    
+      1.  Simplify the administration required to establish Kerberos
+          cross-realm keys.
+          
+      2.  Avoid modification of clients and application servers.
+
+      3.  Allow remote KDC to control its policy on cross-realm
+          keys shared between KDCs, and on cross-realm tickets
+          presented by clients.
+
+      4.  Remove any need for KDCs to maintain state about keys
+          shared with other KDCs.
+
+      5.  Leverage the work done for PKINIT to provide the public key
+          protocol for establishing symmetric cross realm keys.
+
+
+4.  Definitions
+
+    The following notation is used throughout this specification:
+    KDC_l ........... local KDC
+    KDC_r ........... remote KDC
+    XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the
+                      local KDC
+    TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the
+                      client for presentation to the remote KDC
+
+    This specification defines the following new types to be added to the 
+    Kerberos specification:
+      PKCROSS kdc-options field in the AS_REQ is bit 9
+      TE-TYPE-PKCROSS-KDC       2
+      TE-TYPE-PKCROSS-CLIENT    3
+
+    This specification defines the following ASN.1 type for conveying
+    policy information:
+    CrossRealmTktData ::= SEQUENCE OF TypedData
+
+    This specification defines the following types for policy information 
+    conveyed in CrossRealmTktData:
+      PLC_LIFETIME              1
+      PLC_SET_TKT_FLAGS         2
+      PLC_NOSET_TKT_FLAGS       3
+
+    TicketExtensions are defined per the Kerberos specification [8]:
+    TicketExtensions ::= SEQUENCE OF TypedData
+      Where
+        TypedData ::=   SEQUENCE {
+            data-type[0]   INTEGER,
+            data-value[1]  OCTET STRING OPTIONAL
+        }
+
+
+5.  Protocol Specification
+
+    We assume that the client has already obtained a TGT.  To perform
+    cross-realm authentication, the client does exactly what it does
+    with ordinary (i.e. non-public-key-enabled) Kerberos; the only
+    changes are in the KDC; although the ticket which the client
+    forwards to the remote realm may be changed.  This is acceptable
+    since the client treats the ticket as opaque.
+
+
+5.1.  Overview of Protocol
+
+    The basic operation of the PKCROSS protocol is as follows:
+
+        1.  The client submits a request to the local KDC for
+            credentials for the remote realm.  This is just a typical
+            cross realm request that may occur with or without PKCROSS. 
+
+        2.  The local KDC submits a PKINIT request to the remote KDC to
+            obtain a "special" PKCROSS ticket.  This is a standard
+            PKINIT request, except that PKCROSS flag (bit 9) is set in
+            the kdc-options field in the AS_REQ.
+
+        3.  The remote KDC responds as per PKINIT, except that
+            the ticket contains a TicketExtension, which contains
+            policy information such as lifetime of cross realm tickets
+            issued by KDC_l to a client.  The local KDC must reflect
+            this policy information in the credentials it forwards to
+            the client.  Call this ticket XTKT_(l,r) to indicate that
+            this ticket is used to authenticate the local KDC to the
+            remote KDC.
+
+        4.  The local KDC passes a ticket, TGT_(c,r) (the cross realm
+            TGT between the client and remote KDC), to the client.
+            This ticket contains in its TicketExtension field the
+            ticket, XTKT_(l,r), which contains the cross-realm key.
+            The TGT_(c,r) ticket is encrypted using the key sealed in
+            XTKT_(l,r).  (The TicketExtension field is not encrypted.)
+            The local KDC may optionally include another TicketExtension
+            type that indicates the hostname and/or IP address for the
+            remote KDC.
+
+        5.  The client submits the request directly to the remote
+            KDC, as before.
+            
+        6.  The remote KDC extracts XTKT_(l,r) from the TicketExtension
+            in order to decrypt the encrypted part of TGT_(c,r).
+
+    --------------------------------------------------------------------
+    
+    Client                Local KDC (KDC_l)           Remote KDC (KDC_r)
+    ------                -----------------           ------------------
+    Normal Kerberos
+    request for
+    cross-realm
+    ticket for KDC_r
+    ---------------------->
+    
+                          PKINIT request for
+                          XTKT(l,r) - PKCROSS flag
+                          set in the AS-REQ
+                          * ------------------------->
+                          
+                                                      PKINIT reply with
+                                                      XTKT_(l,r) and
+                                                      policy info in
+                                                      ticket extension
+                                           <-------------------------- *
+
+                          Normal Kerberos reply
+                          with TGT_(c,r) and
+                          XTKT(l,r) in ticket
+                          extension
+         <--------------------------------- 
+
+    Normal Kerberos
+    cross-realm TGS-REQ
+    for remote
+    application
+    service with
+    TGT_(c,r) and
+    XTKT(l,r) in ticket
+    extension
+    ------------------------------------------------->
+
+                                                      Normal Kerberos
+                                                      cross-realm
+                                                      TGS-REP
+        <---------------------------------------------------------------
+
+    * Note that the KDC to KDC messages occur only periodically, since
+      the local KDC caches the XTKT_(l,r).
+    --------------------------------------------------------------------
+    
+
+    Sections 5.2 through 5.4 describe in detail steps 2 through 4
+    above.  Section 5.6 describes the conditions under which steps
+    2 and 3 may be skipped.
+
+    Note that the mechanism presented above requires infrequent KDC to 
+    KDC communication (as dictated by policy - this is discussed
+    later).  Without such an exchange, there are the following issues:
+    1) KDC_l would have to issue a ticket with the expectation that
+       KDC_r will accept it.
+    2) In the message that the client sends to KDC_r, KDC_l would have
+       to authenticate KDC_r with credentials that KDC_r trusts.
+    3) There is no way for KDC_r to convey policy information to KDC_l.
+    4) If, based on local policy, KDC_r does not accept a ticket from
+       KDC_l, then the client gets stuck in the middle.  To address such
+       an issue would require modifications to standard client
+       processing behavior.
+    Therefore, the infreqeunt use of KDC to KDC communication assures
+    that inter-realm KDC keys may be established in accordance with local
+    policies and that clients may continue to operate without
+    modification.
+
+
+5.2.  Local KDC's Request to Remote KDC
+
+    When the local KDC receives a request for cross-realm authentication, 
+    it first checks its ticket cache to see if it has a valid PKCROSS 
+    ticket, XTKT_(l,r).  If it has a valid XTKT_(l,r), then it does not 
+    need to send a request to the remote KDC (see section 5.5).
+
+    If the local KDC does not have a valid XTKT_(l,r), it sends a     
+    request to the remote KDC in order to establish a cross realm key and 
+    obtain the XTKT_(l,r).  This request is in fact a PKINIT request as 
+    described in the PKINIT specification; i.e., it consists of an AS-REQ 
+    with a PA-PK-AS-REQ included as a preauthentication field.  Note, 
+    that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the 
+    kdc_options field of the AS-REQ.  Otherwise, this exchange exactly 
+    follows the description given in the PKINIT specification.  In 
+    addition, the naming
+
+
+5.3.  Remote KDC's Response to Local KDC
+
+    When the remote KDC receives the PKINIT/PKCROSS request from the
+    local KDC, it sends back a PKINIT response as described in
+    the PKINIT specification with the following exception: the encrypted
+    part of the Kerberos ticket is not encrypted with the krbtgt key;
+    instead, it is encrypted with the ticket granting server's PKCROSS
+    key.  This key, rather than the krbtgt key, is used because it
+    encrypts a ticket used for verifying a cross realm request rather
+    than for issuing an application service ticket.  Note that, as a
+    matter of policy, the session key for the XTKT_(l,r) MAY be of
+    greater strength than that of a session key for a normal PKINIT
+    reply, since the XTKT_(l,r) SHOULD be much longer lived than a
+    normal application service ticket.
+
+    In addition, the remote KDC SHOULD include policy information in the 
+    XTKT_(l,r).  This policy information would then be reflected in the 
+    cross-realm TGT, TGT_(c,r).  Otherwise, the policy for TGT_(c,r) 
+    would be dictated by KDC_l rather than by KDC_r.  The local KDC MAY 
+    enforce a more restrictive local policy when creating a cross-realm 
+    ticket, TGT_(c,r).  For example, KDC_r  may dictate a lifetime 
+    policy of eight hours, but KDC_l may create TKT_(c,r) with a 
+    lifetime of four hours, as dictated by local policy.  Also, the 
+    remote KDC MAY include other information about itself along with the 
+    PKCROSS ticket.  These items are further discussed in section 6 
+    below.
+
+
+5.4.  Local KDC's Response to Client
+
+    Upon receipt of the PKINIT/CROSS response from the remote KDC,
+    the local KDC formulates a response to the client.  This reply
+    is constructed exactly as in the Kerberos specification, except
+    for the following:
+
+    A) The local KDC places XTKT_(l,r) in the TicketExtension field of
+       the client's cross-realm, ticket, TGT_(c,r), for the remote realm.
+       Where
+          data-type   equals 3 for TE-TYPE-PKCROSS-CLIENT
+          data-value  is ASN.1 encoding of XTKT_(l,r)
+     
+    B) The local KDC adds the name of its CA to the transited field of
+       TGT_(c,r).
+
+
+5.5   Remote KDC's Processing of Client Request
+
+    When the remote KDC, KDC_r, receives a cross-realm ticket, 
+    TGT_(c,r), and it detects that the ticket contains a ticket 
+    extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt 
+    the ticket, XTKT_(l,r), that is encoded in the ticket extension.  
+    KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r).  KDC_r 
+    then uses the key obtained from XTKT_(l,r) in order to decrypt the 
+    cross-realm ticket, TGT_(c,r).
+
+    KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in 
+    compliance with any policy information contained in XTKT_(l,r) (see 
+    section 6).  If the TGT_(c,r) is not in compliance with policy, then 
+    the KDC_r responds to the client with a KRB-ERROR message of type 
+    KDC_ERR_POLICY.
+
+    
+5.6.  Short-Circuiting the KDC-to-KDC Exchange
+
+    As we described earlier, the KDC to KDC exchange is required only 
+    for establishing a symmetric, inter-realm key.  Once this key is 
+    established (via the PKINIT exchange), no KDC to KDC communication 
+    is required until that key needs to be renewed.  This section 
+    describes the circumstances under which the KDC to KDC exchange 
+    described in Sections 5.2 and 5.3 may be skipped.
+
+    The local KDC has a known lifetime for TGT_(c,r).  This lifetime may 
+    be determined by policy information included in XTKT_(l,r), and/or 
+    it may be determined by local KDC policy.  If the local KDC already 
+    has a ticket XTKT(l,r), and the start time plus the lifetime for 
+    TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then 
+    the local KDC may skip the exchange with the remote KDC, and issue a 
+    cross-realm ticket to the client as described in Section 5.4.
+
+    Since the remote KDC may change its PKCROSS key (referred to in 
+    Section 5.2) while there are PKCROSS tickets still active, it SHOULD 
+    cache the old PKCROSS keys until the last issued PKCROSS ticket 
+    expires.  Otherwise, the remote KDC will respond to a client with a 
+    KRB-ERROR message of type KDC_ERR_TGT_REVOKED.
+
+
+6.  Extensions for the PKCROSS Ticket
+
+    As stated in section 5.3, the remote KDC SHOULD include policy 
+    information in XTKT_(l,r).  This policy information is contained in 
+    a TicketExtension, as defined by the Kerberos specification, and the 
+    authorization data of the ticket will contain an authorization 
+    record of type AD-IN-Ticket-Extensions.  The TicketExtension defined 
+    for use by PKCROSS is TE-TYPE-PKCROSS-KDC.
+      Where
+        data-type   equals 2 for TE-TYPE-PKCROSS-KDC
+        data-value  is ASN.1 encoding of CrossRealmTktData
+
+      CrossRealmTktData ::= SEQUENCE OF TypedData
+
+
+      ------------------------------------------------------------------
+      CrossRealmTktData types and the corresponding data are interpreted 
+      as follows:
+
+                                                            ASN.1 data
+      type                value   interpretation            encoding
+      ----------------    -----   --------------            ----------
+      PLC_LIFETIME          1     lifetime (in seconds)     INTEGER
+                                  for TGT_(c,r) 
+                                  - cross-realm tickets
+                                    issued for clients by
+                                    TGT_l
+
+      PLC_SET_TKT_FLAGS     2     TicketFlags that must     BITSTRING
+                                  be set
+                                  - format defined by
+                                    Kerberos specification
+
+      PLC_NOSET_TKT_FLAGS   3     TicketFlags that must     BITSTRING
+                                  not be set
+                                  - format defined by
+                                    Kerberos specification
+
+      Further types may be added to this table.
+      ------------------------------------------------------------------
+
+
+7.  Usage of Certificates
+
+    In the cases of PKINIT and PKCROSS, the trust in a certification 
+    authority is equivalent to Kerberos cross realm trust.  For this 
+    reason, an implementation MAY choose to use the same KDC certificate 
+    when the KDC is acting in any of the following three roles:
+      1) KDC is authenticating clients via PKINIT
+      2) KDC is authenticating another KDC for PKCROSS 
+      3) KDC is the client in a PKCROSS exchange with another KDC
+
+    Note that per PKINIT, the KDC X.509 certificate (the server in a 
+    PKINIT exchange) MUST contain the principal name of the KDC in the 
+    subjectAltName field.
+
+
+8.  Transport Issues
+
+    Because the messages between the KDCs involve PKINIT exchanges, and 
+    PKINIT recommends TCP as a transport mechanism (due to the length of 
+    the messages and the likelihood that they will fragment), the same 
+    recommendation for TCP applies to PKCROSS as well.
+
+    
+9. Security Considerations
+
+   Since PKCROSS utilizes PKINIT, it is subject to the same security
+   considerations as PKINIT.  Administrators should assure adherence 
+   to security policy - for example, this affects the PKCROSS policies
+   for cross realm key lifetime and for policy propogation from the 
+   PKCROSS ticket, issued from a remote KDC to a local KDC, to
+   cross realm tickets that are issued by a local KDC to a client.
+
+
+10. 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] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray
+  J. Trostle.  Public Key Cryptography for Initial Authentication
+  in Kerberos.
+  draft-ietf-cat-kerberos-pk-init-11.txt
+
+  [4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman.  Public 
+  Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-
+  cat-pktapp-02.txt
+
+  [5] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
+  Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt
+
+  [6] ITU-T (formerly CCITT) Information technology - Open Systems
+  Interconnection - The Directory: Authentication Framework
+  Recommendation X.509 ISO/IEC 9594-8
+    
+  [7] B.C. Neuman, Proxy-Based Authorization and Accounting for 
+  Distributed Systems.  In Proceedings of the 13th International 
+  Conference on Distributed Computing Systems, May 1993.
+
+  [8] C.Neuman, J. Kohl, T. Ts'o.  The Kerberos Network Authentication 
+  Service (V5). draft-ietf-cat-kerberos-revisions-05.txt
+
+
+11. Authors' Addresses
+
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road
+    Issaquah WA 98027-5378
+    Phone: +1 425 391 6000
+    E-mail: matt.hur@cybersafe.com
+
+    Brian Tung
+    Tatyana Ryutov
+    Clifford Neuman
+    Gene Tsudik
+    USC/Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey, CA 90292-6695
+    Phone: +1 310 822 1511
+    E-Mail: {brian, tryutov, bcn, gts}@isi.edu
+
+    Ari Medvinsky
+    Keen.com
+    2480 Sand Hill Road, Suite 200
+    Menlo Park, CA 94025
+    Phone +1 650 289 3134
+    E-mail: ari@keen.com
+
+    Bill Sommerfeld
+    Hewlett Packard
+    300 Apollo Drive
+    Chelmsford MA 01824
+    Phone: +1 508 436 4352
+    E-Mail: sommerfeld@apollo.hp.com
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
new file mode 100644
index 000000000000..9b0e76adad98
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
@@ -0,0 +1,1059 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-11.txt                   Clifford Neuman
+Updates: RFC 1510                                                USC/ISI
+expires September 15, 2000                                   Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                          Keen.com, Inc.
+                                                         Sasha Medvinsky
+                                                                Motorola
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+                                                                   Cisco
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC 2026.  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 on ftp.ietf.org (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-11.txt, and expires September 15,
+    2000.  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 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.
+
+    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
+    combination with digital signature keys as the primary, required
+    mechanism.  It also allows for the use of RSA keys and/or (static)
+    Diffie-Hellman certificates.  Note in particular that PKINIT supports
+    the use of separate signature and encryption keys.
+
+    PKINIT enables access to Kerberos-secured services based on initial
+    authentication utilizing public key cryptography.  PKINIT utilizes
+    standard public key signature and encryption data formats within the
+    standard Kerberos messages.  The basic mechanism is as follows:  The
+    user sends an AS-REQ message to the KDC as before, except that if that
+    user is to use public key cryptography in the initial authentication
+    step, his certificate and a signature accompany 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 the encPart from the AS-REP message
+    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
+    derived key or the user's public key.  This message is authenticated
+    utilizing the public key signature of the KDC.
+
+    Note that PKINIT does not require the use of certificates.  A KDC
+    may store the public key of a principal as part of that principal's
+    record.  In this scenario, the KDC is the trusted party that vouches
+    for the principal (as in a standard, non-cross realm, Kerberos
+    environment).  Thus, for any principal, the KDC may maintain a
+    secret key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
+    the inter-realm key and associated inter-realm policy to be applied
+    in issuing cross realm service tickets.  As specified in [4],
+    anonymous Kerberos tickets can be issued by applying a NULL
+    signature in combination with Diffie-Hellman in the PKINIT exchange.
+    Additionally, the PKINIT specification may be used for direct peer
+    to peer authentication without contacting a central KDC. This
+    application of PKINIT is described in PKTAPP [5] and is based on
+    concepts introduced in [6, 7]. 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 TLS [8] 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 [9]).
+
+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 change to RFC 1510 is 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.  The user presents
+          a public key certificate and 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 describes the extensions for the initial authentication
+    method.
+
+3.1.  Definitions
+
+    The extensions involve new preauthentication fields; we introduce
+    the following preauthentication types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+
+    The extensions also involve new error types; we introduce the
+    following types:
+
+        KDC_ERR_CLIENT_NOT_TRUSTED              62
+        KDC_ERR_KDC_NOT_TRUSTED                 63
+        KDC_ERR_INVALID_SIG                     64
+        KDC_ERR_KEY_TOO_WEAK                    65
+        KDC_ERR_CERTIFICATE_MISMATCH            66
+        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
+        KDC_ERR_INVALID_CERTIFICATE             71
+        KDC_ERR_REVOKED_CERTIFICATE             72
+        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
+        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
+        KDC_ERR_CLIENT_NAME_MISMATCH            75
+        KDC_ERR_KDC_NAME_MISMATCH               76
+
+    We utilize the following typed data for errors:
+
+        TD-PKINIT-CMS-CERTIFICATES             101
+        TD-KRB-PRINCIPAL                       102
+        TD-KRB-REALM                           103
+        TD-TRUSTED-CERTIFIERS                  104
+        TD-CERTIFICATE-INDEX                   105
+
+    We utilize the following encryption types (which map directly to
+    OIDs):
+
+        dsaWithSHA1-CmsOID                       9
+        md5WithRSAEncryption-CmsOID             10
+        sha1WithRSAEncryption-CmsOID            11
+        rc2CBC-EnvOID                           12
+        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
+        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
+        des-ede3-cbc-Env-OID                    15
+
+    These mappings are provided so that a client may send the
+    appropriate enctypes in the AS-REQ message in order to indicate
+    support for the corresponding OIDs (for performing PKINIT).
+
+    In many cases, PKINIT requires the encoding of the X.500 name of a
+    certificate authority as a Realm.  When such a name appears as
+    a realm it will be represented using the "other" form of the realm
+    name as specified in the naming constraints section of RFC1510.
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        <nametype> + ":" + <string>
+
+    where nametype is "X500-RFC2253" and string is the result of doing
+    an RFC2253 encoding of the distinguished name, i.e.
+
+        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    function returing a readable UTF encoding of an X.500 name, as
+    defined by RFC 2253 [14] (part of LDAPv3 [18]).
+
+    To ensure that this encoding is unique, we add the following rule
+    to those specified by RFC 2253:
+
+        The order in which the attributes appear in the RFC 2253
+        encoding must be the reverse of the order in the ASN.1
+        encoding of the X.500 name that appears in the public key
+        certificate. The order of the relative distinguished names
+        (RDNs), as well as the order of the AttributeTypeAndValues
+        within each RDN, will be reversed. (This is despite the fact
+        that an RDN is defined as a SET of AttributeTypeAndValues, where
+        an order is normally not important.)
+
+    Similarly, in cases where the KDC does not provide a specific
+    policy based mapping from the X.500 name or X.509 Version 3
+    SubjectAltName extension in the user's certificate to a Kerberos
+    principal name, PKINIT requires the direct encoding of the X.500
+    name as a PrincipalName.  In this case, the name-type of the
+    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510 as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm shall be set to the certificate authority's distinguished
+    name using the X500-RFC2253 realm name format described earlier in
+    this section
+
+    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
+
+        PrincipalName ::=   SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF GeneralString
+        }
+
+    For the purposes of encoding an X.500 name as a Kerberos name for
+    use in Kerberos structures, the name-string shall be encoded as a
+    single GeneralString.  The name-type should be KRB_NT_X500_PRINCIPAL,
+    as noted above.  All Kerberos names must conform to validity
+    requirements as given in RFC 1510.  Note that name mapping may be
+    required or optional, based on policy.
+
+    We also define the following similar ASN.1 structure:
+
+        CertPrincipalName ::= SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF UTF8String
+        }
+
+    When a Kerberos PrincipalName is to be placed within an X.509 data
+    structure, the CertPrincipalName structure is to be used, with the
+    name-string encoded as a single UTF8String.  The name-type should be
+    as identified in the original PrincipalName structure.  The mapping
+    between the GeneralString and UTF8String formats can be found in
+    [19].
+
+    The following rules relate to the the matching of PrincipalNames (or
+    corresponding CertPrincipalNames) with regard to the PKI name
+    constraints for CAs as laid out in RFC 2459 [15].  In order to be
+    regarded as a match (for permitted and excluded name trees), the
+    following must be satisfied.
+
+        1.  If the constraint is given as a user plus realm name, or
+            as a user plus instance plus realm name (as specified in
+            RFC 1510), the realm name must be valid (see 2.a-d below)
+            and the match must be exact, byte for byte.
+
+        2.  If the constraint is given only as a realm name, matching
+            depends on the type of the realm:
+
+            a.  If the realm contains a colon (':') before any equal
+                sign ('='), it is treated as a realm of type Other,
+                and must match exactly, byte for byte.
+
+            b.  Otherwise, if the realm contains an equal sign, it
+                is treated as an X.500 name.  In order to match, every
+                component in the constraint MUST be in the principal
+                name, and have the same value.  For example, 'C=US'
+                matches 'C=US/O=ISI' but not 'C=UK'.
+
+            c.  Otherwise, if the realm name conforms to rules regarding
+                the format of DNS names, it is considered a realm name of
+                type Domain.  The constraint may be given as a realm
+                name 'FOO.BAR', which matches any PrincipalName within
+                the realm 'FOO.BAR' but not those in subrealms such as
+                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
+                matches PrincipalNames in subrealms of the form
+                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
+
+            d.  Otherwise, the realm name is invalid and does not match
+                under any conditions.
+
+3.1.1.  Encryption and Key Formats
+
+    In the exposition below, we use the terms public key and private
+    key generically.  It should be understood that the term "public
+    key" may be used to refer to either a public encryption key or a
+    signature verification key, and that the term "private key" may be
+    used to refer to either a private decryption key or a signature
+    generation key.  The fact that these are logically distinct does
+    not preclude the assignment of bitwise identical keys for RSA
+    keys.
+
+    In the case of Diffie-Hellman, the key shall be produced from the
+    agreed bit string as follows:
+
+        * Truncate the bit string to the appropriate length.
+        * Rectify parity in each byte (if necessary) to obtain the key.
+
+    For instance, in the case of a DES key, we take the first eight
+    bytes of the bit stream, and then adjust the least significant bit
+    of each byte to ensure that each byte has odd parity.
+
+3.1.2. Algorithm Identifiers
+
+    PKINIT does not define, but does permit, the algorithm identifiers
+    listed below.
+
+3.1.2.1. Signature Algorithm Identifiers
+
+    The following signature algorithm identifiers specified in [11] and
+    in [15] shall be used with PKINIT:
+
+    id-dsa-with-sha1       (DSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    sha-1WithRSAEncryption (RSA with SHA1)
+
+3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
+
+    The following algorithm identifier shall be used within the
+    SubjectPublicKeyInfo data structure: dhpublicnumber
+
+    This identifier and the associated algorithm parameters are
+    specified in RFC 2459 [15].
+
+3.1.2.3. Algorithm Identifiers for RSA Encryption
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure, for encrypting the temporary key with a public key:
+
+        rsaEncryption (RSA encryption, PKCS#1 v1.5)
+        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
+
+    Both of the above RSA encryption schemes are specified in [16].
+    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
+    CMS specification says that it will likely include PKCS#1 v2.0 in
+    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
+    vulnerability discovered in PKCS#1 v1.5.)
+
+3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure in the PKINIT Reply, for encrypting the reply key with the
+    temporary key:
+        des-ede3-cbc (3-key 3-DES, CBC mode)
+        rc2-cbc      (RC2, CBC mode)
+
+    The full definition of the above algorithm identifiers and their
+    corresponding parameters (an IV for block chaining) is provided in
+    the CMS specification [11].
+
+3.2.  Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+3.2.1.  Client Request
+
+    Public keys may be signed by some certification authority (CA), or
+    they may be maintained by the KDC in which case the KDC is the
+    trusted authority.  Note that the latter mode does not require the
+    use of certificates.
+
+    The initial authentication request is sent as per RFC 1510, except
+    that a preauthentication field containing data signed by the user's
+    private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedData
+                                    -- Defined in CMS [11];
+                                    -- AuthPack (below) defines the
+                                    -- data that is signed.
+        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
+                                    -- This is a list of CAs that the
+                                    -- client trusts and that certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- As defined in CMS [11];
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it.
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
+                                    -- For example, this may be the
+                                    -- client's Diffie-Hellman
+                                    -- certificate, or it may be the
+                                    -- client's RSA encryption
+                                    -- certificate.
+    }
+
+    TrustedCas ::= CHOICE {
+        principalName         [0] KerberosName,
+                                  -- as defined below
+        caName                [1] Name
+                                  -- fully qualified X.500 name
+                                  -- as defined by X.509
+        issuerAndSerial       [2] IssuerAndSerialNumber
+                                  -- Since a CA may have a number of
+                                  -- certificates, only one of which
+                                  -- a client trusts
+    }
+
+    Usage of SignedData:
+
+        The SignedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  The following describes how to fill in the fields of
+        this data:
+
+        1.  The encapContentInfo field must contain the PKAuthenticator
+            and, optionally, the client's Diffie Hellman public value.
+
+            a.  The eContentType field shall contain the OID value for
+                pkdata: iso (1) org (3) dod (6) internet (1) security (5)
+                kerberosv5 (2) pkinit (3) pkdata (1)
+
+            b.  The eContent field is data of the type AuthPack (below).
+
+        2.  The signerInfos field contains the signature of AuthPack.
+
+        3.  The Certificates field, when non-empty, contains the client's
+            certificate chain.  If present, the KDC uses the public key
+            from the client's certificate to verify the signature in the
+            request.  Note that the client may pass different certificate
+            chains that are used for signing or for encrypting.  Thus,
+            the KDC may utilize a different client certificate for
+            signature verification than the one it uses to encrypt the
+            reply to the client.  For example, the client may place a
+            Diffie-Hellman certificate in this field in order to convey
+            its static Diffie Hellman certificate to the KDC to enable
+            static-ephemeral Diffie-Hellman mode for the reply; in this
+            case, the client does NOT place its public value in the
+            AuthPack (defined below).  As another example, the client may
+            place an RSA encryption certificate in this field.  However,
+            there must always be (at least) a signature certificate.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+                                    -- (ephemeral-ephemeral only)
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention as in RFC1510
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention as in RFC1510
+        nonce                   [4] INTEGER
+    }
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm                   AlgorithmIdentifier,
+                                    -- dhKeyAgreement
+        subjectPublicKey            BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [10]
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm                   ALGORITHM.&id,
+        parameters                  ALGORITHM.&type
+    }   -- as specified by the X.509 recommendation [10]
+
+    If the client passes an issuer and serial number in the request,
+    the KDC is requested to use the referred-to certificate.  If none
+    exists, then the KDC returns an error of type
+    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
+    other hand, the client does not pass any trustedCertifiers,
+    believing that it has the KDC's certificate, but the KDC has more
+    than one certificate.  The KDC should include information in the
+    KRB-ERROR message that indicates the KDC certificate(s) that a
+    client may utilize.  This data is specified in the e-data, which
+    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
+
+    TypedData ::=  SEQUENCE {
+                    data-type      [0] INTEGER,
+                    data-value     [1] OCTET STRING,
+    } -- per Kerberos RFC 1510 revisions
+
+    where:
+    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+    data-value = CertificateSet // as specified by CMS [11]
+
+    The PKAuthenticator carries information to foil replay attacks, and
+    to bind the request and response.  The PKAuthenticator is signed
+    with the client's signature key.
+
+3.2.2.  KDC Response
+
+    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 client's certificate chain contains no certificate signed by
+    a CA trusted by the KDC, then the KDC sends back an error message
+    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
+    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
+    whose data-value is an OCTET STRING which is the DER encoding of
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+                              -- X.500 name encoded as a principal name
+                              -- see Section 3.1
+
+    If while verifying a certificate chain the KDC determines that the
+    signature on one of the certificates in the CertificateSet from
+    the signedAuthPack fails verification, then the KDC returns an
+    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
+    e-data is a SEQUENCE of one TypedData (with type
+    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
+    which is the DER encoding of the index into the CertificateSet
+    ordered as sent by the client.
+
+        CertificateIndex  ::= INTEGER
+                              -- 0 = 1st certificate,
+                              --     (in order of encoding)
+                              -- 1 = 2nd certificate, etc
+
+    The KDC may also check whether any of the certificates in the
+    client's chain has been revoked.  If one of the certificates has
+    been revoked, then the KDC returns an error of type
+    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
+    the certificate's revocation status is unknown or not
+    available, then if required by policy, the KDC returns the
+    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
+    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
+    cases, the affected certificate is identified by the accompanying
+    e-data, which contains a CertificateIndex as described for
+    KDC_ERR_INVALID_CERTIFICATE.
+
+    If the certificate chain can be verified, but the name of the
+    client in the certificate does not match the client's name in the
+    request, then the KDC returns an error of type
+    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+    field in this case.
+
+    Finally, if the certificate chain is verified, but the KDC's name
+    or realm as given in the PKAuthenticator does not match the KDC's
+    actual principal name, then the KDC returns an error of type
+    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
+    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
+    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
+    STRING whose data-value is the DER encoding of a PrincipalName or
+    Realm as defined in RFC 1510 revisions.
+
+    Even if all succeeds, the KDC may--for policy reasons--decide not
+    to trust the client.  In this case, the KDC returns an error message
+    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
+    the presence or absence of an Enhanced Key Usage (EKU) OID within
+    the certificate extensions.  The rules regarding acceptability of
+    an EKU sequence (or the absence of any sequence) are a matter of
+    local policy.  For the benefit of implementers, we define a PKINIT
+    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
+    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
+
+    If a trust relationship exists, the KDC then verifies the client's
+    signature on AuthPack.  If that fails, the KDC returns an error
+    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
+    timestamp (ctime and cusec) in the PKAuthenticator to assure that
+    the request is not a replay.  The KDC also verifies that its name
+    is specified in the PKAuthenticator.
+
+    If the clientPublicValue field is filled in, indicating that the
+    client wishes to use Diffie-Hellman key agreement, then the KDC
+    checks to see that the parameters satisfy its policy.  If they do
+    not (e.g., the prime size is insufficient for the expected
+    encryption type), then the KDC sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
+    private values for the response.
+
+    The KDC also checks that the timestamp in the PKAuthenticator is
+    within the allowable window and that the principal name and realm
+    are correct.  If the local (server) time and the client time in the
+    authenticator differ by more than the allowable clock skew, then the
+    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except as
+    follows.  The user's name in the ticket is determined by the
+    following decision algorithm:
+
+        1.  If the KDC has a mapping from the name in the certificate
+            to a Kerberos name, then use that name.
+            Else
+        2.  If the certificate contains the SubjectAltName extention
+            and the local KDC policy defines a mapping from the
+            SubjectAltName to a Kerberos name, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, mapping
+            mapping as necessary (e.g., as per RFC 2253 for X.500
+            names).  In this case the realm in the ticket shall be the
+            name of the certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subject alt name
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subject alt name may be kerberos/principal@realm format.  In
+    this case the realm name is not that of the CA but that of the
+    local realm doing the mapping (or some realm name chosen by that
+    realm).
+
+    If a non-KDC X.509 certificate contains the principal name within
+    the subjectAltName version 3 extension , that name may utilize
+    KerberosName as defined below, or, in the case of an S/MIME
+    certificate [17], may utilize the email address.  If the KDC
+    is presented with an S/MIME certificate, then the email address
+    within subjectAltName will be interpreted as a principal and realm
+    separated by the "@" sign, or as a name that needs to be
+    canonicalized.  If the resulting name does not correspond to a
+    registered principal name, then the principal name is formed as
+    defined in section 3.1.
+
+    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.  If the KDC has no
+    certificate signed by any of the trustedCertifiers, then it returns
+    an error of type KDC_ERR_KDC_NOT_TRUSTED.
+
+    KDCs should try to (in order of preference):
+    1. Use the KDC certificate identified by the serialNumber included
+       in the client's request.
+    2. Use a certificate issued to the KDC by the client's CA (if in the
+       middle of a CA key roll-over, use the KDC cert issued under same
+       CA key as user cert used to verify request).
+    3. Use a certificate issued to the KDC by one of the client's
+       trustedCertifier(s);
+    If the KDC is unable to comply with any of these options, then the
+    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
+    client.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with the Diffie Hellman derived key or a random key generated
+    for this particular response which is carried in the padata field of
+    the TGS-REP message.
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Hellman key exchange (if the
+                            -- client public value was present in the
+                            -- request).
+                            -- This choice MUST be supported
+                            -- by compliant implementations.
+        encKeyPack         [1] EnvelopedData,
+                            -- Defined in CMS
+                            -- The temporary key is encrypted
+                            -- using the client public key
+                            -- key
+                            -- SignedReplyKeyPack, encrypted
+                            -- with the temporary key, is also
+                            -- included.
+    }
+
+    Usage of SignedData:
+
+        When the Diffie-Hellman option is used, dhSignedData in
+        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
+        of the KDC.  The reply key used to encrypt part of the KDC reply
+        message is derived from the Diffie-Hellman exchange:
+
+        1.  Both the KDC and the client calculate a secret value
+            (g^ab mod p), where a is the client's private exponent and
+            b is the KDC's private exponent.
+
+        2.  Both the KDC and the client take the first N bits of this
+            secret value and convert it into a reply key.  N depends on
+            the reply key type.
+
+        3.  If the reply key is DES, N=64 bits, where some of the bits
+            are replaced with parity bits, according to FIPS PUB 74.
+
+        4.  If the reply key is (3-key) 3-DES, N=192 bits, where some
+            of the bits are replaced with parity bits, according to
+            FIPS PUB 74.
+
+        5.  The encapContentInfo field must contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field shall contain the OID value for
+                pkdata: iso (1) org (3) dod (6) internet (1) security (5)
+                kerberosv5 (2) pkinit (3) pkdata (1)
+
+            b.  The eContent field is data of the type KdcDHKeyInfo
+                (below).
+
+        6.  The certificates field must contain the certificates
+            necessary for the client to establish trust in the KDC's
+            certificate based on the list of trusted certifiers sent by
+            the client in the PA-PK-AS-REQ.  This field may be empty if
+            the client did not send to the KDC a list of trusted
+            certifiers (the trustedCertifiers field was empty, meaning
+            that the client already possesses the KDC's certificate).
+
+        7.  The signerInfos field is a SET that must contain at least
+            one member, since it contains the actual signature.
+
+    KdcDHKeyInfo ::= SEQUENCE {
+                              -- used only when utilizing Diffie-Hellman
+      nonce                 [0] INTEGER,
+                                -- binds responce to the request
+      subjectPublicKey      [2] BIT STRING
+                                -- Equals public exponent (g^a mod p)
+                                -- INTEGER encoded as payload of
+                                -- BIT STRING
+    }
+
+    Usage of EnvelopedData:
+
+        The EnvelopedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  It contains a temporary key encrypted with the PKINIT
+        client's public key.  It also contains a signed and encrypted
+        reply key.
+
+        1.  The originatorInfo field is not required, since that
+            information may be presented in the signedData structure
+            that is encrypted within the encryptedContentInfo field.
+
+        2.  The optional unprotectedAttrs field is not required for
+            PKINIT.
+
+        3.  The recipientInfos field is a SET which must contain exactly
+            one member of the KeyTransRecipientInfo type for encryption
+            with an RSA public key.
+
+            a.  The encryptedKey field (in KeyTransRecipientInfo)
+                contains the temporary key which is encrypted with the
+                PKINIT client's public key.
+
+        4.  The encryptedContentInfo field contains the signed and
+            encrypted reply key.
+
+            a.  The contentType field shall contain the OID value for
+                id-signedData: iso (1) member-body (2) us (840)
+                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
+
+            b.  The encryptedContent field is encrypted data of the CMS
+                type signedData as specified below.
+
+                i.  The encapContentInfo field must contains the
+                    ReplyKeyPack.
+
+                    * The eContentType field shall contain the OID value
+                      for pkdata: iso (1) org (3) dod (6) internet (1)
+                      security (5) kerberosv5 (2) pkinit (3) pkdata (1)
+
+                    * The eContent field is data of the type ReplyKeyPack
+                      (below).
+
+                ii.  The certificates field must contain the certificates
+                     necessary for the client to establish trust in the
+                     KDC's certificate based on the list of trusted
+                     certifiers sent by the client in the PA-PK-AS-REQ.
+                     This field may be empty if the client did not send
+                     to the KDC a list of trusted certifiers (the
+                     trustedCertifiers field was empty, meaning that the
+                     client already possesses the KDC's certificate).
+
+                iii.  The signerInfos field is a SET that must contain at
+                      least one member, since it contains the actual
+                      signature.
+
+    ReplyKeyPack ::= SEQUENCE {
+                              -- not used for Diffie-Hellman
+        replyKey             [0] EncryptionKey,
+                                 -- used to encrypt main reply
+                                 -- ENCTYPE is at least as strong as
+                                 -- ENCTYPE of session key
+        nonce                [1] INTEGER,
+                                 -- binds response to the request
+                                 -- must be same as the nonce
+                                 -- passed in the PKAuthenticator
+    }
+
+    Since each certifier in the certification path of a user's
+    certificate is equivalent to a separate Kerberos realm, the name
+    of each certifier in the certificate chain must be added to the
+    transited field of the ticket.  The format of these realm names is
+    defined in Section 3.1 of this document.  If applicable, the
+    transit-policy-checked flag should be set in the issued ticket.
+
+    The KDC's certificate(s) must bind the public key(s) of the KDC to
+    a name derivable from the name of the realm for that KDC.  X.509
+    certificates shall contain the principal name of the KDC
+    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
+    3 extension. Below is the definition of this version 3 extension,
+    as specified by the X.509 standard:
+
+        subjectAltName EXTENSION ::= {
+            SYNTAX GeneralNames
+            IDENTIFIED BY id-ce-subjectAltName
+        }
+
+        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
+
+        GeneralName ::= CHOICE {
+            otherName       [0] OtherName,
+            ...
+        }
+
+        OtherName ::= SEQUENCE {
+            type-id         OBJECT IDENTIFIER,
+            value           [0] EXPLICIT ANY DEFINED BY type-id
+        }
+
+    For the purpose of specifying a Kerberos principal name, the value
+    in OtherName shall be a KerberosName as defined in RFC 1510, but with
+    the PrincipalName replaced by CertPrincipalName as mentioned in
+    Section 3.1:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] CertPrincipalName  -- defined above
+        }
+
+    This specific syntax is identified within subjectAltName by setting
+    the type-id in OtherName to krb5PrincipalName, where (from the
+    Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+    (This specification may also be used to specify a Kerberos name
+    within the user's certificate.)  The KDC's certificate may be signed
+    directly by a CA, or there may be intermediaries if the server resides
+    within a large organization, or it may be unsigned if the client
+    indicates possession (and trust) of the KDC's certificate.
+
+    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.  The client uses this
+    random key to decrypt the main reply, and subsequently proceeds as
+    described in RFC 1510.
+
+3.2.3. Required Algorithms
+
+    Not all of the algorithms in the PKINIT protocol specification have
+    to be implemented in order to comply with the proposed standard.
+    Below is a list of the required algorithms:
+
+    * Diffie-Hellman public/private key pairs
+        * utilizing Diffie-Hellman ephemeral-ephemeral mode
+    * SHA1 digest and DSA for signatures
+    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
+    * 3-key triple DES Temporary and Reply keys
+
+4.  Logistics and Policy
+
+    This section describes a way to define the policy on the use of
+    PKINIT for each principal and request.
+
+    The KDC is not required to contain a database record for users
+    who use public key authentication.  However, if these users are
+    registered with the KDC, it is recommended that the database record
+    for these users be modified to an additional flag in the attributes
+    field to indicate that the user should authenticate using PKINIT.
+    If this flag is set and a request message does not contain the
+    PKINIT preauthentication field, then the KDC sends back as error of
+    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
+    field of type PA-PK-AS-REQ must be included in the request.
+
+5.  Security Considerations
+
+    PKINIT raises a few security considerations, which we will address
+    in this section.
+
+    First of all, PKINIT introduces a new trust model, where KDCs do not
+    (necessarily) certify the identity of those for whom they issue
+    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
+    limited capacity of self-signing their certificates, but one of the
+    additional benefits is to align Kerberos authentication with a global
+    public key infrastructure.  Anyone using PKINIT in this way must be
+    aware of how the certification infrastructure they are linking to
+    works.
+
+    Secondly, PKINIT also introduces the possibility of interactions
+    between different cryptosystems, which may be of widely varying
+    strengths.  Many systems, for instance, allow the use of 512-bit
+    public keys.  Using such keys to wrap data encrypted under strong
+    conventional cryptosystems, such as triple-DES, is inappropriate;
+    it adds a weak link to a strong one at extra cost.  Implementors
+    and administrators should take care to avoid such wasteful and
+    deceptive interactions.
+
+    Lastly, PKINIT calls for randomly generated keys for conventional
+    cryptosystems.  Many such systems contain systematically "weak"
+    keys.  PKINIT implementations MUST avoid use of these keys, either
+    by discarding those keys when they are generated, or by fixing them
+    in some way (e.g., by XORing them with a given mask).  These
+    precautions vary from system to system; it is not our intention to
+    give an explicit recipe for them here.
+
+6.  Transport Issues
+
+    Certificate chains can potentially grow quite large and span several
+    UDP packets; this in turn increases the probability that a Kerberos
+    message involving PKINIT extensions will be broken in transit.  In
+    light of the possibility that the Kerberos specification will
+    require KDCs to accept requests using TCP as a transport mechanism,
+    we make the same recommendation with respect to the PKINIT
+    extensions as well.
+
+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] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
+    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
+    Authentication in Kerberos.  draft-ietf-cat-kerberos-pk-cross-04.txt
+
+    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
+    Kerberos.  draft-ietf-cat-kerberos-anoncred-00.txt
+
+    [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
+    Public Key Utilizing Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-02.txt
+
+    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
+    Request for Comments 2246, January 1999.
+
+    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
+    Distributed Systems.  In Proceedings of the 13th International
+    Conference on Distributed Computing Systems, May 1993.
+
+    [10] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+    [11] R. Housley. Cryptographic Message Syntax.
+    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
+    as RFC.
+
+    [12] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
+    Security, Inc. A Description of the RC2(r) Encryption Algorithm
+    March 1998.
+    Request for Comments 2268.
+
+    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+    Key Infrastructure, Certificate and CRL Profile, January 1999.
+    Request for Comments 2459.
+
+    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+    Specifications, October 1998.  Request for Comments 2437.
+
+    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
+    Version 2 Certificate Handling, March 1998.  Request for
+    Comments 2312.
+
+    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
+    Protocol (v3), December 1997.  Request for Comments 2251.
+
+    [19] ITU-T (formerly CCITT) Information Processing Systems - Open
+    Systems Interconnection - Specification of Abstract Syntax Notation
+    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
+
+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 15, 2000.
+
+10. Authors
+
+    Brian Tung
+    Clifford Neuman
+    USC Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey CA 90292-6695
+    Phone: +1 310 822 1511
+    E-mail: {brian, bcn}@isi.edu
+
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road
+    Issaquah WA 98027-5378
+    Phone: +1 425 391 6000
+    E-mail: matt.hur@cybersafe.com
+
+    Ari Medvinsky
+    Keen.com, Inc.
+    150 Independence Drive
+    Menlo Park CA 94025
+    Phone: +1 650 289 3134
+    E-mail: ari@keen.com
+
+    Sasha Medvinsky
+    Motorola
+    6450 Sequence Drive
+    San Diego, CA 92121
+    Phone +1 619 404 2825
+    E-mail: smedvinsky@gi.com
+
+    John Wray
+    Iris Associates, Inc.
+    5 Technology Park Dr.
+    Westford, MA 01886
+    E-mail: John_Wray@iris.com
+
+    Jonathan Trostle
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt
new file mode 100644
index 000000000000..b1e596836eb8
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt
@@ -0,0 +1,1080 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-12.txt                   Clifford Neuman
+Updates: RFC 1510                                                USC/ISI
+expires January 15, 2001                                     Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                          Keen.com, Inc.
+                                                         Sasha Medvinsky
+                                                                Motorola
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+                                                                   Cisco
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC 2026.  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 on ftp.ietf.org (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-11.txt, and expires January 15,
+    2001.  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 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.
+
+    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
+    combination with digital signature keys as the primary, required
+    mechanism.  It also allows for the use of RSA keys and/or (static)
+    Diffie-Hellman certificates.  Note in particular that PKINIT supports
+    the use of separate signature and encryption keys.
+
+    PKINIT enables access to Kerberos-secured services based on initial
+    authentication utilizing public key cryptography.  PKINIT utilizes
+    standard public key signature and encryption data formats within the
+    standard Kerberos messages.  The basic mechanism is as follows:  The
+    user sends an AS-REQ message to the KDC as before, except that if that
+    user is to use public key cryptography in the initial authentication
+    step, his certificate and a signature accompany 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 the encPart from the AS-REP message
+    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
+    derived key or the user's public key.  This message is authenticated
+    utilizing the public key signature of the KDC.
+
+    Note that PKINIT does not require the use of certificates.  A KDC
+    may store the public key of a principal as part of that principal's
+    record.  In this scenario, the KDC is the trusted party that vouches
+    for the principal (as in a standard, non-cross realm, Kerberos
+    environment).  Thus, for any principal, the KDC may maintain a
+    secret key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
+    the inter-realm key and associated inter-realm policy to be applied
+    in issuing cross realm service tickets.  As specified in [4],
+    anonymous Kerberos tickets can be issued by applying a NULL
+    signature in combination with Diffie-Hellman in the PKINIT exchange.
+    Additionally, the PKINIT specification may be used for direct peer
+    to peer authentication without contacting a central KDC. This
+    application of PKINIT is described in PKTAPP [5] and is based on
+    concepts introduced in [6, 7]. 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 TLS [8] 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 [9]).
+
+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 change to RFC 1510 is 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.  The user presents
+          a public key certificate and 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 describes the extensions for the initial authentication
+    method.
+
+3.1.  Definitions
+
+    The extensions involve new preauthentication fields; we introduce
+    the following preauthentication types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+
+    The extensions also involve new error types; we introduce the
+    following types:
+
+        KDC_ERR_CLIENT_NOT_TRUSTED              62
+        KDC_ERR_KDC_NOT_TRUSTED                 63
+        KDC_ERR_INVALID_SIG                     64
+        KDC_ERR_KEY_TOO_WEAK                    65
+        KDC_ERR_CERTIFICATE_MISMATCH            66
+        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
+        KDC_ERR_INVALID_CERTIFICATE             71
+        KDC_ERR_REVOKED_CERTIFICATE             72
+        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
+        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
+        KDC_ERR_CLIENT_NAME_MISMATCH            75
+        KDC_ERR_KDC_NAME_MISMATCH               76
+
+    We utilize the following typed data for errors:
+
+        TD-PKINIT-CMS-CERTIFICATES             101
+        TD-KRB-PRINCIPAL                       102
+        TD-KRB-REALM                           103
+        TD-TRUSTED-CERTIFIERS                  104
+        TD-CERTIFICATE-INDEX                   105
+
+    We utilize the following encryption types (which map directly to
+    OIDs):
+
+        dsaWithSHA1-CmsOID                       9
+        md5WithRSAEncryption-CmsOID             10
+        sha1WithRSAEncryption-CmsOID            11
+        rc2CBC-EnvOID                           12
+        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
+        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
+        des-ede3-cbc-Env-OID                    15
+
+    These mappings are provided so that a client may send the
+    appropriate enctypes in the AS-REQ message in order to indicate
+    support for the corresponding OIDs (for performing PKINIT).
+
+    In many cases, PKINIT requires the encoding of the X.500 name of a
+    certificate authority as a Realm.  When such a name appears as
+    a realm it will be represented using the "other" form of the realm
+    name as specified in the naming constraints section of RFC1510.
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        <nametype> + ":" + <string>
+
+    where nametype is "X500-RFC2253" and string is the result of doing
+    an RFC2253 encoding of the distinguished name, i.e.
+
+        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    function returing a readable UTF encoding of an X.500 name, as
+    defined by RFC 2253 [14] (part of LDAPv3 [18]).
+
+    To ensure that this encoding is unique, we add the following rule
+    to those specified by RFC 2253:
+
+        The order in which the attributes appear in the RFC 2253
+        encoding must be the reverse of the order in the ASN.1
+        encoding of the X.500 name that appears in the public key
+        certificate. The order of the relative distinguished names
+        (RDNs), as well as the order of the AttributeTypeAndValues
+        within each RDN, will be reversed. (This is despite the fact
+        that an RDN is defined as a SET of AttributeTypeAndValues, where
+        an order is normally not important.)
+
+    Similarly, in cases where the KDC does not provide a specific
+    policy based mapping from the X.500 name or X.509 Version 3
+    SubjectAltName extension in the user's certificate to a Kerberos
+    principal name, PKINIT requires the direct encoding of the X.500
+    name as a PrincipalName.  In this case, the name-type of the
+    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510 as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm shall be set to the certificate authority's distinguished
+    name using the X500-RFC2253 realm name format described earlier in
+    this section
+
+    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
+
+        PrincipalName ::=   SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF GeneralString
+        }
+
+    For the purposes of encoding an X.500 name as a Kerberos name for
+    use in Kerberos structures, the name-string shall be encoded as a
+    single GeneralString.  The name-type should be KRB_NT_X500_PRINCIPAL,
+    as noted above.  All Kerberos names must conform to validity
+    requirements as given in RFC 1510.  Note that name mapping may be
+    required or optional, based on policy.
+
+    We also define the following similar ASN.1 structure:
+
+        CertPrincipalName ::= SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF UTF8String
+        }
+
+    When a Kerberos PrincipalName is to be placed within an X.509 data
+    structure, the CertPrincipalName structure is to be used, with the
+    name-string encoded as a single UTF8String.  The name-type should be
+    as identified in the original PrincipalName structure.  The mapping
+    between the GeneralString and UTF8String formats can be found in
+    [19].
+
+    The following rules relate to the the matching of PrincipalNames (or
+    corresponding CertPrincipalNames) with regard to the PKI name
+    constraints for CAs as laid out in RFC 2459 [15].  In order to be
+    regarded as a match (for permitted and excluded name trees), the
+    following must be satisfied.
+
+        1.  If the constraint is given as a user plus realm name, or
+            as a user plus instance plus realm name (as specified in
+            RFC 1510), the realm name must be valid (see 2.a-d below)
+            and the match must be exact, byte for byte.
+
+        2.  If the constraint is given only as a realm name, matching
+            depends on the type of the realm:
+
+            a.  If the realm contains a colon (':') before any equal
+                sign ('='), it is treated as a realm of type Other,
+                and must match exactly, byte for byte.
+
+            b.  Otherwise, if the realm contains an equal sign, it
+                is treated as an X.500 name.  In order to match, every
+                component in the constraint MUST be in the principal
+                name, and have the same value.  For example, 'C=US'
+                matches 'C=US/O=ISI' but not 'C=UK'.
+
+            c.  Otherwise, if the realm name conforms to rules regarding
+                the format of DNS names, it is considered a realm name of
+                type Domain.  The constraint may be given as a realm
+                name 'FOO.BAR', which matches any PrincipalName within
+                the realm 'FOO.BAR' but not those in subrealms such as
+                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
+                matches PrincipalNames in subrealms of the form
+                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
+
+            d.  Otherwise, the realm name is invalid and does not match
+                under any conditions.
+
+3.1.1.  Encryption and Key Formats
+
+    In the exposition below, we use the terms public key and private
+    key generically.  It should be understood that the term "public
+    key" may be used to refer to either a public encryption key or a
+    signature verification key, and that the term "private key" may be
+    used to refer to either a private decryption key or a signature
+    generation key.  The fact that these are logically distinct does
+    not preclude the assignment of bitwise identical keys for RSA
+    keys.
+
+    In the case of Diffie-Hellman, the key shall be produced from the
+    agreed bit string as follows:
+
+        * Truncate the bit string to the appropriate length.
+        * Rectify parity in each byte (if necessary) to obtain the key.
+
+    For instance, in the case of a DES key, we take the first eight
+    bytes of the bit stream, and then adjust the least significant bit
+    of each byte to ensure that each byte has odd parity.
+
+3.1.2. Algorithm Identifiers
+
+    PKINIT does not define, but does permit, the algorithm identifiers
+    listed below.
+
+3.1.2.1. Signature Algorithm Identifiers
+
+    The following signature algorithm identifiers specified in [11] and
+    in [15] shall be used with PKINIT:
+
+    id-dsa-with-sha1       (DSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    sha-1WithRSAEncryption (RSA with SHA1)
+
+3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
+
+    The following algorithm identifier shall be used within the
+    SubjectPublicKeyInfo data structure: dhpublicnumber
+
+    This identifier and the associated algorithm parameters are
+    specified in RFC 2459 [15].
+
+3.1.2.3. Algorithm Identifiers for RSA Encryption
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure, for encrypting the temporary key with a public key:
+
+        rsaEncryption (RSA encryption, PKCS#1 v1.5)
+        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
+
+    Both of the above RSA encryption schemes are specified in [16].
+    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
+    CMS specification says that it will likely include PKCS#1 v2.0 in
+    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
+    vulnerability discovered in PKCS#1 v1.5.)
+
+3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure in the PKINIT Reply, for encrypting the reply key with the
+    temporary key:
+        des-ede3-cbc (3-key 3-DES, CBC mode)
+        rc2-cbc      (RC2, CBC mode)
+
+    The full definition of the above algorithm identifiers and their
+    corresponding parameters (an IV for block chaining) is provided in
+    the CMS specification [11].
+
+3.2.  Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+3.2.1.  Client Request
+
+    Public keys may be signed by some certification authority (CA), or
+    they may be maintained by the KDC in which case the KDC is the
+    trusted authority.  Note that the latter mode does not require the
+    use of certificates.
+
+    The initial authentication request is sent as per RFC 1510, except
+    that a preauthentication field containing data signed by the user's
+    private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedData
+                                    -- Defined in CMS [11];
+                                    -- AuthPack (below) defines the
+                                    -- data that is signed.
+        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
+                                    -- This is a list of CAs that the
+                                    -- client trusts and that certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- As defined in CMS [11];
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it.
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
+                                    -- For example, this may be the
+                                    -- client's Diffie-Hellman
+                                    -- certificate, or it may be the
+                                    -- client's RSA encryption
+                                    -- certificate.
+    }
+
+    TrustedCas ::= CHOICE {
+        principalName         [0] KerberosName,
+                                  -- as defined below
+        caName                [1] Name
+                                  -- fully qualified X.500 name
+                                  -- as defined by X.509
+        issuerAndSerial       [2] IssuerAndSerialNumber
+                                  -- Since a CA may have a number of
+                                  -- certificates, only one of which
+                                  -- a client trusts
+    }
+
+    Usage of SignedData:
+
+        The SignedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  The following describes how to fill in the fields of
+        this data:
+
+        1.  The encapContentInfo field must contain the PKAuthenticator
+            and, optionally, the client's Diffie Hellman public value.
+
+            a.  The eContentType field shall contain the OID value for
+                pkauthdata: iso (1) org (3) dod (6) internet (1)
+                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
+
+            b.  The eContent field is data of the type AuthPack (below).
+
+        2.  The signerInfos field contains the signature of AuthPack.
+
+        3.  The Certificates field, when non-empty, contains the client's
+            certificate chain.  If present, the KDC uses the public key
+            from the client's certificate to verify the signature in the
+            request.  Note that the client may pass different certificate
+            chains that are used for signing or for encrypting.  Thus,
+            the KDC may utilize a different client certificate for
+            signature verification than the one it uses to encrypt the
+            reply to the client.  For example, the client may place a
+            Diffie-Hellman certificate in this field in order to convey
+            its static Diffie Hellman certificate to the KDC to enable
+            static-ephemeral Diffie-Hellman mode for the reply; in this
+            case, the client does NOT place its public value in the
+            AuthPack (defined below).  As another example, the client may
+            place an RSA encryption certificate in this field.  However,
+            there must always be (at least) a signature certificate.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+                                    -- (ephemeral-ephemeral only)
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+                                    -- for replay prevention as in RFC1510
+        ctime                   [1] KerberosTime,
+                                    -- for replay prevention as in RFC1510
+        nonce                   [2] INTEGER,
+        pachecksum              [3] Checksum
+                                    -- Checksum over KDC-REQ-BODY
+                                    -- Defined by Kerberos spec
+    }
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm                   AlgorithmIdentifier,
+                                    -- dhKeyAgreement
+        subjectPublicKey            BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [10]
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm                   OBJECT IDENTIFIER,
+                                    -- for dhKeyAgreement, this is
+                                    -- { iso (1) member-body (2) US (840)
+                                    -- rsadsi (113459) pkcs (1) 3 1 }
+                                    -- from PKCS #3 [20]
+        parameters                  ANY DEFINED by algorithm OPTIONAL
+                                    -- for dhKeyAgreement, this is
+                                    -- DHParameter
+    }   -- as specified by the X.509 recommendation [10]
+
+    DHParameter ::= SEQUENCE {
+        prime                       INTEGER,
+                                    -- p
+        base                        INTEGER,
+                                    -- g
+        privateValueLength          INTEGER OPTIONAL
+                                    -- l
+    }   -- as defined in PKCS #3 [20]
+
+    If the client passes an issuer and serial number in the request,
+    the KDC is requested to use the referred-to certificate.  If none
+    exists, then the KDC returns an error of type
+    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
+    other hand, the client does not pass any trustedCertifiers,
+    believing that it has the KDC's certificate, but the KDC has more
+    than one certificate.  The KDC should include information in the
+    KRB-ERROR message that indicates the KDC certificate(s) that a
+    client may utilize.  This data is specified in the e-data, which
+    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
+
+    TypedData ::=  SEQUENCE {
+                    data-type      [0] INTEGER,
+                    data-value     [1] OCTET STRING,
+    } -- per Kerberos RFC 1510 revisions
+
+    where:
+    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+    data-value = CertificateSet // as specified by CMS [11]
+
+    The PKAuthenticator carries information to foil replay attacks, to
+    bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
+    request and response.  The PKAuthenticator is signed with the client's
+    signature key.
+
+3.2.2.  KDC Response
+
+    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 client's certificate chain contains no certificate signed by
+    a CA trusted by the KDC, then the KDC sends back an error message
+    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
+    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
+    whose data-value is an OCTET STRING which is the DER encoding of
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+                              -- X.500 name encoded as a principal name
+                              -- see Section 3.1
+
+    If while verifying a certificate chain the KDC determines that the
+    signature on one of the certificates in the CertificateSet from
+    the signedAuthPack fails verification, then the KDC returns an
+    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
+    e-data is a SEQUENCE of one TypedData (with type
+    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
+    which is the DER encoding of the index into the CertificateSet
+    ordered as sent by the client.
+
+        CertificateIndex  ::= INTEGER
+                              -- 0 = 1st certificate,
+                              --     (in order of encoding)
+                              -- 1 = 2nd certificate, etc
+
+    The KDC may also check whether any of the certificates in the
+    client's chain has been revoked.  If one of the certificates has
+    been revoked, then the KDC returns an error of type
+    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
+    the certificate's revocation status is unknown or not
+    available, then if required by policy, the KDC returns the
+    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
+    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
+    cases, the affected certificate is identified by the accompanying
+    e-data, which contains a CertificateIndex as described for
+    KDC_ERR_INVALID_CERTIFICATE.
+
+    If the certificate chain can be verified, but the name of the
+    client in the certificate does not match the client's name in the
+    request, then the KDC returns an error of type
+    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+    field in this case.
+
+    Finally, if the certificate chain is verified, but the KDC's name
+    or realm as given in the PKAuthenticator does not match the KDC's
+    actual principal name, then the KDC returns an error of type
+    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
+    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
+    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
+    STRING whose data-value is the DER encoding of a PrincipalName or
+    Realm as defined in RFC 1510 revisions.
+
+    Even if all succeeds, the KDC may--for policy reasons--decide not
+    to trust the client.  In this case, the KDC returns an error message
+    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
+    the presence or absence of an Enhanced Key Usage (EKU) OID within
+    the certificate extensions.  The rules regarding acceptability of
+    an EKU sequence (or the absence of any sequence) are a matter of
+    local policy.  For the benefit of implementers, we define a PKINIT
+    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
+    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
+
+    If a trust relationship exists, the KDC then verifies the client's
+    signature on AuthPack.  If that fails, the KDC returns an error
+    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
+    timestamp (ctime and cusec) in the PKAuthenticator to assure that
+    the request is not a replay.  The KDC also verifies that its name
+    is specified in the PKAuthenticator.
+
+    If the clientPublicValue field is filled in, indicating that the
+    client wishes to use Diffie-Hellman key agreement, then the KDC
+    checks to see that the parameters satisfy its policy.  If they do
+    not (e.g., the prime size is insufficient for the expected
+    encryption type), then the KDC sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
+    private values for the response.
+
+    The KDC also checks that the timestamp in the PKAuthenticator is
+    within the allowable window and that the principal name and realm
+    are correct.  If the local (server) time and the client time in the
+    authenticator differ by more than the allowable clock skew, then the
+    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except as
+    follows.  The user's name in the ticket is determined by the
+    following decision algorithm:
+
+        1.  If the KDC has a mapping from the name in the certificate
+            to a Kerberos name, then use that name.
+            Else
+        2.  If the certificate contains the SubjectAltName extention
+            and the local KDC policy defines a mapping from the
+            SubjectAltName to a Kerberos name, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, mapping
+            mapping as necessary (e.g., as per RFC 2253 for X.500
+            names).  In this case the realm in the ticket shall be the
+            name of the certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subject alt name
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subject alt name may be kerberos/principal@realm format.  In
+    this case the realm name is not that of the CA but that of the
+    local realm doing the mapping (or some realm name chosen by that
+    realm).
+
+    If a non-KDC X.509 certificate contains the principal name within
+    the subjectAltName version 3 extension , that name may utilize
+    KerberosName as defined below, or, in the case of an S/MIME
+    certificate [17], may utilize the email address.  If the KDC
+    is presented with an S/MIME certificate, then the email address
+    within subjectAltName will be interpreted as a principal and realm
+    separated by the "@" sign, or as a name that needs to be
+    canonicalized.  If the resulting name does not correspond to a
+    registered principal name, then the principal name is formed as
+    defined in section 3.1.
+
+    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.  If the KDC has no
+    certificate signed by any of the trustedCertifiers, then it returns
+    an error of type KDC_ERR_KDC_NOT_TRUSTED.
+
+    KDCs should try to (in order of preference):
+    1. Use the KDC certificate identified by the serialNumber included
+       in the client's request.
+    2. Use a certificate issued to the KDC by the client's CA (if in the
+       middle of a CA key roll-over, use the KDC cert issued under same
+       CA key as user cert used to verify request).
+    3. Use a certificate issued to the KDC by one of the client's
+       trustedCertifier(s);
+    If the KDC is unable to comply with any of these options, then the
+    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
+    client.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with the Diffie Hellman derived key or a random key generated
+    for this particular response which is carried in the padata field of
+    the TGS-REP message.
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Hellman key exchange (if the
+                            -- client public value was present in the
+                            -- request).
+                            -- This choice MUST be supported
+                            -- by compliant implementations.
+        encKeyPack         [1] EnvelopedData,
+                            -- Defined in CMS
+                            -- The temporary key is encrypted
+                            -- using the client public key
+                            -- key
+                            -- SignedReplyKeyPack, encrypted
+                            -- with the temporary key, is also
+                            -- included.
+    }
+
+    Usage of SignedData:
+
+        When the Diffie-Hellman option is used, dhSignedData in
+        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
+        of the KDC.  The reply key used to encrypt part of the KDC reply
+        message is derived from the Diffie-Hellman exchange:
+
+        1.  Both the KDC and the client calculate a secret value
+            (g^ab mod p), where a is the client's private exponent and
+            b is the KDC's private exponent.
+
+        2.  Both the KDC and the client take the first N bits of this
+            secret value and convert it into a reply key.  N depends on
+            the reply key type.
+
+        3.  If the reply key is DES, N=64 bits, where some of the bits
+            are replaced with parity bits, according to FIPS PUB 74.
+
+        4.  If the reply key is (3-key) 3-DES, N=192 bits, where some
+            of the bits are replaced with parity bits, according to
+            FIPS PUB 74.
+
+        5.  The encapContentInfo field must contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field shall contain the OID value for
+                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
+                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
+
+            b.  The eContent field is data of the type KdcDHKeyInfo
+                (below).
+
+        6.  The certificates field must contain the certificates
+            necessary for the client to establish trust in the KDC's
+            certificate based on the list of trusted certifiers sent by
+            the client in the PA-PK-AS-REQ.  This field may be empty if
+            the client did not send to the KDC a list of trusted
+            certifiers (the trustedCertifiers field was empty, meaning
+            that the client already possesses the KDC's certificate).
+
+        7.  The signerInfos field is a SET that must contain at least
+            one member, since it contains the actual signature.
+
+    KdcDHKeyInfo ::= SEQUENCE {
+                              -- used only when utilizing Diffie-Hellman
+      nonce                 [0] INTEGER,
+                                -- binds responce to the request
+      subjectPublicKey      [2] BIT STRING
+                                -- Equals public exponent (g^a mod p)
+                                -- INTEGER encoded as payload of
+                                -- BIT STRING
+    }
+
+    Usage of EnvelopedData:
+
+        The EnvelopedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  It contains a temporary key encrypted with the PKINIT
+        client's public key.  It also contains a signed and encrypted
+        reply key.
+
+        1.  The originatorInfo field is not required, since that
+            information may be presented in the signedData structure
+            that is encrypted within the encryptedContentInfo field.
+
+        2.  The optional unprotectedAttrs field is not required for
+            PKINIT.
+
+        3.  The recipientInfos field is a SET which must contain exactly
+            one member of the KeyTransRecipientInfo type for encryption
+            with an RSA public key.
+
+            a.  The encryptedKey field (in KeyTransRecipientInfo)
+                contains the temporary key which is encrypted with the
+                PKINIT client's public key.
+
+        4.  The encryptedContentInfo field contains the signed and
+            encrypted reply key.
+
+            a.  The contentType field shall contain the OID value for
+                id-signedData: iso (1) member-body (2) us (840)
+                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
+
+            b.  The encryptedContent field is encrypted data of the CMS
+                type signedData as specified below.
+
+                i.  The encapContentInfo field must contains the
+                    ReplyKeyPack.
+
+                    * The eContentType field shall contain the OID value
+                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
+                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
+
+                    * The eContent field is data of the type ReplyKeyPack
+                      (below).
+
+                ii.  The certificates field must contain the certificates
+                     necessary for the client to establish trust in the
+                     KDC's certificate based on the list of trusted
+                     certifiers sent by the client in the PA-PK-AS-REQ.
+                     This field may be empty if the client did not send
+                     to the KDC a list of trusted certifiers (the
+                     trustedCertifiers field was empty, meaning that the
+                     client already possesses the KDC's certificate).
+
+                iii.  The signerInfos field is a SET that must contain at
+                      least one member, since it contains the actual
+                      signature.
+
+    ReplyKeyPack ::= SEQUENCE {
+                              -- not used for Diffie-Hellman
+        replyKey             [0] EncryptionKey,
+                                 -- used to encrypt main reply
+                                 -- ENCTYPE is at least as strong as
+                                 -- ENCTYPE of session key
+        nonce                [1] INTEGER,
+                                 -- binds response to the request
+                                 -- must be same as the nonce
+                                 -- passed in the PKAuthenticator
+    }
+
+    Since each certifier in the certification path of a user's
+    certificate is equivalent to a separate Kerberos realm, the name
+    of each certifier in the certificate chain must be added to the
+    transited field of the ticket.  The format of these realm names is
+    defined in Section 3.1 of this document.  If applicable, the
+    transit-policy-checked flag should be set in the issued ticket.
+
+    The KDC's certificate(s) must bind the public key(s) of the KDC to
+    a name derivable from the name of the realm for that KDC.  X.509
+    certificates shall contain the principal name of the KDC
+    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
+    3 extension. Below is the definition of this version 3 extension,
+    as specified by the X.509 standard:
+
+        subjectAltName EXTENSION ::= {
+            SYNTAX GeneralNames
+            IDENTIFIED BY id-ce-subjectAltName
+        }
+
+        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
+
+        GeneralName ::= CHOICE {
+            otherName       [0] OtherName,
+            ...
+        }
+
+        OtherName ::= SEQUENCE {
+            type-id         OBJECT IDENTIFIER,
+            value           [0] EXPLICIT ANY DEFINED BY type-id
+        }
+
+    For the purpose of specifying a Kerberos principal name, the value
+    in OtherName shall be a KerberosName as defined in RFC 1510, but with
+    the PrincipalName replaced by CertPrincipalName as mentioned in
+    Section 3.1:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] CertPrincipalName  -- defined above
+        }
+
+    This specific syntax is identified within subjectAltName by setting
+    the type-id in OtherName to krb5PrincipalName, where (from the
+    Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+    (This specification may also be used to specify a Kerberos name
+    within the user's certificate.)  The KDC's certificate may be signed
+    directly by a CA, or there may be intermediaries if the server resides
+    within a large organization, or it may be unsigned if the client
+    indicates possession (and trust) of the KDC's certificate.
+
+    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.  The client uses this
+    random key to decrypt the main reply, and subsequently proceeds as
+    described in RFC 1510.
+
+3.2.3. Required Algorithms
+
+    Not all of the algorithms in the PKINIT protocol specification have
+    to be implemented in order to comply with the proposed standard.
+    Below is a list of the required algorithms:
+
+    * Diffie-Hellman public/private key pairs
+        * utilizing Diffie-Hellman ephemeral-ephemeral mode
+    * SHA1 digest and DSA for signatures
+    * SHA1 digest also for the Checksum in the PKAuthenticator
+    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
+    * 3-key triple DES Temporary and Reply keys
+
+4.  Logistics and Policy
+
+    This section describes a way to define the policy on the use of
+    PKINIT for each principal and request.
+
+    The KDC is not required to contain a database record for users
+    who use public key authentication.  However, if these users are
+    registered with the KDC, it is recommended that the database record
+    for these users be modified to an additional flag in the attributes
+    field to indicate that the user should authenticate using PKINIT.
+    If this flag is set and a request message does not contain the
+    PKINIT preauthentication field, then the KDC sends back as error of
+    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
+    field of type PA-PK-AS-REQ must be included in the request.
+
+5.  Security Considerations
+
+    PKINIT raises a few security considerations, which we will address
+    in this section.
+
+    First of all, PKINIT introduces a new trust model, where KDCs do not
+    (necessarily) certify the identity of those for whom they issue
+    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
+    limited capacity of self-signing their certificates, but one of the
+    additional benefits is to align Kerberos authentication with a global
+    public key infrastructure.  Anyone using PKINIT in this way must be
+    aware of how the certification infrastructure they are linking to
+    works.
+
+    Secondly, PKINIT also introduces the possibility of interactions
+    between different cryptosystems, which may be of widely varying
+    strengths.  Many systems, for instance, allow the use of 512-bit
+    public keys.  Using such keys to wrap data encrypted under strong
+    conventional cryptosystems, such as triple-DES, is inappropriate;
+    it adds a weak link to a strong one at extra cost.  Implementors
+    and administrators should take care to avoid such wasteful and
+    deceptive interactions.
+
+    Lastly, PKINIT calls for randomly generated keys for conventional
+    cryptosystems.  Many such systems contain systematically "weak"
+    keys.  PKINIT implementations MUST avoid use of these keys, either
+    by discarding those keys when they are generated, or by fixing them
+    in some way (e.g., by XORing them with a given mask).  These
+    precautions vary from system to system; it is not our intention to
+    give an explicit recipe for them here.
+
+6.  Transport Issues
+
+    Certificate chains can potentially grow quite large and span several
+    UDP packets; this in turn increases the probability that a Kerberos
+    message involving PKINIT extensions will be broken in transit.  In
+    light of the possibility that the Kerberos specification will
+    require KDCs to accept requests using TCP as a transport mechanism,
+    we make the same recommendation with respect to the PKINIT
+    extensions as well.
+
+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] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
+    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
+    Authentication in Kerberos.  draft-ietf-cat-kerberos-pk-cross-04.txt
+
+    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
+    Kerberos.  draft-ietf-cat-kerberos-anoncred-00.txt
+
+    [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
+    Public Key Utilizing Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-02.txt
+
+    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
+    Request for Comments 2246, January 1999.
+
+    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
+    Distributed Systems.  In Proceedings of the 13th International
+    Conference on Distributed Computing Systems, May 1993.
+
+    [10] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+    [11] R. Housley. Cryptographic Message Syntax.
+    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
+    as RFC.
+
+    [12] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
+    Security, Inc. A Description of the RC2(r) Encryption Algorithm
+    March 1998.
+    Request for Comments 2268.
+
+    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+    Key Infrastructure, Certificate and CRL Profile, January 1999.
+    Request for Comments 2459.
+
+    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+    Specifications, October 1998.  Request for Comments 2437.
+
+    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
+    Version 2 Certificate Handling, March 1998.  Request for
+    Comments 2312.
+
+    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
+    Protocol (v3), December 1997.  Request for Comments 2251.
+
+    [19] ITU-T (formerly CCITT) Information Processing Systems - Open
+    Systems Interconnection - Specification of Abstract Syntax Notation
+    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
+
+    [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
+    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
+
+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 January 15, 2001.
+
+10. Authors
+
+    Brian Tung
+    Clifford Neuman
+    USC Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey CA 90292-6695
+    Phone: +1 310 822 1511
+    E-mail: {brian, bcn}@isi.edu
+
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road
+    Issaquah WA 98027-5378
+    Phone: +1 425 391 6000
+    E-mail: matt.hur@cybersafe.com
+
+    Ari Medvinsky
+    Keen.com, Inc.
+    150 Independence Drive
+    Menlo Park CA 94025
+    Phone: +1 650 289 3134
+    E-mail: ari@keen.com
+
+    Sasha Medvinsky
+    Motorola
+    6450 Sequence Drive
+    San Diego, CA 92121
+    +1 858 404 2367
+    E-mail: smedvinsky@gi.com
+
+    John Wray
+    Iris Associates, Inc.
+    5 Technology Park Dr.
+    Westford, MA 01886
+    E-mail: John_Wray@iris.com
+
+    Jonathan Trostle
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt
new file mode 100644
index 000000000000..6581dd5810a5
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt
@@ -0,0 +1,378 @@
+INTERNET-DRAFT                                    Ari Medvinsky
+draft-ietf-cat-kerberos-pk-tapp-03.txt            Keen.com, Inc.
+Expires January 14, 2001                          Matthew Hur
+Informational					  CyberSafe Corporation
+						  Sasha Medvinsky
+						  Motorola
+                                                  Clifford Neuman
+                                                  USC/ISI
+
+Public Key Utilizing Tickets for Application Servers (PKTAPP)
+
+
+0. Status Of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026.  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 on ftp.ietf.org (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-10.txt, and expires April 30,
+2000.  Please send comments to the authors.
+
+1. Abstract
+
+Public key based Kerberos for Distributed Authentication[1], (PKDA) 
+proposed by Sirbu & Chuang, describes PK based authentication that 
+eliminates the use of a centralized key distribution center while 
+retaining the advantages of Kerberos tickets.  This draft describes how, 
+without any modification, the PKINIT specification[2] may be used to 
+implement the ideas introduced in PKDA.  The benefit is that only a 
+single PK Kerberos extension is needed to address the goals of PKINIT & 
+PKDA.
+
+
+
+2. Introduction
+
+With the proliferation of public key cryptography, a number of public 
+key extensions to Kerberos have been proposed to provide 
+interoperability with the PK infrastructure and to improve the Kerberos 
+authentication system [4].  Among these are PKINIT[2] (under development
+in the CAT working group) and more recently PKDA [1] proposed by Sirbu & 
+Chuang of CMU.  One of the principal goals of PKINIT is to provide for 
+interoperability between a PK infrastructure and Kerberos.  Using 
+PKINIT, a user can authenticate to the KDC via a public key certificate.  
+A ticket granting ticket (TGT), returned by the KDC, enables a PK user 
+to obtain tickets and authenticate to kerberized services.  The PKDA 
+proposal goes a step further.  It supports direct client to server 
+authentication, eliminating the need for an online key distribution 
+center.  In this draft, we describe how, without any modification, the 
+PKINIT protocol may be applied to achieve the goals of PKDA. For direct 
+client to server authentication, the client will use PKINIT to 
+authenticate to the end server (instead of a central KDC), which then, 
+will issue a ticket for itself.  The benefit of this proposal, is that a 
+single PK extension to Kerberos can addresses the goals of PKINIT and 
+PKDA.
+
+
+3. PKDA background
+
+The PKDA proposal provides direct client to server authentication, thus 
+eliminating the need for an online key distribution center.  A client 
+and server take part in an initial PK based authentication exchange, 
+with an added caveat that the server acts as a Kerberos ticket granting 
+service and issues a traditional Kerberos ticket for itself.  In 
+subsequent communication, the client makes use of the Kerberos ticket, 
+thus eliminating the need for public key operations on the server.  This 
+approach has an advantage over SSL 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 Neuman[3]). 
+
+Below is a brief overview of the PKDA protocol.  For a more detailed 
+description see [1]. 
+
+SCERT_REQ: Client to Server
+The client requests a certificate from the server.  If the serverÆs 
+certificate is cached locally, SCERT_REQ and SCERT_REP are omitted.
+
+SCERT_REP:  Server to Client
+The server returns its certificate to the client.
+
+PKTGS_REQ: Client to Server
+The client sends a request for a service ticket to the server.  To 
+authenticate the request, the client signs, among other fields, a time 
+stamp and a newly generated symmetric key .  The time stamp is used to 
+foil replay attacks;  the symmetric key is used by the server to secure 
+the PKTGS_REP message. 
+The client provides a certificate in the request (the certificate 
+enables the server to verify the validity of the clientÆs signature) and 
+seals it along with the signed information using the serverÆs public 
+key.  
+
+ 
+PKTGS_REP:  Server to Client
+The server returns a service ticket (which it issued for itself) along 
+with the session key for the ticket.  The session key is protected by 
+the client-generated key from the PKTGS_REQ message.  
+
+AP_REQ:  Client to Server
+After the above exchange, the client can proceed in a normal fashion, 
+using the conventional Kerberos ticket in an AP_REQ message.
+
+
+4. PKINIT background
+
+One of the principal goals of PKINIT is to provide for interoperability 
+between a public key infrastructure and Kerberos.  Using a public key 
+certificate, a client can authenticate to the KDC and receive a TGT 
+which enables the client to obtain service tickets to kerberized 
+services..  In PKINIT, the AS-REQ and AS-REP messages remain the same; 
+new preauthentication data types are used to conduct the PK exchange.  
+Client and server certificates are exchanged via the preauthentication 
+data.  Thus, the exchange of certificates , PK authentication, and 
+delivery of a TGT can occur in two messages.
+
+Below is a brief overview of the PKINIT protocol.  For a more detailed 
+description see [2]. 
+
+PreAuthentication data of AS-REQ:  Client to Server
+The client sends a list of trusted certifiers, a signed PK 
+authenticator, and its certificate.  The PK authenticator, based on the 
+Kerberos authenticator, contains the name of the KDC, a timestamp, and a 
+nonce.
+
+PreAuthentication data of AS-REP:  Server to Client
+The server responds with its certificate and the key used for decrypting 
+the encrypted part of the AS-REQ.  This key is encrypted with the 
+clientÆs public key.
+
+AP_REQ:  Client to Server
+After the above exchange, the client can proceed in a normal fashion, 
+using the conventional Kerberos ticket in an AP_REQ message.
+
+
+5. Application of PKINIT to achieve equivalence to PKDA
+
+While PKINIT is normally used to retrieve a ticket granting ticket 
+(TGT), it may also be used to request an end service ticket.  When used 
+in this fashion, PKINIT is functionally equivalent to PKDA.  We 
+introduce the concept of a local ticket granting server (LTGS) to 
+illustrate how PKINIT may be used for issuing end service tickets based 
+on public key authentication.  It is important to note that the LTGS may 
+be built into an application server, or it may be a stand-alone server 
+used for issuing tickets within a well-defined realm, such as a single 
+machine.  We will discuss both of these options.
+
+
+5.1. The LTGS
+
+The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT 
+preauthentication data.  When a client submits an AS-REQ to the LTGS, it
+specifies an application server, in order to receive an end service 
+ticket instead of a TGT.
+
+
+5.1.1. The LTGS as a standalone server
+
+The LTGS may run as a separate process that serves applications which 
+reside on the same machine. This serves to consolidate administrative 
+functions and provide an easier migration path for a heterogeneous 
+environment consisting of both public key and Kerberos.  The LTGS would 
+use one well-known port (port #88 - same as the KDC) for all message 
+traffic and would share a symmetric with each service.  After the client 
+receives a service ticket, it then contacts the application server 
+directly.  This approach is similar to the one suggested by Sirbu , et 
+al [1].
+
+5.1.1.1. Ticket Policy for PKTAPP Clients
+
+It is desirable for the LTGS to have access to a PKTAPP client ticket
+policy. This policy will contain information for each client, such as 
+the maximum lifetime of a ticket, whether or not a ticket can be 
+forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for
+authentication and are not required to be registered as Kerberos 
+principals.
+
+As one possible solution, each public key Certification Authority could
+be registered in a secure database, along with the ticket policy 
+information for all PKTAPP clients that are certified by this
+Certification Authority.
+
+5.1.1.2. LTGS as a Kerberos Principal
+
+Since the LTGS serves only PKTAPP clients and returns only end service
+tickets for other services, it does not require a Kerberos service key 
+or a Kerberos principal identity. It is therefore not necessary for the
+LTGS to even be registered as a Kerberos principal.
+
+The LTGS still requires public key credentials for the PKINIT exchange,
+and it may be desired to have some global restrictions on the Kerberos
+tickets that it can issue. It is recommended (but not required) that
+this information be associated with a Kerberos principal entry for the
+LTGS.
+
+
+5.1.1.3. Kerberos Principal Database
+
+Since the LTGS issues tickets for Kerberos services, it will require
+access to a Kerberos principal database containing entries for at least
+the end services. Each entry must contain a service key and may also
+contain restrictions on the service tickets that are issued to clients.
+It is recommended that (for ease of administration) this principal
+database be centrally administered and distributed (replicated) to all
+hosts where an LTGS may be running.
+
+In the case that there are other clients that do not support PKINIT
+protocol, but still need access to the same Kerberos services, this
+principal database will also require entries for Kerberos clients and
+for the TGS entries.
+
+5.1.2. The LTGS as part of an application server
+
+The LTGS may be combined with an application server.  This accomplishes 
+direct client to application server authentication; however, it requires 
+that applications be modified to process AS-REQ and AS-REP messages.  
+The LTGS would communicate over the port assigned to the application 
+server or over the well known Kerberos port for that particular 
+application.
+
+5.1.2.2. Ticket Policy for PKTAPP Clients
+
+Application servers normally do not have access to a distributed 
+principal database. Therefore, they will have to find another means of
+keeping track of the ticket policy information for PKTAPP clients. It is
+recommended that this ticket policy be kept in a directory service (such
+as LDAP).  
+
+It is critical, however, that both read and write access to this ticket
+policy is restricted with strong authentication and encryption to only
+the correct application server.  An unauthorized party should not have
+the authority to modify the ticket policy. Disclosing the ticket policy
+to a 3rd party may aid an adversary in determining the best way to
+compromise the network.
+
+It is just as critical for the application server to authenticate the
+directory service. Otherwise an adversary could use a man-in-the-middle
+attack to substitute a false ticket policy with a false directory
+service.
+
+5.1.2.3. LTGS Credentials
+
+Each LTGS (combined with an application service) will require public key
+credentials in order to use the PKINIT protocol. These credentials can 
+be stored in a single file that is both encrypted with a password-
+derived symmetric key and also secured by an operating system. This
+symmetric key may be stashed somewhere on the machine for convenience,
+although such practice potentially weakens the overall system security
+and is strongly discouraged.
+
+For added security, it is recommended that the LTGS private keys are
+stored inside a temper-resistant hardware module that requires a pin
+code for access.
+
+
+5.1.2.4. Compatibility With Standard Kerberos
+
+Even though an application server is combined with the LTGS, for
+backward compatibility it should still accept service tickets that have
+been issued by the KDC. This will allow Kerberos clients that do not
+support PKTAPP to authenticate to the same application server (with the
+help of a KDC).
+
+5.1.3. Cross-Realm Authentication
+
+According to the PKINIT draft, the client's realm is the X.500 name of
+the Certification Authority that issued the client certificate. A 
+Kerberos application service will be in a standard Kerberos realm, which
+implies that the LTGS will need to issue cross-realm end service 
+tickets. This is the only case, where cross-realm end service tickets
+are issued. In a standard Kerberos model, a client first acquires a
+cross-realm TGT, and then gets an end service ticket from the KDC that
+is in the same realm as the application service.
+
+6. Protocol differences between PKINIT and PKDA
+
+Both PKINIT and PKDA will accomplish the same goal of issuing end 
+service tickets, based on initial public key authentication.  A PKINIT-
+based implementation and a PKDA implementation would be functionally 
+equivalent.  The primary differences are that 1)PKDA requires the client 
+to create the symmetric key while PKINIT requires the server to create 
+the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes 
+in four messages.
+
+7. Summary
+
+The PKINIT protocol can be used, without modification to facilitate 
+client to server authentication without the use of a central KDC.  The 
+approach described in this draft  (and originally proposed in PKDA[1]) 
+is essentially a public key authentication protocol that retains the 
+advantages of Kerberos tickets.
+
+Given that PKINIT has progressed through the CAT working group of the 
+IETF, with plans for non-commercial distribution (via MITÆs v5 Kerberos)  
+as well as commercial support, it is worthwhile to provide PKDA 
+functionality, under the PKINIT umbrella.
+
+8. Security Considerations
+
+PKTAPP is based on the PKINIT protocol and all security considerations
+already listed in [2] apply here.
+
+When the LTGS is implemented as part of each application server, the
+secure storage of its public key credentials and of its ticket policy
+are both a concern.  The respective security considerations are already
+covered in sections 5.1.2.3 and 5.1.2.2 of this document.  
+
+
+9. Bibliography
+
+[1] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
+Public Key Cryptography.  Symposium On Network and Distributed System 
+Security, 1997.
+
+[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
+J. Trostle.  Public Key Cryptography for Initial Authentication in
+Kerberos.  Internet Draft, October 1999. 
+(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt)
+
+[3] C. Neuman, Proxy-Based Authorization and Accounting for 
+Distributed Systems.  In Proceedings of the 13th International 
+Conference on Distributed Computing Systems, May 1993.
+
+[4] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
+(V5).  Request for Comments 1510.
+
+10.  Expiration Date
+
+This draft expires April 24, 2000.
+
+11. Authors
+
+Ari Medvinsky
+Keen.com, Inc.
+150 Independence Dr.
+Menlo Park, CA 94025
+Phone +1 650 289 3134
+E-mail: ari@keen.com
+
+Matthew Hur
+CyberSafe Corporation
+1605 NW Sammamish Road
+Issaquah, WA 98027-5378
+Phone: +1 425 391 6000
+E-mail: matt.hur@cybersafe.com
+
+Alexander Medvinsky
+Motorola
+6450 Sequence Dr.
+San Diego, CA 92121
+Phone: +1 858 404 2367
+E-mail: smedvinsky@gi.com
+
+Clifford Neuman
+USC Information Sciences Institute
+4676 Admiralty Way Suite 1001
+Marina del Rey CA 90292-6695
+Phone: +1 310 822 1511
+E-mail: bcn@isi.edu
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
new file mode 100644
index 000000000000..15921248c117
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
@@ -0,0 +1,6866 @@
+INTERNET-DRAFT                                           Clifford Neuman
+                                                               John Kohl
+                                                           Theodore Ts'o
+                                                          March 10, 2000
+                                              Expires September 10, 2000
+
+The Kerberos Network Authentication Service (V5)
+draft-ietf-cat-kerberos-revisions-05.txt
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC 2026. 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 on ftp.ietf.org (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-revisions-05.txt, and expires September 10, 2000.
+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.
+
+The motivations, goals, assumptions, and rationale behind most design
+decisions are treated cursorily; they are more fully described in a paper
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+Separately authenticated authorization credentials may be embedded in a
+tickets authorization data when encapsulated by the kdc-issued authorization
+data element.
+
+Applications should not be modified to accept the mere issuance of a service
+ticket by the Kerberos server (even by a 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.
+   * 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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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).
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+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).
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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<>].
+
+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
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+(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.
+
+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
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.'
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+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
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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:
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     "/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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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.
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+4. The Kerberos Database
+
+The Kerberos server must have access to a database containing 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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+field would be used to indicate how long old keys must remain valid to allow
+the continued use of outstanding tickets.
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+PrincipalName ::=   SEQUENCE {
+                    name-type[0]     INTEGER,
+                    name-string[1]   SEQUENCE OF GeneralString
+}
+
+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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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),
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                  -- unused7(7),
+                  -- renewable(8),
+                  -- unused9(9),
+                  -- unused10(10),
+                  -- 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: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          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 optional field contains a sequence of extentions that may be used
+     to carry information that must be carried with the ticket to support
+     several 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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     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.
+
+          4           PROXY
+                                   When set, this  flag  indicates  that  a
+                                   ticket is a proxy.
+
+          5           MAY-POSTDATE
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                   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.
+
+          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,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                   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.
+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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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 Kerberos 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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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, except when an entry is separately authenticated by
+     encapulation in the kdc-issued element, 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),
+     may obtain 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.
+     Alternatively, such authorization credentials may be embedded in the
+     ticket authenticating the authorized entity, when the authorization is
+     separately authenticated using the kdc-issued authorization data
+     element (see B.4).
+
+     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.
+
+5.3.2. Authenticators
+
+An authenticator is a record sent with a ticket to a server to certify the
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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
+}
+
+The fields in this message are:
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+padata-type
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+         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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+         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.
+
+         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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                      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.
+
+         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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                      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.
+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].
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+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,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+              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.
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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)
+}
+
+
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                  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
+}
+
+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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+}
+
+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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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
+}
+
+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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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,
+                 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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+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,
+}
+
+
+
+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.
+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:
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     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.
+
+     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], and triple DES variants, 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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+          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 for some methods is
+     described in the following diagram, but other methods may deviate from
+     this layour - so long as the definition of the method defines the
+     layout actually in use.
+
+           +-----------+----------+-------------+-----+
+           |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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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)
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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;
+               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 and
+     without Key Derivation [Original draft by Marc Horowitz, revisions by
+     David Miller]
+
+     This encryption type is based on the Triple DES cryptosystem, the
+     HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key
+     derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may not
+     be used in conjunction with the use of Triple DES keys.
+
+     Algorithm Identifiers
+
+     The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
+     The des3-cbc-hmac-sha1-kd encryption type, specifying the key
+     derivation variant of the encryption type, has been assigned the value
+     16. The hmac-sha1-des3 checksum type has been assigned the value 13.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     The hmac-sha1-des3-kd checksum type, specifying the key derivation
+     variant of the checksum, has been assigned the value 12.
+
+     Triple DES Key Production
+
+     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.
+
+     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.
+
+     The string-to-key function is used to tranform UNICODE passwords into
+     DES3 keys. The DES3 string-to-key function relies on the "N-fold"
+     algorithm, which is detailed in [9]. The description of the N-fold
+     algorithm in that document is as follows:
+        o To n-fold a number X, replicate the input value to a length that
+          is the least common multiple of n and the length of X. Before each
+          repetition, the input is rotated to the right by 13 bit positions.
+          The successive n-bit chunks are added together using
+          1's-complement addition (that is, addition with end-around carry)
+          to yield an n-bit result"
+        o The n-fold algorithm, as with DES string-to-key, is applied to the
+          password string concatenated with a salt value. The salt value is
+          derived in the same was as for the DES string-to-key algorithm.
+          For 3-key triple DES then, the operation will involve a 168-fold
+          of the input password string. The remainder of the string-to-key
+          function for DES3 is shown here in pseudocode:
+
+     DES3string-to-key(passwordString, key)
+
+         salt = name_to_default_salt(realm, name)
+         s = passwordString + salt
+         tmpKey1 = 168-fold(s)
+         parityFix(tmpKey1);
+         if not weakKey(tmpKey1)
+             /*
+              * Encrypt temp key in itself with a
+              * zero initialization vector
+              *
+              * Function signature is DES3encrypt(plain, key, iv)
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+              * with cipher as the return value
+              */
+             tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec)
+             /*
+              * Encrypt resultant temp key in itself with third component
+              * of first temp key as initialization vector
+              */
+             key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2])
+             parityFix(key)
+             if not weakKey(key)
+                  return SUCCESS
+             else
+                  return FAILURE
+         else
+             return FAILURE
+
+     The weakKey function above is the same weakKey function used with DES
+     keys, but applied to each of the three single DES keys that comprise
+     the triple DES key.
+
+     The lengths of UNICODE encoded character strings include the trailing
+     terminator character (0).
+
+     Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd
+
+     EncryptedData using this type must be generated as described in
+     [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode.
+     The checksum algorithm is HMAC-SHA1. If the key derivation variant of
+     the encryption type is used, encryption key values are modified
+     according to the method under the Key Derivation section below.
+
+     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 Types hmac-sha1-des3 and hmac-sha1-des3-kd
+
+     Checksums using this type must be generated as described in
+     [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key
+     derivation variant of the checksum type is used, checksum key values
+     are modified according to the method under the Key Derivation section
+     below.
+
+     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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     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)
+      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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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 required 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.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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:
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     |  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 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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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 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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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).
+
+     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:
+        o the Unspecified Address
+        o the Loopback Address
+        o 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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+  <reserved>                     4
+  des3-cbc-md5                   5     8           0                 8
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+  <reserved>                     6
+  des3-cbc-sha1                  7     8           0                 8
+  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)
+  des3-cbc-sha1-kd              16                                 (Tom Yu)
+  rc4-hmac                      23                                 (swift)
+  rc4-hmac-exp                  24                                 (swift)
+
+  ENCTYPE_PK_CROSS              48                      (reserved for pkcross)
+  <reserved>                    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 (drop rsa ?)
+  rsa-md5                    7                   16 (drop rsa ?)
+  rsa-md5-des                8                   24 (drop rsa ?)
+  rsa-md5-des3               9                   24 (drop rsa ?)
+  hmac-sha1-des3-kd          12                  20
+  hmac-sha1-des3             13                  20
+
+  padata type                     padata-type value
+
+  PA-TGS-REQ                      1
+  PA-ENC-TIMESTAMP                2
+  PA-PW-SALT                      3
+  <reserved>                      4
+  PA-ENC-UNIX-TIME                5                  (depricated)
+  PA-SANDIA-SECUREID              6
+  PA-SESAME                       7
+  PA-OSF-DCE                      8
+  PA-CYBERSAFE-SECUREID           9
+  PA-AFS3-SALT                    10
+  PA-ETYPE-INFO                   11
+  PA-SAM-CHALLENGE                12                  (sam/otp)
+  PA-SAM-RESPONSE                 13                  (sam/otp)
+  PA-PK-AS-REQ                    14                  (pkinit)
+  PA-PK-AS-REP                    15                  (pkinit)
+  PA-USE-SPECIFIED-KVNO           20
+  PA-SAM-REDIRECT                 21                  (sam/otp)
+  PA-GET-FROM-TYPED-DATA          22
+  PA-SAM-ETYPE-INFO               23                  (sam/otp)
+
+data-type                     value    form of typed-data
+
+<reserved>                      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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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
+AD-OSF-DCE-PKI-CERTID              66         (hemsath@us.ibm.com)
+
+Ticket Extension Types
+
+TE-TYPE-NULL                  0      Null ticket extension
+TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
+<reserved>                    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
+<reserved>                    5      TE-TYPE-DEST-HOST (I have reservations)
+
+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]
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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 prot vers number 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
+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)
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+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.
+
+     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.
+
+     Encryption: DES-CBC-MD5, one triple des variant (tbd)
+     Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd)
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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).
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+               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).
+
+     [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.
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
+               Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
+               md5-01.txt, August, 1996.
+
+     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
+
+     A.2. KRB_AS_REQ verification and KRB_AS_REP generation
+
+             decode message into req;
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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
+                     set new_tkt.flags.PROXIABLE;
+             endif
+
+             if (req.kdc-options.ALLOW-POSTDATE is set) then
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     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,
+                                     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 */
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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);
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+             /* 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
+                     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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;
+             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);
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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
+
+             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 */
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                             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
+                     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);
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     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
+                             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,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                            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;
+             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,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                      * 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;
+             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,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                             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
+
+     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 */
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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);
+             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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                    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);
+
+     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;
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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);
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     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
+                     /* 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 */
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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;
+
+     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;
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     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
+                     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             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
+
+     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
+
+     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
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+          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.
+
+     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
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     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
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     [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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     [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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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.
+
+     [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
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     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/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
new file mode 100644
index 000000000000..ae79e8a7c4fb
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
@@ -0,0 +1,7301 @@
+INTERNET-DRAFT                                              Clifford Neuman
+                                                                  John Kohl
+                                                              Theodore Ts'o
+                                                              July 14, 2000
+                                                   Expires January 14, 2001
+
+The Kerberos Network Authentication Service (V5)
+
+
+draft-ietf-cat-kerberos-revisions-06.txt
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC 2026. 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 on ftp.ietf.org (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-revisions-06.txt, and expires January 14, 2001.
+Please send comments to: krb-protocol@MIT.EDU
+
+     This document is getting closer to a last call, but there are several
+     issues to be discussed. Some, but not all of these issues, are
+     highlighted in comments in the draft. We hope to resolve these issues
+     on the mailing list for the Kerberos working group, leading up to and
+     during the Pittsburgh IETF on a section by section basis, since this
+     is a long document, and it has been difficult to consider it as a
+     whole. Once sections are agreed to, it is out intent to issue the more
+     formal WG and IETF last calls.
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+authentication of 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.
+
+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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [JBrezak] Should there be a section here on how clients determine what
+     realm a service is in? Something like:
+
+     The client may not immediately know what realm a particular service
+     principal is in. There are 2 basic mechanisms that can be used to
+     determine the realm of a service. The first requires that the client
+     fully specify the service principal including the realm in the
+     Kerberos protocol request. If the Kerberos server for the specified
+     realm does not have a principal that exactly matches the service in
+     the request, the Kerberos server will return an error indicating that
+     the service principal was not found. Alternatively the client can make
+     a request providing just the service principal name and requesting
+     name canonicalization from the Kerberos server. The Kerberos server
+     will attempt to locate a service principal in its database that best
+     matches the request principal or provide a referral to another
+     Kerberos realm that may be contain the requested service principal.
+
+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.
+Separately authenticated authorization credentials may be embedded in a
+tickets authorization data when encapsulated by the kdc-issued
+authorization data element.
+
+Applications should not be modified to accept the mere issuance of a
+service ticket by the Kerberos server (even by a 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: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+   * 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).
+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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+2.7 Name canonicalization [JBrezak]
+
+If a client does not have the full name information for a principal, it can
+request that the Kerberos server attempt to lookup the name in its database
+and return a canonical form of the requested principal or a referral to a
+realm that has the requested principal in its namespace. Name
+canonicalization allows a principal to have alternate names. Name
+canonicalization must not be used to locate principal names supplied from
+wildcards and is not a mechanism to be used to search a Kerberos database.
+
+The CANONICALIZE flag in a ticket request is used to indicate to the
+Kerberos server that the client will accept an alternative name to the
+principal in the request or a referral to another realm. Both the AS and
+TGS must be able to interpret requests with this flag.
+
+By using this flag, the client can avoid extensive configuration needed to
+map specific host names to a particular realm.
+
+2.8. 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.
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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<>].
+
+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; whether
+the client requests name-canonicalization; 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
+the requested client principal named in the request is not found in its
+database, then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is
+returned. If the request had the CANONICALIZE option set, then the AS can
+attempt to lookup the client principal name in an alternate database, if it
+is found an error message with a KDC_ERR_WRONG_REALM error code and the
+cname and crealm in the error message must contain the true client
+principal name and realm.
+
+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].
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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. DES3-CBC-SHA1 and DES3-CBC-SHA1-KD), 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.
+
+     JBrezak - the behavior of PW-SALT, and ETYPE-INFO should be explained
+     here; also about using keys that have different string-to-key
+     functions like AFSsalt
+
+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 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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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. If the client set the CANONICALIZE option and a
+KDC_ERR_WRONG_REALM error was returned, the AS request should be retried to
+the realm and client principal name specified in the error message crealm
+and cname field respectively.
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.'
+
+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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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 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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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 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: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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 it is
+known. If the client does know the service principal name and realm and it
+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.
+
+If the client does not know the realm of the service or the true service
+principal name, then the CANONICALIZE option must be used in the request.
+This will cause the TGS to locate the service principal based on the target
+service name in the ticket and return the service principal name in the
+response. Alternatively, the Kerberos server may return a TGT for a realm
+which is 'closer' to the desired realm (further along the standard
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+hierarchical path) or the realm that may contain the requested service
+principal name in a request with the CANONCALIZE option set [JBrezak], 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. If the CANONICALIZE option is
+set in the KRB_TGS_REQ, then the requested service name may not be the true
+principal name or the service may not be in the TGS realm.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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. If the CANONICALIZE option is set, the TGS may return a
+ticket containing the server name of the true service principal. If the
+requested server cannot be found in the TGS database, then a TGT for
+another trusted realm may be returned instead of a ticket for the service.
+This TGT is a referral mechanism to cause the client to retry the request
+to the realm of the TGT. These are the only cases where the response for
+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.
+
+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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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. The server name returned in the reply is the true principal name of
+the service. See section A.7 for pseudocode.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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 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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+4. The Kerberos Database
+
+The Kerberos server must have access to a database containing 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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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].
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.2. 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
+}
+
+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
+}
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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 io
+                  -- reserved(0),
+                  -- forwardable(1),
+                  -- forwarded(2),
+                  -- proxiable(3),
+                  -- proxy(4),
+                  -- allow-postdate(5),
+                  -- postdated(6),
+                  -- unused7(7),
+                  -- renewable(8),
+                  -- unused9(9),
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                  -- unused10(10),
+                  -- unused11(11),
+                  -- unused12(12),
+                  -- unused13(13),
+                  -- requestanonymous(14),
+                  -- canonicalize(15),
+                  -- 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: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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 optional field contains a sequence of extentions that may be used
+     to carry information that must be carried with the ticket to support
+     several 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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+          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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+          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.
+
+          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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                                   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.
+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 Kerberos
+     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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+     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, except when an entry is separately authenticated by
+     encapulation in the kdc-issued element, 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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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),
+     may obtain 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. Alternatively, such authorization credentials
+     may be embedded in the ticket authenticating the authorized entity,
+     when the authorization is separately authenticated using the
+     kdc-issued authorization data element (see B.4).
+
+     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.
+
+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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+     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
+}
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+}
+
+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. When
+     this field is used to authenticate or pre-authenticate a request, it
+     should contain a keyed checksum over the KDC-REQ-BODY to bind the
+     pre-authentication data to rest of the request. The KDC, as a matter
+     of policy, may decide whether to honor a KDC-REQ which includes any
+     pre-authentication data that does not contain the checksum field.
+     PA-ENC-TIMESTAMP defines a pre-authentication data type that is used
+     for authenticating a client by way of an encrypted timestamp. This is
+     accomplished with a padata field with padata-type equal to
+     PA-ENC-TIMESTAMP and padata-value defined as follows (query: the
+     checksum is new in this definition. If the optional field will break
+     things we can keep the old PA-ENC-TS-ENC, and define a new alternate
+     form that includes the checksum). :
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+          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,
+                          pachecksum[2]      checksum OPTIONAL
+                                             -- keyed checksum of
+KDC-REQ-BODY
+          }
+
+     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.
+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:
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+        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.
+
+         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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+         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       RESERVED
+                                      Reserved for PK-Cross
+
+         10-13     UNUSED
+                                      These options are presently unused.
+
+         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      CANONICALIZE
+                                      The CANONICALIZE option indicates that
+                                      the client will accept the return of a
+                                      true server name instead of the name
+                                      specified in the request. In addition
+                                      the client will be able to process
+                                      any TGT referrals that will direct
+                                      the client to another realm to locate
+                                      the requested server. If a KDC does
+                                      not support name- canonicalization,
+                                      the option is ignored and the
+                                      appropriate
+                                      KDC_ERR_C_PRINCIPAL_UNKNOWN or
+                                      KDC_ERR_S_PRINCIPAL_UNKNOWN error is
+                                      returned. [JBrezak]
+
+         16-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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                                      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.
+
+         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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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. If the CANONICALIZE option is set, the
+     realm is used as a hint to the KDC for its database lookup.
+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.
+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. When he
+     ENC-TKT-IN-SKEY option is used for user-to-user authentication, this
+     addional ticket may be a TGT issued by the local realm or an
+     inter-realm TGT issued for the current KDC's realm by a remote KDC. 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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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)
+}
+
+
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+}
+
+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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+}
+
+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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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
+}
+
+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
+}
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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,
+                 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: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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,
+}
+
+
+
+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.
+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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+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.
+
+     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], and triple DES variants, 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.
+
+     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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 for some
+     methods is described in the following diagram, but other methods may
+     deviate from this layour - so long as the definition of the method
+     defines the layout actually in use.
+
+           +-----------+----------+-------------+-----+
+           |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
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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:
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+          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;
+               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 and
+     without Key Derivation [Original draft by Marc Horowitz, revisions by
+     David Miller]
+
+          There are still a few pieces of this specification to be included
+          by falue, rather than by reference. This will be done before the
+          Pittsburgh IETF.
+     This encryption type is based on the Triple DES cryptosystem, the
+     HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key
+     derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may
+     not be used in conjunction with the use of Triple DES keys.
+
+     Algorithm Identifiers
+
+     The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
+     The des3-cbc-hmac-sha1-kd encryption type, specifying the key
+     derivation variant of the encryption type, has been assigned the value
+     16. The hmac-sha1-des3 checksum type has been assigned the value 13.
+     The hmac-sha1-des3-kd checksum type, specifying the key derivation
+     variant of the checksum, has been assigned the value 12.
+
+     Triple DES Key Production
+
+     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: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     The string-to-key function is used to tranform UNICODE passwords into
+     DES3 keys. The DES3 string-to-key function relies on the "N-fold"
+     algorithm, which is detailed in [9]. The description of the N-fold
+     algorithm in that document is as follows:
+        o To n-fold a number X, replicate the input value to a length that
+          is the least common multiple of n and the length of X. Before
+          each repetition, the input is rotated to the right by 13 bit
+          positions. The successive n-bit chunks are added together using
+          1's-complement addition (that is, addition with end-around carry)
+          to yield an n-bit result"
+        o The n-fold algorithm, as with DES string-to-key, is applied to
+          the password string concatenated with a salt value. The salt
+          value is derived in the same was as for the DES string-to-key
+          algorithm. For 3-key triple DES then, the operation will involve
+          a 168-fold of the input password string. The remainder of the
+          string-to-key function for DES3 is shown here in pseudocode:
+
+     DES3string-to-key(passwordString, key)
+
+         salt = name_to_default_salt(realm, name)
+         s = passwordString + salt
+         tmpKey1 = 168-fold(s)
+         parityFix(tmpKey1);
+         if not weakKey(tmpKey1)
+             /*
+              * Encrypt temp key in itself with a
+              * zero initialization vector
+              *
+              * Function signature is DES3encrypt(plain, key, iv)
+              * with cipher as the return value
+              */
+             tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec)
+             /*
+              * Encrypt resultant temp key in itself with third component
+              * of first temp key as initialization vector
+              */
+             key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2])
+             parityFix(key)
+             if not weakKey(key)
+                  return SUCCESS
+             else
+                  return FAILURE
+         else
+             return FAILURE
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     The weakKey function above is the same weakKey function used with DES
+     keys, but applied to each of the three single DES keys that comprise
+     the triple DES key.
+
+     The lengths of UNICODE encoded character strings include the trailing
+     terminator character (0).
+
+     Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd
+
+     EncryptedData using this type must be generated as described in
+     [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC
+     mode. The checksum algorithm is HMAC-SHA1. If the key derivation
+     variant of the encryption type is used, encryption key values are
+     modified according to the method under the Key Derivation section
+     below.
+
+     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 Types hmac-sha1-des3 and hmac-sha1-des3-kd
+
+     Checksums using this type must be generated as described in
+     [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key
+     derivation variant of the checksum type is used, checksum key values
+     are modified according to the method under the Key Derivation section
+     below.
+
+     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)
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+      8. TGS-REP encrypted part (includes application session key),
+         encrypted with the tgs session key (section 5.4.2)
+      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: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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 required 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: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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 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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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 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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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 (/). Though domain names themselves are case insensitive, in
+     order for realms to match, the case must match as well. When
+     establishing a new realm name based on an internet domain name it is
+     recommended by convention that the characters be converted to upper
+     case.
+
+     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.
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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, DCE
+principal)
+    NT-SRV-INST       2   Service and other unique instance (krbtgt)
+    NT-SRV-HST        3   Service with host name as instance (telnet, rcmds)
+    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]
+    NT-SMTP-NAME      7   Name in form of SMTP email name (e.g.
+user@foo.com)
+
+     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.
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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 SMTP allows a name to be of a form that resembles a
+     SMTP email name. This name type can be used in conjunction with
+     name-canonicalization to allow a free-form of username to be specified
+     as a client name and allow the KDC to determine the Kerberos principal
+     name for the requested name. [JBrezak]
+
+     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).
+
+     Internet (IPv6) Addresses [Westerlund]
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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:
+        o the Unspecified Address
+        o the Loopback Address
+        o 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.
+
+     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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  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
+     reserved                       4
+     des3-cbc-md5                   5     8           0                 8
+     reserved                       6
+     des3-cbc-sha1                  7     8           0                 8
+     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)
+     des3-cbc-sha1-kd              16                                 (Tom
+Yu)
+     rc4-hmac                      23
+(swift)
+     rc4-hmac-exp                  24
+(swift)
+
+     reserved                      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 (drop rsa ?)
+     rsa-md5                    7                   16 (drop rsa ?)
+     rsa-md5-des                8                   24 (drop rsa ?)
+     rsa-md5-des3               9                   24 (drop rsa ?)
+     hmac-sha1-des3-kd          12                  20
+     hmac-sha1-des3             13                  20
+     sha1 (unkeyed)             14                  20
+
+     padata type                     padata-type value
+
+     PA-TGS-REQ                      1
+     PA-ENC-TIMESTAMP                2
+     PA-PW-SALT                      3
+     reserved                        4
+     PA-ENC-UNIX-TIME                5                  (depricated)
+     PA-SANDIA-SECUREID              6
+     PA-SESAME                       7
+     PA-OSF-DCE                      8
+     PA-CYBERSAFE-SECUREID           9
+     PA-AFS3-SALT                    10
+     PA-ETYPE-INFO                   11
+     PA-SAM-CHALLENGE                12                  (sam/otp)
+     PA-SAM-RESPONSE                 13                  (sam/otp)
+     PA-PK-AS-REQ                    14                  (pkinit)
+     PA-PK-AS-REP                    15                  (pkinit)
+     PA-USE-SPECIFIED-KVNO           20
+     PA-SAM-REDIRECT                 21                  (sam/otp)
+     PA-GET-FROM-TYPED-DATA          22
+     PA-SAM-ETYPE-INFO               23                  (sam/otp)
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     data-type                     value    form of typed-data
+
+     reserved                        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
+     TD-APP-DEFINED-ERROR            106
+
+     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
+     AD-OSF-DCE-PKI-CERTID              66    (hemsath@us.ibm.com)
+     AD-WIN200-PAC                     128
+(jbrezak@exchange.microsoft.com)
+
+     Ticket Extension Types
+
+     TE-TYPE-NULL                  0     Null ticket extension
+     TE-TYPE-EXTERNAL-ADATA        1     Integrity protected authorization
+data
+     reserved                      2     TE-TYPE-PKCROSS-KDC
+     TE-TYPE-PKCROSS-CLIENT        3     PKCROSS cross realm key ticket
+     TE-TYPE-CYBERSAFE-EXT         4     Assigned to CyberSafe Corp
+     reserved                      5     TE-TYPE-DEST-HOST
+
+     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
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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 number
+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
+     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 to reset
+     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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.
+
+     Encryption: DES-CBC-MD5, one triple des variant (tbd)
+     Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd)
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [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).
+
+     [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.
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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
+
+     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     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
+                     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;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             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,
+
+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;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             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);
+
+     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     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
+                     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
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             body.enc-authorization-data := user-supplied data;
+             if (body.kdc-options.ENC-TKT-IN-SKEY) then
+                     body.additional-tickets_ticket := second TGT;
+             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
+
+             set computed_checksum := checksum(req);
+             if (computed_checksum != auth_hdr.authenticatory.cksum) then
+                     error_out(KRB_AP_ERR_MODIFIED);
+             endif
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+
+             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
+                     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     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
+                             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);
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+
+                     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;
+             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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                             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;
+             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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     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
+
+     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     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);
+             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);
+
+     A.11. KRB_AP_REP generation
+
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_AP_REP */
+
+             body.ctime := packet.ctime;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             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);
+
+     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;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             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
+                     /* 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;
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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;
+
+     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     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
+                     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
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                (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
+
+     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
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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           SEQUENCE {
+                             te-type[0]       INTEGER,
+                             te-checksum[0]    Checksum
+     }
+
+     An authorization data element of type mandatory-ticket-extensions
+     specifies the type and 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 of the
+     type indicated. 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 type and
+     checksum do not match that checksum specified in the authorization
+     data element. Note that although the type is redundant for the
+     purposes of the comparison, it makes the comparison easier when
+     multiple extensions are present. Application servers that do not
+     implement this element must reject tickets that contain authorization
+     data elements of this type.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     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.
+
+     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.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     ----------------------------------------------------------------------
+     [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.
+
+     [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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [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.
+
+     [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.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [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.
+
+     [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/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
new file mode 100644
index 000000000000..6f7dae0dea70
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
@@ -0,0 +1,325 @@
+
+INTERNET-DRAFT                                        Mike Swift 
+draft-ietf-cat-kerberos-set-passwd-02.txt             Microsoft
+March 2000                                            Jonathan Trostle
+                                                      Cisco Systems
+                                                      John Brezak
+                                                      Microsoft
+                                                      Bill Gossman
+                                                      Cybersafe
+
+              Kerberos Set/Change Password: Version 2
+
+
+0. Status Of This Memo
+
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1]. 
+
+   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.
+
+   Comments and suggestions on this document are encouraged.  Comments 
+   on this document should be sent to the CAT working group discussion 
+   list:
+                       ietf-cat-wg@stanford.edu
+
+1. Abstract
+
+   The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 
+   does not allow for an administrator to set a password for a new user. 
+   This functionality is useful in some environments, and this proposal 
+   extends [4] to allow password setting. The changes are: adding new 
+   fields to the request message to indicate the principal which is 
+   having its password set, not requiring the initial flag in the service 
+   ticket, using a new protocol version number, and adding three new 
+   result codes. We also extend the set/change protocol to allow a 
+   client to send a sequence of keys to the KDC instead of a cleartext 
+   password. If in the cleartext password case, the cleartext password 
+   fails to satisfy password policy, the server should use the result    
+   code KRB5_KPASSWD_POLICY_REJECT.
+
+2. Conventions used in this document 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+   
+3. The Protocol
+
+   The service must accept requests on UDP port 464 and TCP port 464 as 
+   well. The protocol consists of a single request message followed by 
+   a single reply message.  For UDP transport, each message must be fully 
+   contained in a single UDP packet.
+
+   For TCP transport, there is a 4 octet header in network byte order
+   precedes the message and specifies the length of the message. This
+   requirement is consistent with the TCP transport header in 1510bis.
+
+Request Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REQ length        |         AP-REQ data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                        KRB-PRIV message                       /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order).
+
+   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REQ data: (see [3]) The AP-REQ message must be for the service 
+   principal kadmin/changepw@REALM, where REALM is the REALM of the user 
+   who wishes to change/set his password.  The ticket in the AP-REQ must 
+   must include a subkey in the Authenticator. To enable setting of 
+   passwords/keys, it is not required that the initial flag be set in the 
+   Kerberos service ticket. The initial flag is required for change requests,
+   but not for set password requests. We have the following definitions:
+
+                    old passwd   initial flag  target principal can be
+                    in request?  required?     distinct from 
+                                               authenticating principal?
+                                              
+   change password:  yes         yes           no
+
+   set password:     no          no            yes
+
+   set key:          no          policy        yes
+                                 determined
+
+   KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 
+   using the subkey from the authenticator in the AP-REQ data. 
+
+   The user-data component of the message consists of the following ASN.1 
+   structure encoded as an OCTET STRING:
+
+   ChangePasswdData :: =  SEQUENCE {
+                       newpasswdorkeys[0]   NewPasswdOrKeys,
+                       targname[1]          PrincipalName OPTIONAL,
+                         -- only present in set password: the principal
+                         -- which will have its password set
+                       targrealm[2]         Realm OPTIONAL, 
+                         -- only present in set password: the realm for 
+                         -- the principal which will have its password set
+
+                       }
+
+   NewPasswdOrKeys :: = CHOICE {
+                       passwords[0]  PasswordSequence,       
+                       keyseq[1]     KeySequences
+   }
+                         
+   KeySequences :: = SEQUENCE OF KeySequence
+
+   KeySequence :: = SEQUENCE {
+                       key[0]        EncryptionKey,
+                       salt[1]       OCTET STRING OPTIONAL,
+                       salt-type[2]  INTEGER OPTIONAL
+   }
+
+   PasswordSequence :: = SEQUENCE {
+                       newpasswd[0]  OCTET STRING,
+                       oldpasswd[1]  OCTET STRING OPTIONAL
+                         -- oldpasswd always present for change password
+                         -- but not present for set password 
+   }
+
+   The server must verify the AP-REQ message, check whether the client 
+   principal in the ticket is authorized to set or change the password 
+   (either for that principal, or for the principal in the targname 
+   field if present), and decrypt the new password/keys. The server 
+   also checks whether the initial flag is required for this request, 
+   replying with status 0x0007 if it is not set and should be. An 
+   authorization failure is cause to respond with status 0x0005. For 
+   forward compatibility, the server should be prepared to ignore fields 
+   after targrealm in the structure that it does not understand. 
+
+   The newpasswdorkeys field contains either the new cleartext password 
+   (with the old cleartext password for a change password operation), 
+   or a sequence of encryption keys with their respective salts. 
+
+   In the cleartext password case, if the old password is sent in the
+   request, the request is defined to be a change password request. If
+   the old password is not present in the request, the request is a set
+   password request. The server should apply policy checks to the old 
+   and new password after verifying that the old password is valid. 
+   The server can check validity by obtaining a key from the old 
+   password with a keytype that is present in the KDC database for the 
+   user and comparing the keys for equality. The server then generates 
+   the appropriate keytypes from the password and stores them in the KDC 
+
+   database. If all goes well, status 0x0000 is returned to the client 
+   in the reply message (see below). For a change password operation,
+   the initial flag in the service ticket MUST be set. 
+
+   In the key sequence case, the sequence of keys is sent to the set
+   password service. For a principal that can act as a server, its 
+   preferred keytype should be sent as the first key in the sequence, 
+   but the KDC is not required to honor this preference. Application 
+   servers should use the key sequence option for changing/setting their 
+   keys. The set password service should check that all keys are in the
+   proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. 
+
+Reply Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REP length        |         AP-REP data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                          KRB-PRIV message                     /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order). (The reply message has the same format as in [4]).
+
+   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
+   packet.
+   
+   KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 
+   subkey in the authenticator in the AP-REQ data.
+
+   The server will respond with a KRB-PRIV message unless it cannot
+   validate the client AP-REQ or KRB-PRIV message, in which case it will
+   respond with a KRB-ERROR message. NOTE: Unlike change password version
+   1, the KRB-ERROR message will be sent back without any encapsulation. 
+
+   The user-data component of the KRB-PRIV message, or e-data component 
+   of the KRB-ERROR message, must consist of the following data.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          result code          |        result string          /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             edata                             /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      result code (16 bits) (result codes 0-4 are from [4]):
+         The result code must have one of the following values (network
+         byte order):
+         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
+                                     allowed in a KRB-ERROR message)
+         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
+         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
+                                     processing the request (for example, 
+                                     there is a resource or other problem 
+                                     causing the request to fail)
+         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
+                                     authentication processing
+         KRB5_KPASSWD_SOFTERROR    4 request fails due to a soft error 
+                                     in processing the request 
+         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
+         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
+         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
+         KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
+         the result string should include a text message to be presented
+         to the user.
+         KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
+         (only in response to a set password request).
+         KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
+         containing at least one etype that is not supported by the KDC.
+         The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 
+         type that specifies the etypes that the KDC supports:
+         
+         KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
+                encryption-type[0]  INTEGER,
+                salt[1]             OCTET STRING OPTIONAL -- not sent
+         }
+
+         PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
+
+         The client should retry the request using only etypes (keytypes)
+         that are contained within the PKERB-ETYPE-INFO structure in the
+         previous response. 
+         0xFFFF if the request fails for some other reason.
+         The client must interpret any non-zero result code as a failure.
+      result string - from [4]:
+         This field is a UTF-8 encoded string which should be displayed
+         to the user by the client. Specific reasons for a password 
+         set/change policy failure is one use for this string. 
+      edata: used to convey additional information as defined by the 
+         result code. 
+
+4. References
+
+   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+       9, RFC 2026, October 1996. 
+    
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+       Levels", BCP 14, RFC 2119, March 1997 
+ 
+   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
+       Service (V5), Request for Comments 1510.
+
+   [4] M. Horowitz. Kerberos Change Password Protocol,
+       ftp://ds.internic.net/internet-drafts/
+       draft-ietf-cat-kerb-chg-password-02.txt
+
+5. Expiration Date
+
+   This draft expires in September 2000.
+
+6. Authors' Addresses
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+   Email: jtrostle@cisco.com
+
+   Mike Swift 
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: mikesw@microsoft.com
+
+   John Brezak
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: jbrezak@microsoft.com
+
+   Bill Gossman
+   Cybersafe Corporation
+   1605 NW Sammamish Rd.
+   Issaquah, WA 98027-5378
+   Email: bill.gossman@cybersafe.com
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
new file mode 100644
index 000000000000..0319f8bf347c
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
@@ -0,0 +1,345 @@
+
+INTERNET-DRAFT                                        Mike Swift 
+draft-ietf-cat-kerberos-set-passwd-03.txt             Microsoft
+April 2000                                            Jonathan Trostle
+                                                      Cisco Systems
+                                                      John Brezak
+                                                      Microsoft
+                                                      Bill Gossman
+                                                      Cybersafe
+
+              Kerberos Set/Change Password: Version 2
+
+
+0. Status Of This Memo
+
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1]. 
+
+   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.
+
+   Comments and suggestions on this document are encouraged.  Comments 
+   on this document should be sent to the CAT working group discussion 
+   list:
+                       ietf-cat-wg@stanford.edu
+
+1. Abstract
+
+   The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 
+   does not allow for an administrator to set a password for a new user. 
+   This functionality is useful in some environments, and this proposal 
+   extends [4] to allow password setting. The changes are: adding new 
+   fields to the request message to indicate the principal which is 
+   having its password set, not requiring the initial flag in the service 
+   ticket, using a new protocol version number, and adding three new 
+   result codes. We also extend the set/change protocol to allow a 
+   client to send a sequence of keys to the KDC instead of a cleartext 
+   password. If in the cleartext password case, the cleartext password 
+   fails to satisfy password policy, the server should use the result    
+   code KRB5_KPASSWD_POLICY_REJECT.
+
+2. Conventions used in this document 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+   
+3. The Protocol
+
+   The service must accept requests on UDP port 464 and TCP port 464 as 
+   well. The protocol consists of a single request message followed by 
+   a single reply message.  For UDP transport, each message must be fully 
+   contained in a single UDP packet.
+
+   For TCP transport, there is a 4 octet header in network byte order
+   precedes the message and specifies the length of the message. This
+   requirement is consistent with the TCP transport header in 1510bis.
+
+Request Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REQ length        |         AP-REQ data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                        KRB-PRIV message                       /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order).
+
+   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ 
+   message service ticket sname, srealm principal identifier is 
+   kadmin/changepw@REALM where REALM is the realm of the change password 
+   service. The same applies to a set password/key request except the 
+   principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ 
+   must include a subkey in the Authenticator. To enable setting of 
+   passwords/keys, it is not required that the initial flag be set in the 
+   Kerberos service ticket. The initial flag is required for change requests,
+   but not for set requests. We have the following definitions:
+
+                    old passwd   initial flag  target principal can be
+                    in request?  required?     distinct from 
+                                               authenticating principal?
+                                              
+   change password:  yes         yes           no
+
+   set password:     no          policy (*)    yes
+
+   set key:          no          policy (*)    yes
+                                 
+   change key:       no          yes           no
+
+   policy (*): implementations SHOULD allow administrators to set the
+   initial flag required for set requests policy to either yes or no.
+   Clients MUST be able to retry set requests that fail due to error 7
+   (initial flag required) with an initial ticket. Clients SHOULD NOT
+   cache service tickets targetted at kadmin/changepw.
+
+   KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 
+   using the subkey from the authenticator in the AP-REQ data. 
+
+   The user-data component of the message consists of the following ASN.1 
+   structure encoded as an OCTET STRING:
+
+   ChangePasswdData :: =  SEQUENCE {
+                       newpasswdorkeys[0]   NewPasswdOrKeys,
+                       targname[1]          PrincipalName OPTIONAL,
+                         -- only present in set password/key: the principal
+                         -- which will have its password or keys set. Not
+                         -- present in a set request if the client principal
+                         -- from the ticket is the principal having its 
+                         -- passwords or keys set.
+                       targrealm[2]         Realm OPTIONAL, 
+                         -- only present in set password/key: the realm for 
+                         -- the principal which will have its password or
+                         -- keys set. Not present in a set request if the 
+                         -- client principal from the ticket is the principal 
+                         -- having its passwords or keys set.
+                       }
+
+   NewPasswdOrKeys :: = CHOICE {
+                       passwords[0]  PasswordSequence,  -- change/set passwd   
+                       keyseq[1]     KeySequences       -- change/set key
+   }
+                         
+   KeySequences :: = SEQUENCE OF KeySequence
+
+   KeySequence :: = SEQUENCE {
+                       key[0]        EncryptionKey,
+                       salt[1]       OCTET STRING OPTIONAL,
+                       salt-type[2]  INTEGER OPTIONAL
+   }
+
+   PasswordSequence :: = SEQUENCE {
+                       newpasswd[0]  OCTET STRING,
+                       oldpasswd[1]  OCTET STRING OPTIONAL
+                         -- oldpasswd always present for change password
+                         -- but not present for set password, set key, or
+                         -- change key
+   }
+
+   The server must verify the AP-REQ message, check whether the client 
+   principal in the ticket is authorized to set or change the password 
+   (either for that principal, or for the principal in the targname 
+   field if present), and decrypt the new password/keys. The server 
+   also checks whether the initial flag is required for this request, 
+   replying with status 0x0007 if it is not set and should be. An 
+   authorization failure is cause to respond with status 0x0005. For 
+   forward compatibility, the server should be prepared to ignore fields 
+   after targrealm in the structure that it does not understand. 
+
+   The newpasswdorkeys field contains either the new cleartext password 
+   (with the old cleartext password for a change password operation), 
+   or a sequence of encryption keys with their respective salts. 
+
+   In the cleartext password case, if the old password is sent in the
+   request, the request MUST be a change password request. If the old 
+   password is not present in the request, the request MUST be a set
+   password request. The server should apply policy checks to the old 
+   and new password after verifying that the old password is valid. 
+   The server can check validity by obtaining a key from the old 
+   password with a keytype that is present in the KDC database for the 
+   user and comparing the keys for equality. The server then generates 
+   the appropriate keytypes from the password and stores them in the KDC 
+   database. If all goes well, status 0x0000 is returned to the client 
+   in the reply message (see below). For a change password operation,
+   the initial flag in the service ticket MUST be set. 
+
+   In the key sequence case, the sequence of keys is sent to the change
+   or set password service (kadmin/changepw or kadmin/setpw respectively). 
+   For a principal that can act as a server, its preferred keytype should 
+   be sent as the first key in the sequence, but the KDC is not required 
+   to honor this preference. Application servers should use the key 
+   sequence option for changing/setting their keys. The change/set password 
+   services should check that all keys are in the proper format, returning 
+   the KRB5_KPASSWD_MALFORMED error otherwise. 
+
+Reply Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REP length        |         AP-REP data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                          KRB-PRIV message                     /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order). (The reply message has the same format as in [4]).
+
+   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
+   packet.
+   
+   KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 
+   subkey in the authenticator in the AP-REQ data.
+
+   The server will respond with a KRB-PRIV message unless it cannot
+   validate the client AP-REQ or KRB-PRIV message, in which case it will
+   respond with a KRB-ERROR message. NOTE: Unlike change password version
+   1, the KRB-ERROR message will be sent back without any encapsulation. 
+
+   The user-data component of the KRB-PRIV message, or e-data component 
+   of the KRB-ERROR message, must consist of the following data.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          result code          |        result string          /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             edata                             /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      result code (16 bits) (result codes 0-4 are from [4]):
+         The result code must have one of the following values (network
+         byte order):
+         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
+                                     allowed in a KRB-ERROR message)
+         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
+         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
+                                     processing the request (for example, 
+                                     there is a resource or other problem 
+                                     causing the request to fail)
+         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
+                                     authentication processing
+         KRB5_KPASSWD_SOFTERROR    4 request fails due to a soft error 
+                                     in processing the request 
+         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
+         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
+         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
+         KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
+         the result string should include a text message to be presented
+         to the user.
+         KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
+         (only in response to a set password request).
+         KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
+         containing at least one etype that is not supported by the KDC.
+         The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 
+         type that specifies the etypes that the KDC supports:
+         
+         KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
+                encryption-type[0]  INTEGER,
+                salt[1]             OCTET STRING OPTIONAL -- not sent
+         }
+
+         PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
+
+         The client should retry the request using only etypes (keytypes)
+         that are contained within the PKERB-ETYPE-INFO structure in the
+         previous response. 
+         0xFFFF if the request fails for some other reason.
+         The client must interpret any non-zero result code as a failure.
+      result string - from [4]:
+         This field is a UTF-8 encoded string which should be displayed
+         to the user by the client. Specific reasons for a password 
+
+         set/change policy failure is one use for this string. 
+      edata: used to convey additional information as defined by the 
+         result code. 
+
+4. Acknowledgements
+  
+   The authors thank Tony Andrea for his input to the document.
+
+5. References
+
+   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+       9, RFC 2026, October 1996. 
+    
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+       Levels", BCP 14, RFC 2119, March 1997 
+ 
+   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
+       Service (V5), Request for Comments 1510.
+
+   [4] M. Horowitz. Kerberos Change Password Protocol,
+       ftp://ds.internic.net/internet-drafts/
+       draft-ietf-cat-kerb-chg-password-02.txt
+
+6. Expiration Date
+
+   This draft expires in October 2000.
+
+7. Authors' Addresses
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+   Email: jtrostle@cisco.com
+
+   Mike Swift 
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: mikesw@microsoft.com
+
+   John Brezak
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: jbrezak@microsoft.com
+
+   Bill Gossman
+   Cybersafe Corporation
+   1605 NW Sammamish Rd.
+   Issaquah, WA 98027-5378
+   Email: bill.gossman@cybersafe.com
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
new file mode 100644
index 000000000000..bd31750a15af
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                             Ken Hornstein
+<draft-ietf-cat-krb-dns-locate-02.txt>                               NRL
+March 10, 2000                                            Jeffrey Altman
+Expires: September 10, 2000                          Columbia University
+
+
+
+          Distributing Kerberos KDC and Realm Information with DNS
+
+
+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.
+
+   Distribution of this memo is unlimited.  It is filed as <draft-ietf-
+   cat-krb-dns-locate-02.txt>, and expires on September 10, 2000.  Please
+   send comments to the authors.
+
+Abstract
+
+   Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
+   col [RFC????] describe any mechanism for clients to learn critical
+   configuration information necessary for proper operation of the pro-
+   tocol.  Such information includes the location of Kerberos key dis-
+   tribution centers or a mapping between DNS domains and Kerberos
+   realms.
+
+   Current Kerberos implementations generally store such configuration
+   information in a file on each client machine.  Experience has shown
+   this method of storing configuration information presents problems
+   with out-of-date information and scaling problems, especially when
+
+
+
+Hornstein, Altman                                               [Page 1]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   using cross-realm authentication.
+
+   This memo describes a method for using the Domain Name System
+   [RFC1035] for storing such configuration information.  Specifically,
+   methods for storing KDC location and hostname/domain name to realm
+   mapping information are discussed.
+
+DNS vs. Kerberos - Case Sensitivity of Realm Names
+
+   In Kerberos, realm names are case sensitive.  While it is strongly
+   encouraged that all realm names be all upper case this recommendation
+   has not been adopted by all sites.  Some sites use all lower case
+   names and other use mixed case.  DNS on the other hand is case insen-
+   sitive for queries but is case preserving for responses to TXT
+   queries.  Since "MYREALM", "myrealm", and "MyRealm" are all different
+   it is necessary that the DNS entries be distinguishable.
+
+   Since the recommend realm names are all upper case, we will not
+   require any quoting to be applied to upper case names.  If the realm
+   name contains lower case characters each character is to be quoted by
+   a '=' character.  So "MyRealm" would be represented as "M=yR=e=a=l=m"
+   and "myrealm" as "=m=y=r=e=a=l=m".  If the realm name contains the
+   '=' character it will be represented as "==".
+
+
+Overview - KDC location information
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2052].  The format of this RR is as follows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for Kerberos is always "_kerberos".
+
+   The Proto can be either "_udp" or "_tcp".  If these records are to be
+   used, a "_udp" record MUST be included.  If the Kerberos implementa-
+   tion supports TCP transport, a "_tcp" record SHOULD be included.
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
+   meaning as defined in RFC 2052.
+
+Example - KDC location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
+   beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
+   directed to kdc1.asdf.com first as per the specified priority.
+
+
+
+Hornstein, Altman                                               [Page 2]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   Weights are not used in these records.
+
+   _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
+   _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
+
+Overview - Kerberos password changing server location information
+
+   Kerberos password changing server [KERB-CHG] location is to be stored
+   using the DNS SRV RR [RFC 2052].  The format of this RR is as fol-
+   lows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for the password server is always "_kpasswd".
+
+   The Proto MUST be "_udp".
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
+   meaning as defined in RFC 2052.
+
+Overview - Kerberos admin server location information
+
+   Kerberos admin location information is to be stored using the DNS SRV
+   RR [RFC 2052].  The format of this RR is as follows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for the admin server is always "_kerberos-adm".
+
+   The Proto can be either "_udp" or "_tcp".  If these records are to be
+   used, a "_tcp" record MUST be included.  If the Kerberos admin imple-
+   mentation supports UDP transport, a "_udp" record SHOULD be included.
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
+   meaning as defined in RFC 2052.
+
+   Note that there is no formal definition of a Kerberos admin protocol,
+   so the use of this record is optional and implementation-dependent.
+
+Example - Kerberos administrative server location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has one
+   administrative server, kdc1.asdf.com.
+
+
+
+
+Hornstein, Altman                                               [Page 3]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 88 kdc1.asdf.com.
+
+Overview - Hostname/domain name to Kerberos realm mapping
+
+   Information on the mapping of DNS hostnames and domain names to Ker-
+   beros realms is stored using DNS TXT records [RFC 1035].  These
+   records have the following format.
+
+   Service.Name TTL Class TXT Realm
+
+   The Service field is always "_kerberos", and prefixes all entries of
+   this type.
+
+   The Name is a DNS hostname or domain name.  This is explained in
+   greater detail below.
+
+   TTL, Class, and TXT have the standard DNS meaning as defined in RFC
+   1035.
+
+   The Realm is the data for the TXT RR, and consists simply of the Ker-
+   beros realm that corresponds to the Name specified.
+
+   When a Kerberos client wishes to utilize a host-specific service, it
+   will perform a DNS TXT query, using the hostname in the Name field of
+   the DNS query.  If the record is not found, the first label of the
+   name is stripped and the query is retried.
+
+   Compliant implementations MUST query the full hostname and the most
+   specific domain name (the hostname with the first label removed).
+   Compliant implementations SHOULD try stripping all subsequent labels
+   until a match is found or the Name field is empty.
+
+Example - Hostname/domain name to Kerberos realm mapping
+
+   For the previously mentioned ASDF.COM realm and domain, some sample
+   records might be as follows:
+
+   _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
+   _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
+   _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
+
+   Let us suppose that in this case, a Kerberos client wishes to use a
+   Kerberized service on the host foo.asdf.com.  It would first query:
+
+   _kerberos.foo.asdf.com. IN TXT
+
+   Finding no match, it would then query:
+
+
+
+
+Hornstein, Altman                                               [Page 4]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   _kerberos.asdf.com. IN TXT
+
+   And find an answer of ASDF.COM.  This would be the realm that
+   foo.asdf.com resides in.
+
+   If another Kerberos client wishes to use a Kerberized service on the
+   host salesserver.asdf.com, it would query:
+
+   _kerberos.salesserver.asdf.com IN TXT
+
+   And find an answer of SALES.ASDF.COM.
+
+Security considerations
+
+   As DNS is deployed today, it is an unsecure service.  Thus the infor-
+   mation returned by it cannot be trusted.
+
+   Current practice for REALM to KDC mapping is to use hostnames to
+   indicate KDC hosts (stored in some implementation-dependent location,
+   but generally a local config file).  These hostnames are vulnerable
+   to the standard set of DNS attacks (denial of service, spoofed
+   entries, etc).  The design of the Kerberos protocol limits attacks of
+   this sort to denial of service.  However, the use of SRV records does
+   not change this attack in any way.  They have the same vulnerabili-
+   ties that already exist in the common practice of using hostnames for
+   KDC locations.
+
+   Current practice for HOSTNAME to REALM mapping is to provide a local
+   configuration of mappings of hostname or domain name to realm which
+   are then mapped to KDCs.  But this again is vulnerable to spoofing
+   via CNAME records that point to hosts in other domains.  This has the
+   same effect as when a TXT record is spoofed.  In a realm with no
+   cross-realm trusts this is a DoS attack.  However, when cross-realm
+   trusts are used it is possible to redirect a client to use a comprom-
+   ised realm.
+
+   This is not an exploit of the Kerberos protocol but of the Kerberos
+   trust model.  The same can be done to any application that must
+   resolve the hostname in order to determine which domain a non-FQDN
+   belongs to.
+
+   Implementations SHOULD provide a way of specifying this information
+   locally without the use of DNS.  However, to make this feature
+   worthwhile a lack of any configuration information on a client should
+   be interpretted as permission to use DNS.
+
+
+
+
+
+
+Hornstein, Altman                                               [Page 5]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+Expiration
+
+   This Internet-Draft expires on September 10, 2000.
+
+References
+
+
+   [RFC1510]
+        The Kerberos Network Authentication System; Kohl, Newman; Sep-
+        tember 1993.
+
+   [RFC1035]
+        Domain Names - Implementation and Specification; Mockapetris;
+        November 1987
+
+   [RFC2782]
+        A DNS RR for specifying the location of services (DNS SRV); Gul-
+        brandsen, Vixie; Feburary 2000
+
+   [KERB-CHG]
+        Kerberos Change Password Protocol; Horowitz;
+        ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
+        password-02.txt
+
+Authors' Addresses
+
+   Ken Hornstein
+   US Naval Research Laboratory
+   Bldg A-49, Room 2
+   4555 Overlook Avenue
+   Washington DC  20375 USA
+
+   Phone: +1 (202) 404-4765
+   EMail: kenh@cmf.nrl.navy.mil
+
+   Jeffrey Altman
+   The Kermit Project
+   Columbia University
+   612 West 115th Street #716
+   New York NY 10025-7799 USA
+
+   Phone: +1 (212) 854-1344
+   EMail: jaltman@columbia.edu
+
+
+
+
+
+
+
+
+Hornstein, Altman                                               [Page 6]
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
new file mode 100644
index 000000000000..11e5dc9f9548
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
@@ -0,0 +1,1333 @@
+
+INTERNET-DRAFT                                                    Tom Yu
+Common Authentication Technology WG                                  MIT
+draft-ietf-cat-krb5gss-mech2-03.txt                        04 March 2000
+
+           The Kerberos Version 5 GSSAPI Mechanism, Version 2
+
+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.
+
+   Comments on this document should be sent to
+   "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication
+   Technology WG discussion list.
+
+Abstract
+
+   This document defines protocols, procedures, and conventions to be
+   employed by peers implementing the Generic Security Service
+   Application Program Interface (as specified in RFC 2743) when using
+   Kerberos Version 5 technology (as specified in RFC 1510).  This
+   obsoletes RFC 1964.
+
+Acknowledgements
+
+   Much of the material in this specification is based on work done for
+   Cygnus Solutions by Marc Horowitz.
+
+Table of Contents
+
+   Status of This Memo ............................................    1
+   Abstract .......................................................    1
+   Acknowledgements ...............................................    1
+   Table of Contents ..............................................    1
+   1.  Introduction ...............................................    3
+   2.  Token Formats ..............................................    3
+      2.1.  Packet Notation .......................................    3
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 1]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+      2.2.  Mechanism OID .........................................    4
+      2.3.  Context Establishment .................................    4
+         2.3.1.  Option Format ....................................    4
+            2.3.1.1.  Delegated Credentials Option ................    5
+            2.3.1.2.  Null Option .................................    5
+         2.3.2.  Initial Token ....................................    6
+            2.3.2.1.  Data to be Checksummed in APREQ .............    8
+         2.3.3.  Response Token ...................................   10
+      2.4.  Per-message Tokens ....................................   12
+         2.4.1.  Sequence Number Usage ............................   12
+         2.4.2.  MIC Token ........................................   12
+            2.4.2.1.  Data to be Checksummed in MIC Token .........   13
+         2.4.3.  Wrap Token .......................................   14
+            2.4.3.1.  Wrap Token With Integrity Only ..............   14
+            2.4.3.2.  Wrap Token With Integrity and Encryption
+                      .............................................   15
+               2.4.3.2.1.  Data to be Encrypted in Wrap Token .....   16
+   3.  ASN.1 Encoding of Octet Strings ............................   17
+   4.  Name Types .................................................   18
+      4.1.  Mandatory Name Forms ..................................   18
+         4.1.1.  Kerberos Principal Name Form .....................   18
+         4.1.2.  Exported Name Object Form for Kerberos5
+                 Mechanism ........................................   19
+   5.  Credentials ................................................   20
+   6.  Parameter Definitions ......................................   20
+      6.1.  Minor Status Codes ....................................   20
+         6.1.1.  Non-Kerberos-specific codes ......................   21
+         6.1.2.  Kerberos-specific-codes ..........................   21
+   7.  Kerberos Protocol Dependencies .............................   22
+   8.  Security Considerations ....................................   22
+   9.  References .................................................   22
+   10.  Author's Address ..........................................   23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 2]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+1.  Introduction
+
+   The original Kerberos 5 GSSAPI mechanism[RFC1964] has a number of
+   shortcomings.  This document attempts to remedy them by defining a
+   completely new Kerberos 5 GSSAPI mechanism.
+
+   The context establishment token format requires that the
+   authenticator of AP-REQ messages contain a cleartext data structure
+   in its checksum field, which is a needless and potentially confusing
+   overloading of that field.  This is implemented by a special checksum
+   algorithm whose purpose is to copy the input data directly into the
+   checksum field of the authenticator.
+
+   The number assignments for checksum algorithms and for encryption
+   types are inconsistent between the Kerberos protocol and the original
+   GSSAPI mechanism.  If new encryption or checksum algorithms are added
+   to the Kerberos protocol at some point, the GSSAPI mechanism will
+   need to be separately updated to use these new algorithms.
+
+   The original mechanism specifies a crude method of key derivation (by
+   using the XOR of the context key with a fixed constant), which is
+   incompatible with newer cryptosystems which specify key derivation
+   procedures themselves.  The original mechanism also assumes that both
+   checksums and cryptosystem blocksizes are eight bytes.
+
+   Defining all GSSAPI tokens for the new Kerberos 5 mechanism in terms
+   of the Kerberos protocol specification ensures that new encryption
+   types and checksum types may be automatically used as they are
+   defined for the Kerberos protocol.
+
+2.  Token Formats
+
+   All tokens, not just the initial token, are framed as the
+   InitialContextToken described in RFC 2743 section 3.1.  The
+   innerContextToken element of the token will not itself be encoded in
+   ASN.1, with the exception of caller-provided application data.
+
+   One rationale for avoiding the use of ASN.1 in the inner token is
+   that some implementors may wish to implement this mechanism in a
+   kernel or other similarly constrained application where handling of
+   full ASN.1 encoding may be cumbersome.  Also, due to the poor
+   availability of the relevant standards documents, ASN.1 encoders and
+   decoders are difficult to implement completely correctly, so keeping
+   ASN.1 usage to a minimum decreases the probability of bugs in the
+   implementation of the mechanism.  In particular, bit strings need to
+   be transferred at certain points in this mechanism.  There are many
+   conflicting common misunderstandings of how to encode and decode
+   ASN.1 bit strings, which have led difficulties in the implementaion
+   of the Kerberos protocol.
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 3]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.1.  Packet Notation
+
+   The order of transmission of this protocol is described at the octet
+   level.  Packet diagrams depict bits in the order of transmission,
+   assuming that individual octets are transmitted with the most
+   significant bit (MSB) first.  The diagrams read from left to right
+   and from top to bottom, as in printed English.  In each octet, bit
+   number 7 is the MSB and bit number 0 is the LSB.
+
+   Numbers prefixed by the characters "0x" are in hexadecimal notation,
+   as in the C programming language.  Even though packet diagrams are
+   drawn 16 bits wide, no padding should be used to align the ends of
+   variable-length fields to a 32-bit or 16-bit boundary.
+
+   All integer fields are in network byte order.  All other fields have
+   the size shown in the diagrams, with the exception of variable length
+   fields.
+
+2.2.  Mechanism OID
+
+   The Object Identifier (OID) of the new krb5 v2 mechanism is:
+
+   {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2)
+   krb5v2(3)}
+
+
+2.3.  Context Establishment
+
+2.3.1.  Option Format
+
+   Context establishment tokens, i.e., the initial ones that the
+   GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit
+   while a security context is being set up, may contain options that
+   influence the subsequent behavior of the context.  This document
+   describes only a small set of options, but additional types may be
+   added by documents intended to supplement this one.  The generic
+   format is as follows:
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                          option type                          |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                  option length (32 bits)                  --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                 option data (variable length)                 /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 4]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   option type (16 bits)
+        The type identifier of the following option.
+
+   option length (32 bits)
+        The length in bytes of the following option.
+
+   option data (variable length)
+        The actual option data.
+
+   Any number of options may appear in an initator or acceptor token.
+   The final option in a token must be the null option, in order to mark
+   the end of the list.  Option type 0xffff is reserved.
+
+   The initiator and acceptor shall ignore any options that they do not
+   understand.
+
+2.3.1.1.  Delegated Credentials Option
+
+   Only the initiator may use this option.  The format of the delegated
+   credentials option is as follows:
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                     option type = 0x00001                     |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                      KRB-CRED length                      --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                        KRB-CRED message                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   option type (16 bits)
+        The option type for this option shall be 0x0001.
+
+   KRB-CRED length (32 bits)
+        The length in bytes of the following KRB-CRED message.
+
+   KRB-CRED message (variable length)
+        The option data for this option shall be the KRB-CRED message
+        that contains the credentials being delegated (forwarded) to the
+        context acceptor.  Only the initiator may use this option.
+
+2.3.1.2.  Null Option
+
+   The Null option terminates the option list, and must be used by both
+   the initiator and the acceptor.  Its format is as follows:
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 5]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                        option type = 0                        |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                         length = 0                        --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+
+
+   option type (16 bits)
+        The option type of this option must be zero.
+
+   option length (32 bits)
+        The length of this option must be zero.
+
+2.3.2.  Initial Token
+
+   This is the initial token sent by the context initiator, generated by
+   GSS_Init_sec_context().
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                   initial token id = 0x0101                   |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--         reserved flag bits          +-----------------------+
+  4  |                                       | I | C | S | R | M | D |
+     +-------------------------------+-------------------------------+
+  6  |                      checksum type count                      |
+     +-------------------------------+-------------------------------+
+  8  |                               .                               |
+     /                       checksum type list                      /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                               .                               |
+     /                            options                            /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  m  |                                                               |
+     +--                       AP-REQ length                       --+
+ m+2 |                                                               |
+     +-------------------------------+-------------------------------+
+ m+4 |                               .                               |
+     /                          AP-REQ data                          /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   initial token ID (16 bits)
+        Contains the integer 0x0101, which identifies this as the
+        initial token in the context setup.
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 6]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   reserved flag bits (26 bits)
+        These bits are reserved for future expansion.  They must be set
+        to zero by the initiator and be ignored by the acceptor.
+
+   I flag (1 bit)
+        0x00000020 -- GSS_C_INTEG_FLAG
+
+   C flag (1 bit)
+        0x00000010 -- GSS_C_CONF_FLAG
+
+   S flag (1 bit)
+        0x00000008 -- GSS_C_SEQUENCE_FLAG
+
+   R flag (1 bit)
+        0x00000004 -- GSS_C_REPLAY_FLAG
+
+   M flag (1 bit)
+        0x00000002 -- GSS_C_MUTUAL_FLAG
+
+   D flag (1 bit)
+        0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the
+        "delegated credentials" option is included.
+
+   checksum type count (16 bits)
+        The number of checksum types supported by the initiator.
+
+   checksum type list (variable length)
+        A list of Kerberos checksum types, as defined in RFC 1510
+        section 6.4. These checksum types must be collision-proof and
+        keyed with the context key; no checksum types that are
+        incompatible with the encryption key shall be used.  Each
+        checksum type number shall be 32 bits wide.  This list should
+        contain all the checksum types supported by the initiator.  If
+        mutual authentication is not used, then this list shall contain
+        only one checksum type.
+
+   options (variable length)
+        The context initiation options, described in section 2.3.1.
+
+   AP-REQ length (32 bits)
+        The length of the following KRB_AP_REQ message.
+
+   AP-REQ data (variable length)
+        The AP-REQ message as described in RFC 1510.  The checksum in
+        the authenticator will be computed over the items listed in the
+        next section.
+
+   The optional sequence number field shall be used in the AP-REQ.  The
+   initiator should generate a subkey in the authenticator, and the
+   acceptor should generate a subkey in the AP-REP.  The key used for
+   the per-message tokens will be the AP-REP subkey, or if that is not
+   present, the authenticator subkey, or if that is not present, the
+   session key.  When subkeys are generated, it is strongly recommended
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 7]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   that they be of the same type as the associated session key.
+
+   XXX The above is not secure.  There should be an algorithmic process
+   to arrive at a subsession key which both sides of the authentication
+   exchange can perform based on the ticket sessions key and data known
+   to both parties, and this should probably be part of the revised
+   Kerberos protocol rather than bound to the GSSAPI mechanism.
+
+2.3.2.1.  Data to be Checksummed in AP-REQ
+
+   The checksum in the AP-REQ message is calculated over the following
+   items.  Like in the actual tokens, no padding should be added to
+   force integer fields to align on 32 bit boundaries.  This particular
+   set of data should not be sent as a part of any token; it merely
+   specifies what is to be checksummed in the AP-REQ.  The items in this
+   encoding that precede the initial token ID correspond to the channel
+   bindings passed to GSS_Init_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 8]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                                                               |
+     +--                   initiator address type                  --+
+  2  |                                                               |
+     +-------------------------------+-------------------------------+
+  4  |                    initiator address length                   |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                       initiator address                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                                                               |
+     +--                   acceptor address type                   --+
+     |                                                               |
+     +-------------------------------+-------------------------------+
+ n+4 |                    acceptor address length                    |
+     +-------------------------------+-------------------------------+
+ n+6 |                               .                               |
+     /                        acceptor address                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  m  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  k  |                   initial token id = 0x0101                   |
+     +-------------------------------+-------------------------------+
+ k+2 |                                                               |
+     +--                           flags                           --+
+ k+4 |                                                               |
+     +-------------------------------+-------------------------------+
+ k+6 |                      checksum type count                      |
+     +-------------------------------+-------------------------------+
+ k+8 |                               .                               |
+     /                       checksum type list                      /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  j  |                               .                               |
+     /                            options                            /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   initiator address type (32 bits)
+        The initiator address type, as defined in the Kerberos protocol
+        specification.  If no initiator address is provided, this must
+        be zero.
+
+   initiator address length (16 bits)
+        The length in bytes of the following initiator address.  If
+        there is no inititator address provided, this must be zero.
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 9]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   initiator address (variable length)
+        The actual initiator address, in network byte order.
+
+   acceptor address type (32 bits)
+        The acceptor address type, as defined in the Kerberos protocol
+        specification.  If no acceptor address is provided, this must be
+        zero.
+
+   acceptor address length (16 bits)
+        The length in bytes of the following acceptor address.  This
+        must be zero is there is no acceptor address provided.
+
+   initiator address (variable length)
+        The actual acceptor address, in network byte order.
+
+   applicatation data (variable length)
+        The application data, if provided, encoded as a ASN.1 octet
+        string using DER.  If no application data are passed as input
+        channel bindings, this shall be a zero-length ASN.1 octet
+        string.
+
+   initial token ID (16 bits)
+        The initial token ID from the initial token.
+
+   flags (32 bits)
+        The context establishment flags from the initial token.
+
+   checksum type count (16 bits)
+        The number of checksum types supported by the initiator.
+
+   checksum type list (variable length)
+        The same list of checksum types contained in the initial token.
+
+   options (variable length)
+        The options list from the initial token.
+
+2.3.3.  Response Token
+
+   This is the reponse token sent by the context acceptor, if mutual
+   authentication is enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 10]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                   response token id = 0x0202                  |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                  reserved flag bits                 +-------+
+  4  |                                                       | D | E |
+     +-------------------------------+-------------------------------+
+  6  |                                                               |
+     +--                       checksum type                       --+
+  8  |                                                               |
+     +-------------------------------+-------------------------------+
+ 10  |                               .                               |
+     /                            options                            /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                                                               |
+     +--                 AP-REP or KRB-ERROR length                --+
+ n+2 |                                                               |
+     +-------------------------------+-------------------------------+
+ n+4 |                               .                               |
+     /                    AP-REP or KRB-ERROR data                   /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  m  |                               .                               |
+     /                            MIC data                           /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   response token id (16 bits)
+        Contains the integer 0x0202, which identifies this as the
+        response token in the context setup.
+
+   reserved flag bits (30 bits)
+        These bits are reserved for future expansion.  They must be set
+        to zero by the acceptor and be ignored by the initiator.
+
+   D flag -- delegated creds accepted (1 bit)
+        0x00000002 -- If this flag is set, the acceptor processed the
+        delegated credentials, and GSS_C_DELEG_FLAG should be returned
+        to the caller.
+
+   E flag -- error (1 bit)
+        0x00000001 -- If this flag is set, a KRB-ERROR message shall be
+        present, rather than an AP-REP message.  If this flag is not
+        set, an AP-REP message shall be present.
+
+   checksum type count (16 bits)
+        The number of checksum types supported by both the initiator and
+        the acceptor.
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 11]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   checksum type (32 bits)
+        A Kerberos checksum type, as defined in RFC 1510 section 6.4.
+        This checksum type must be among the types listed by the
+        initiator, and will be used in for subsequent checksums
+        generated during this security context.
+
+   options (variable length)
+        The option list, as described earlier.  At this time, no options
+        are defined for the acceptor, but an implementation might make
+        use of these options to acknowledge an option from the initial
+        token.  After all the options are specified, a null option must
+        be used to terminate the list.
+
+   AP-REP or KRB-ERROR length (32 bits)
+        Depending on the value of the error flag, length in bytes of the
+        AP-REP or KRB-ERROR message.
+
+   AP-REP or KRB-ERROR data (variable length)
+        Depending on the value of the error flag, the AP-REP or
+        KRB-ERROR message as described in RFC 1510.  If this field
+        contains an AP-REP message, the sequence number field in the
+        AP-REP shall be filled.  If this is a KRB-ERROR message, no
+        further fields will be in this message.
+
+   MIC data (variable length)
+        A MIC token, as described in section 2.4.2, computed over the
+        concatentation of the response token ID, flags, checksum length
+        and type fields, and all option fields.  This field and the
+        preceding length field must not be present if the error flag is
+        set.
+
+2.4.  Per-message Tokens
+
+2.4.1.  Sequence Number Usage
+
+   Sequence numbers for per-message tokens are 31 bit unsigned integers,
+   which are incremented by 1 after each token.  An overflow condition
+   should result in a wraparound of the sequence number to zero.  The
+   initiator and acceptor each keep their own sequence numbers per
+   connection.
+
+   The intial sequence number for tokens sent from the initiator to the
+   acceptor shall be the least significant 31 bits of sequence number in
+   the AP-REQ message.  The initial sequence number for tokens sent from
+   the acceptor to the initiator shall be the least significant 31 bits
+   of the sequence number in the AP-REP message if mutual authentication
+   is used; if mutual authentication is not used, the initial sequence
+   number from acceptor to initiator shall be the least significant 31
+   bits of the sequence number in the AP-REQ message.
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 12]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.4.2.  MIC Token
+
+   Use of the GSS_GetMIC() call yields a token, separate from the user
+   data being protected, which can be used to verify the integrity of
+   that data when it is received.  The MIC token has the following
+   format:
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                     MIC token id = 0x0303                     |
+     +-------------------------------+-------------------------------+
+  2  | D |                                                           |
+     +---+                     sequence number                     --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                        checksum length                        |
+     +-------------------------------+-------------------------------+
+  8  |                               .                               |
+     /                         checksum data                         /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   MIC token id (16 bits)
+        Contains the integer 0x0303, which identifies this as a MIC
+        token.
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   checksum length (16 bits)
+        The number of bytes in the following checksum data field.
+
+   checksum data (variable length)
+        The checksum itself, as defined in RFC 1510 section 6.4.  The
+        checksum is calculated over the encoding described in the
+        following section.  The key usage GSS_TOK_MIC -- 22 [XXX need to
+        register this] shall be used in cryptosystems that support key
+        derivation.
+
+   The mechanism implementation shall only use the checksum type
+   returned by the acceptor in the case of mutual authentication.  If
+   mutual authentication is not requested, then only the checksum type
+   in the initiator token shall be used.
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 13]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.4.2.1.  Data to be Checksummed in MIC Token
+
+   The checksum in the MIC token shall be calculated over the following
+   elements.  This set of data is not actually included in the token as
+   is; the description only appears for the purpose of specifying the
+   method of calculating the checksum.
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                     MIC token id = 0x0303                     |
+     +-------------------------------+-------------------------------+
+  2  | D |                                                           |
+     +---+                     sequence number                     --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   MIC token ID (16 bits)
+        The MIC token ID from the MIC message.
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   application data (variable length)
+        The application-supplied data, encoded as an ASN.1 octet string
+        using DER.
+
+2.4.3.  Wrap Token
+
+   Use of the GSS_Wrap() call yields a token which encapsulates the
+   input user data (optionally encrypted) along with associated
+   integrity check quantities.
+
+2.4.3.1.  Wrap Token With Integrity Only
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 14]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                integrity wrap token id = 0x0404               |
+     +-------------------------------+-------------------------------+
+  2  | D |                                                           |
+     +---+                     sequence number                     --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                        checksum length                        |
+     +-------------------------------+-------------------------------+
+ n+2 |                               .                               |
+     /                         checksum data                         /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   integrity wrap token id (16 bits)
+        Contains the integer 0x0404, which identifies this as a Wrap
+        token with integrity only.
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   application data (variable length)
+        The application-supplied data, encoded as an ASN.1 octet string
+        using DER.
+
+   checksum length (16 bits)
+        The number of bytes in the following checksum data field.
+
+   checksum data (variable length)
+        The checksum itself, as defined in RFC 1510 section 6.4,
+        computed over the concatenation of the token ID, sequence
+        number, direction field, application data length, and
+        application data, as in the MIC token checksum in the previous
+        section.  The key usage GSS_TOK_WRAP_INTEG -- 23 [XXX need to
+        register this] shall be used in cryptosystems that support key
+        derivation.
+
+   The mechanism implementation should only use checksum types which it
+   knows to be valid for both peers, as described for MIC tokens.
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 15]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.4.3.2.  Wrap Token With Integrity and Encryption
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+     |                encrypted wrap token id = 0x0505               |
+     +-------------------------------+-------------------------------+
+  2  |                               .                               |
+     /                         encrypted data                        /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   encrypted wrap token id (16 bits)
+        Contains the integer 0x0505, which identifies this as a Wrap
+        token with integrity and encryption.
+
+   encrypted data (variable length)
+        The encrypted data itself, as defined in RFC 1510 section 6.3,
+        encoded as an ASN.1 octet string using DER.  Note that this is
+        not the ASN.1 type EncryptedData as defined in RFC 1510
+        section 6.1, but rather the ciphertext without encryption type
+        or kvno information.  The encryption is performed using the
+        key/enctype exchanged during context setup.  The confounder and
+        checksum are as specified in the Kerberos protocol
+        specification.  The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need
+        to register this] shall be used in cryptosystems that support
+        key derivation.  The actual data to be encrypted are specified
+        below.
+
+2.4.3.2.1.  Data to be Encrypted in Wrap Token
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  | D |                                                           |
+     +---+                     sequence number                     --+
+  2  |                                                               |
+     +-------------------------------+-------------------------------+
+  4  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   application data (variable length)
+        The application-supplied data, encoded as an ASN.1 octet string
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 16]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+        using DER.
+
+3.  ASN.1 Encoding of Octet Strings
+
+   In order to encode arbitirarly-sized application data, ASN.1 octet
+   string encoding is in this protocol.  The Distinguished Encoding
+   Rules (DER) shall always be used in such cases.  For reference
+   purposes, the DER encoding of an ASN.1 octet string, adapted from
+   ITU-T X.690, follows:
+
+   +--------+-------//-------+-------//-------+
+   |00000100| length octets  |contents octets |
+   +--------+-------//-------+-------//-------+
+    |
+    +-- identifier octet = 0x04 = [UNIVERSAL 4]
+
+
+   In this section only, the bits in each octet shall be numbered as in
+   the ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the
+   octet, and with bit 1 being the LSB of the octet.
+
+   identifier octet (8 bits)
+        Contains the constant 0x04, the tag for primitive encoding of an
+        octet string with the default (UNIVERSAL 4) tag.
+
+   length octets (variable length)
+        Contains the length of the contents octets, in definite form
+        (since this encoding uses DER).
+
+   contents octets (variable length)
+        The contents of the octet string.
+
+   The length octets shall consist of either a short form (one byte
+   only), which is to be used only if the number of octets in the
+   contents octets is less than or equal to 127, or a long form, which
+   is to be used in all other cases.  The short form shall consist of a
+   single octet with bit 8 (the MSB) equal to zero, and the remaining
+   bits encoding the number of contents octets (which may be zero) as an
+   unsigned binary integer.
+
+   The long form shall consist of an initial octet and one or more
+   subsequent octets.  The first octet shall have bit 8 (the MSB) set to
+   one, and the remaining bits shall encode the number of subsequent
+   octets in the length encoding as an unsigned binary integer.  The
+   length must be encoded in the minimum number of octets.  An initial
+   octet of 0xFF is reserved by the ASN.1 specification.  Bits 8 to 1 of
+   the first subsequent octet, followed by bits 8 to 1 of each
+   subsequent octet in order, shall be the encoding of an unsigned
+   binary integer, with bit 8 of the first octet being the most
+   significant bit.  Thus, the length encoding within is in network byte
+   order.
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 17]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   An initial length octet of 0x80 shall not be used, as that is
+   reserved by the ASN.1 specification for indefinite lengths in
+   conjunction with constructed contents encodings, which are not to be
+   used with DER.
+
+4.  Name Types
+
+   This section discusses the name types which may be passed as input to
+   the Kerberos 5 GSSAPI mechanism's GSS_Import_name() call, and their
+   associated identifier values.  It defines interface elements in
+   support of portability, and assumes use of C language bindings per
+   RFC 2744.  In addition to specifying OID values for name type
+   identifiers, symbolic names are included and recommended to GSSAPI
+   implementors in the interests of convenience to callers.  It is
+   understood that not all implementations of the Kerberos 5 GSSAPI
+   mechanism need support all name types in this list, and that
+   additional name forms will likely be added to this list over time.
+   Further, the definitions of some or all name types may later migrate
+   to other, mechanism-independent, specifications.  The occurrence of a
+   name type in this specification is specifically not intended to
+   suggest that the type may be supported only by an implementation of
+   the Kerberos 5 mechanism.  In particular, the occurrence of the
+   string "_KRB5_" in the symbolic name strings constitutes a means to
+   unambiguously register the name strings, avoiding collision with
+   other documents; it is not meant to limit the name types' usage or
+   applicability.
+
+   For purposes of clarification to GSSAPI implementors, this section's
+   discussion of some name forms describes means through which those
+   forms can be supported with existing Kerberos technology.  These
+   discussions are not intended to preclude alternative implementation
+   strategies for support of the name forms within Kerberos mechanisms
+   or mechanisms based on other technologies.  To enhance application
+   portability, implementors of mechanisms are encouraged to support
+   name forms as defined in this section, even if their mechanisms are
+   independent of Kerberos 5.
+
+4.1.  Mandatory Name Forms
+
+   This section discusses name forms which are to be supported by all
+   conformant implementations of the Kerberos 5 GSSAPI mechanism.
+
+4.1.1.  Kerberos Principal Name Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) us(840) mit(113554) infosys(1) gssapi(2) krb5(2)
+   krb5_name(1)}.  The recommended symbolic name for this type is
+   "GSS_KRB5_NT_PRINCIPAL_NAME".
+
+   This name type corresponds to the single-string representation of a
+   Kerberos name.  (Within the MIT Kerberos 5 implementation, such names
+   are parseable with the krb5_parse_name() function.)  The elements
+   included within this name representation are as follows, proceeding
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 18]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   from the beginning of the string:
+
+        (1) One or more principal name components; if more than one
+        principal name component is included, the components are
+        separated by '/'.  Arbitrary octets may be included within
+        principal name components, with the following constraints and
+        special considerations:
+
+           (1a) Any occurrence of the characters '@' or '/' within a
+           name component must be immediately preceded by the '\'
+           quoting character, to prevent interpretation as a component
+           or realm separator.
+
+           (1b) The ASCII newline, tab, backspace, and null characters
+           may occur directly within the component or may be
+           represented, respectively, by '\n', '\t', '\b', or '\0'.
+
+           (1c) If the '\' quoting character occurs outside the contexts
+           described in (1a) and (1b) above, the following character is
+           interpreted literally.  As a special case, this allows the
+           doubled representation '\\' to represent a single occurrence
+           of the quoting character.
+
+           (1d) An occurrence of the '\' quoting character as the last
+           character of a component is illegal.
+
+        (2) Optionally, a '@' character, signifying that a realm name
+        immediately follows. If no realm name element is included, the
+        local realm name is assumed.  The '/' , ':', and null characters
+        may not occur within a realm name; the '@', newline, tab, and
+        backspace characters may be included using the quoting
+        conventions described in (1a), (1b), and (1c) above.
+
+4.1.2.  Exported Name Object Form for Kerberos 5 Mechanism
+
+   When generated by the Kerberos 5 mechanism, the Mechanism OID within
+   the exportable name shall be that of the original Kerberos 5
+   mechanism[RFC1964].  The Mechanism OID for the original Kerberos 5
+   mechanism is:
+
+   {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2)
+   krb5(2)}
+
+   The name component within the exportable name shall be a contiguous
+   string with structure as defined for the Kerberos Principal Name
+   Form.
+
+   In order to achieve a distinguished encoding for comparison purposes,
+   the following additional constraints are imposed on the export
+   operation:
+
+        (1) all occurrences of the characters '@', '/', and '\' within
+        principal components or realm names shall be quoted with an
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 19]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+        immediately-preceding '\'.
+
+        (2) all occurrences of the null, backspace, tab, or newline
+        characters within principal components or realm names will be
+        represented, respectively, with '\0', '\b', '\t', or '\n'.
+
+        (3) the '\' quoting character shall not be emitted within an
+        exported name except to accomodate cases (1) and (2).
+
+5.  Credentials
+
+   The Kerberos 5 protocol uses different credentials (in the GSSAPI
+   sense) for initiating and accepting security contexts.  Normal
+   clients receive a ticket-granting ticket (TGT) and an associated
+   session key at "login" time; the pair of a TGT and its corresponding
+   session key forms a credential which is suitable for initiating
+   security contexts.  A ticket-granting ticket, its session key, and
+   any other (ticket, key) pairs obtained through use of the
+   ticket-granting-ticket, are typically stored in a Kerberos 5
+   credentials cache, sometimes known as a ticket file.
+
+   The encryption key used by the Kerberos server to seal tickets for a
+   particular application service forms the credentials suitable for
+   accepting security contexts.  These service keys are typically stored
+   in a Kerberos 5 key table (keytab), or srvtab file (the Kerberos 4
+   terminology).  In addition to their use as accepting credentials,
+   these service keys may also be used to obtain initiating credentials
+   for their service principal.
+
+   The Kerberos 5 mechanism's credential handle may contain references
+   to either or both types of credentials.  It is a local matter how the
+   Kerberos 5 mechanism implementation finds the appropriate Kerberos 5
+   credentials cache or key table.
+
+   However, when the Kerberos 5 mechanism attempts to obtain initiating
+   credentials for a service principal which are not available in a
+   credentials cache, and the key for that service principal is
+   available in a Kerberos 5 key table, the mechanism should use the
+   service key to obtain initiating credentials for that service.  This
+   should be accomplished by requesting a ticket-granting-ticket from
+   the Kerberos Key Distribution Center (KDC), and decrypting the KDC's
+   reply using the service key.
+
+6.  Parameter Definitions
+
+   This section defines parameter values used by the Kerberos V5 GSSAPI
+   mechanism.  It defines interface elements in support of portability,
+   and assumes use of C language bindings per RFC 2744.
+
+6.1.  Minor Status Codes
+
+   This section recommends common symbolic names for minor_status values
+   to be returned by the Kerberos 5 GSSAPI mechanism.  Use of these
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 20]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   definitions will enable independent implementors to enhance
+   application portability across different implementations of the
+   mechanism defined in this specification.  (In all cases,
+   implementations of GSS_Display_status() will enable callers to
+   convert minor_status indicators to text representations.)  Each
+   implementation should make available, through include files or other
+   means, a facility to translate these symbolic names into the concrete
+   values which a particular GSSAPI implementation uses to represent the
+   minor_status values specified in this section.
+
+   It is recognized that this list may grow over time, and that the need
+   for additional minor_status codes specific to particular
+   implementations may arise.  It is recommended, however, that
+   implementations should return a minor_status value as defined on a
+   mechanism-wide basis within this section when that code is accurately
+   representative of reportable status rather than using a separate,
+   implementation-defined code.
+
+6.1.1.  Non-Kerberos-specific codes
+
+   These symbols should likely be incorporated into the generic GSSAPI
+   C-bindings document, since they really are more general.
+
+GSS_KRB5_S_G_BAD_SERVICE_NAME
+        /* "No @ in SERVICE-NAME name string" */
+GSS_KRB5_S_G_BAD_STRING_UID
+        /* "STRING-UID-NAME contains nondigits" */
+GSS_KRB5_S_G_NOUSER
+        /* "UID does not resolve to username" */
+GSS_KRB5_S_G_VALIDATE_FAILED
+        /* "Validation error" */
+GSS_KRB5_S_G_BUFFER_ALLOC
+        /* "Couldn't allocate gss_buffer_t data" */
+GSS_KRB5_S_G_BAD_MSG_CTX
+        /* "Message context invalid" */
+GSS_KRB5_S_G_WRONG_SIZE
+        /* "Buffer is the wrong size" */
+GSS_KRB5_S_G_BAD_USAGE
+        /* "Credential usage type is unknown" */
+GSS_KRB5_S_G_UNKNOWN_QOP
+        /* "Unknown quality of protection specified" */
+
+
+6.1.2.  Kerberos-specific-codes
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 21]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+GSS_KRB5_S_KG_CCACHE_NOMATCH
+        /* "Principal in credential cache does not match desired name" */
+GSS_KRB5_S_KG_KEYTAB_NOMATCH
+        /* "No principal in keytab matches desired name" */
+GSS_KRB5_S_KG_TGT_MISSING
+        /* "Credential cache has no TGT" */
+GSS_KRB5_S_KG_NO_SUBKEY
+        /* "Authenticator has no subkey" */
+GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
+        /* "Context is already fully established" */
+GSS_KRB5_S_KG_BAD_SIGN_TYPE
+        /* "Unknown signature type in token" */
+GSS_KRB5_S_KG_BAD_LENGTH
+        /* "Invalid field length in token" */
+GSS_KRB5_S_KG_CTX_INCOMPLETE
+        /* "Attempt to use incomplete security context" */
+
+
+7.  Kerberos Protocol Dependencies
+
+   This protocol makes several assumptions about the Kerberos protocol,
+   which may require changes to the successor of RFC 1510.
+
+   Sequence numbers, checksum types, and address types are assumed to be
+   no wider than 32 bits.  The Kerberos protocol specification might
+   need to be modified to accomodate this.  This obviously requires some
+   further discussion.
+
+   Key usages need to be registered within the Kerberos protocol for use
+   with GSSAPI per-message tokens.  The current specification of the
+   Kerberos protocol does not include descriptions of key derivations or
+   key usages, but planned revisions to the protocol will include them.
+
+   This protocol also makes the assumption that any cryptosystem used
+   with the session key will include integrity protection, i.e., it
+   assumes that no "raw" cryptosystems will be used.
+
+8.  Security Considerations
+
+   The GSSAPI is a security protocol; therefore, security considerations
+   are discussed throughout this document.  The original Kerberos 5
+   GSSAPI mechanism's constraints on possible cryptosystems and checksum
+   types do not permit it to be readily extended to accomodate more
+   secure cryptographic technologies with larger checksums or encryption
+   block sizes.  Sites are strongly encouraged to adopt the mechanism
+   specified in this document in the light of recent publicity about the
+   deficiencies of DES.
+
+9.  References
+
+   [X.680] ISO/IEC, "Information technology -- Abstract Syntax Notation
+   One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) |
+   ISO/IEC 8824-1:1998
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 22]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   [X.690] ISO/IEC, "Information technology -- ASN.1 encoding rules:
+   Specification of Basic Encoding Rules (BER), Canonical Encoding Rules
+   (CER) and Distinguished Encoding Rules (DER)", ITU-T X.690 (1997) |
+   ISO/IEC 8825-1:1998.
+
+   [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication
+   Service (V5)", RFC 1510.
+
+   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+   RFC 1964.
+
+   [RFC2743] Linn, J., "Generic Security Service Application Program
+   Interface, Version 2, Update 1", RFC 2743.
+
+   [RFC2744] Wray, J., "Generic Security Service API Version 2:
+   C-bindings", RFC 2744.
+
+10.  Author's Address
+
+   Tom Yu
+   Massachusetts Institute of Technology
+   Room E40-345
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   USA
+
+   email: tlyu@mit.edu
+   phone: +1 617 253 1753
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 23]
+
diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt
new file mode 100644
index 000000000000..24325fdbda74
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt
@@ -0,0 +1,281 @@
+CAT Working Group                                           K. Raeburn
+Internet-draft                                                     MIT
+Category:                                                July 14, 2000
+Updates: RFC 1964
+Document: draft-raeburn-cat-gssapi-krb5-3des-00.txt
+
+        Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
+
+Status of this Memo
+ 
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [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. 
+    
+1. Abstract 
+
+   The MIT Kerberos 5 release version 1.2 includes support for
+   triple-DES with key derivation [KrbRev].  Recent work by the EFF
+   [EFF] has demonstrated the vulnerability of single-DES mechanisms
+   to brute-force attacks by sufficiently motivated and well-funded
+   parties.
+
+   The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5]
+   specifically enumerates encryption and checksum types,
+   independently of how such schemes may be used in Kerberos.  In the
+   long run, a new Kerberos-based mechanism, which does not require
+   separately enumerating for the GSSAPI mechanism each of the
+   encryption types defined by Kerberos, appears to be a better
+   approach.  Efforts to produce such a specification are under way.
+
+   In the interest of providing increased security in the interim,
+   however, MIT is proposing adding support for triple-DES to the
+   existing mechanism, as described here.
+
+2. Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC 2119.
+
+3. New Algorithm Identifiers
+
+   One new sealing algorithm is defined, for use in WRAP tokens:
+
+   02 00 - DES3-KD
+
+   This algorithm uses triple-DES with key derivation, with a usage
+   value KG_USAGE_SEAL.  Padding is still to 8-byte multiples, and the
+   IV for encrypting application data is zero.
+
+   One new signing algorithm is defined, for use in MIC, Wrap, and
+   Delete tokens:
+
+   04 00 - HMAC SHA1 DES3-KD
+
+   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
+   with usage KG_USAGE_SIGN, as (ought to be described) in [KrbRev].
+
+   [XXX: The current [KrbRev] description refers to expired I-Ds from
+   Marc Horowitz.  The text in [KrbRev] may be inadequate to produce
+   an interoperable implementation.]
+
+   The checksum size for this algorithm is 20 octets.  See section 5.3
+   below for the use of checksum lengths of other than eight bytes.
+
+4. Key Derivation
+
+   For purposes of key derivation, we add three new usage values to the
+   list defined in [KrbRev]; one for signing messages, one for
+   sealing messages, and one for encrypting sequence numbers:
+
+   #define KG_USAGE_SEAL 22
+   #define KG_USAGE_SIGN 23
+   #define KG_USAGE_SEQ  24
+
+5. Adjustments to Previous Definitions
+
+5.1. Quality of Protection
+
+   The GSSAPI specification [GSSAPI] says that a zero QOP value
+   indicates the "default".  The original specification for the
+   Kerberos 5 mechanism says that a zero QOP value (or a QOP value
+   with the appropriate bits clear) means DES encryption.
+
+   Rather than continue to force the use of plain DES when the
+   application doesn't use mechanism-specific QOP values, the better
+   choice appears to be to redefine the DES QOP value as some non-zero
+   value, and define a triple-DES value as well.  Then a zero value
+   continues to imply the default, which would be triple-DES
+   protection when given a triple-DES session key.
+
+   Our values are:
+
+   GSS_KRB5_INTEG_C_QOP_HMAC_SHA1        0x0004
+            /* SHA-1 checksum encrypted with key derivation */
+
+   GSS_KRB5_CONF_C_QOP_DES               0x0100
+            /* plain DES encryption */
+   GSS_KRB5_CONF_C_QOP_DES3_KD           0x0200
+            /* triple-DES with key derivation */
+
+   Rather than open the question of whether to specify means for
+   deriving a key of one type given a key of another type, and the
+   security implications of whether to generate a long key from a
+   shorter one, our implementation will simply return an error if the
+   QOP value specified does not correspond to the session key type.
+
+   [Implementation note: MIT's code does not implement QoP, and
+   returns an error for any non-zero QoP value.]
+
+5.2. MIC Sequence Number Encryption
+
+   The sequence numbers are encrypted in the context key (as defined
+   in [GSSAPI-KRB5] -- this will be either the Kerberos session key or
+   asubkey provided by the context initiator), using whatever
+   encryption system is designated by the type of that context key.
+   The IV is formed from the first N bytes of the SGN_CKSUM field,
+   where N is the number of bytes needed for the IV.  (With all
+   algorithms described here and in [GSSAPI-KRB5], the checksum is at
+   least as large as the IV.)
+
+5.3. Message Layout
+
+   Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
+   checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was
+   specified as being 8 bytes long.  We now change this size to be
+   "defined by the checksum algorithm", and retroactively amend the
+   descriptions of all the checksum algorithms described in
+   [GSSAPI-KRB5] to explicitly specify 8-byte output.  Application
+   data continues to immediately follow the checksum field in the Wrap
+   token.
+
+   The revised message descriptions are thus:
+
+   MIC:
+
+   Byte no          Name           Description
+    0..1           TOK_ID          Identification field.
+    2..3           SGN_ALG         Integrity algorithm indicator.
+    4..7           Filler          Contains ff ff ff ff
+    8..15          SND_SEQ         Sequence number field.
+    16..s+15       SGN_CKSUM       Checksum of "to-be-signed data",
+                                   calculated according to algorithm
+                                   specified in SGN_ALG field.
+
+   Wrap:
+
+   Byte no          Name           Description
+    0..1           TOK_ID          Identification field.
+                                   Tokens emitted by GSS_Wrap() contain
+                                   the hex value 02 01 in this field.
+    2..3           SGN_ALG         Checksum algorithm indicator.
+    4..5           SEAL_ALG        Sealing algorithm indicator.
+    6..7           Filler          Contains ff ff
+    8..15          SND_SEQ         Encrypted sequence number field.
+    16..s+15       SGN_CKSUM       Checksum of plaintext padded data,
+                                   calculated according to algorithm
+                                   specified in SGN_ALG field.
+    s+16..last     Data            encrypted or plaintext padded data
+
+   Where "s" indicates the size of the checksum.
+
+   As indicated above in section 2, we define the HMAC SHA1 DES3-KD
+   checksum algorithm to produce a 20-byte output, so encrypted data
+   begins at byte 36.
+
+6. Backwards Compatibility Considerations
+
+   The context initiator SHOULD request of the KDC credentials using
+   session-key cryptosystem types supported by that implementation; if
+   the only types returned by the KDC are not supported by the
+   mechanism implementation, it MUST indicate a failure.  This may
+   seem obvious, but early implementations of both Kerberos and the
+   GSSAPI Kerberos mechanism supported only DES keys, so the
+   cryptosystem compatibility question was easy to overlook.
+
+   Under the current mechanism, no negotiation of algorithm types
+   occurs, so server-side (acceptor) implementations cannot request
+   that clients not use algorithm types not understood by the server.
+   However, administration of the server's Kerberos data has to be
+   done in communication with the KDC, and it is from the KDC that the
+   client will request credentials.  The KDC could therefore be tasked
+   with limiting session keys for a given service to types actually
+   supported by the Kerberos and GSSAPI software on the server.
+
+   This does have a drawback for cases where a service principal name
+   is used both for GSSAPI-based and non-GSSAPI-based communication,
+   if the GSSAPI implementation does not understand triple-DES but the
+   Kerberos implementation does.  It means that triple-DES session
+   keys cannot be issued for that service principal, which keeps the
+   protection of non-GSSAPI services weaker than necessary.  However,
+   in the most recent MIT releases thus far, while triple-DES support
+   has been present, it has required additional work to enable, so it
+   is not likely to be in use for many services.
+
+   It would also be possible to have clients attempt to get single-DES
+   session keys before trying to get triple-DES session keys, and have
+   the KDC refuse to issue the single-DES keys only for the most
+   critical of services, for which single-DES protection is considered
+   inadequate.  However, that would eliminate the possibility of
+   connecting with the more secure cryptosystem to any service that
+   can be accessed with the weaker cryptosystem.
+
+   We have chosen to go with the former approach, putting the burden
+   on the KDC administration and gaining the best protection possible
+   for GSSAPI services, possibly at the cost of protection of
+   non-GSSAPI Kerberos services running earlier versions of the
+   software.
+
+6. Security Considerations
+
+   Various tradeoffs arise regarding the mixing of new and old
+   software, or GSSAPI-based and non-GSSAPI Kerberos authentication.
+   They are discussed in section 5.
+
+7. References
+
+   [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
+   Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
+   Associates, Inc., May, 1998.
+
+   [GSSAPI] Linn, J., "Generic Security Service Application Program
+   Interface Version 2, Update 1", RFC 2743, January, 2000.
+
+   [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+   RFC 1964, June, 1996.
+
+   [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
+   Authentication Service (V5)",
+   draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+   3", RFC 2026, October, 1996.
+
+8. Author's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this   
+   document itself may not be modified in any way, such as by removing   
+   the copyright notice or references to the Internet Society or other   
+   Internet organizations, except as needed for the purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
new file mode 100644
index 000000000000..64ca1ac498be
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Kerberos Working Group                                        K. Raeburn
+Category: Informational                                              MIT
+Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt    November 24, 2000
+
+
+         Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1]. 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.
+
+1. Abstract
+
+   The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically
+   enumerates encryption and checksum types, independently of how such
+   schemes may be used in Kerberos.  In the long run, a new Kerberos-
+   based mechanism, which does not require separately enumerating for
+   the GSSAPI mechanism each of the various encryption types defined by
+   Kerberos, is probably a better approach.  Various people have
+   expressed interest in designing one, but the work has not yet been
+   completed.
+
+   The MIT Kerberos 5 release version 1.2 includes support for triple-
+   DES with key derivation [KrbRev].  Recent work by the EFF [EFF] has
+   demonstrated the vulnerability of single-DES mechanisms to brute-
+   force attacks by sufficiently motivated and well-funded parties.  So,
+   in the interest of providing increased security in the near term, MIT
+   is adding support for triple-DES to the existing mechanism
+   implementation we ship, as an interim measure.
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+2. New Algorithm Identifiers
+
+   One new sealing algorithm is defined, for use in Wrap tokens.
+
+
+   +--------------------------------------------------------------------+
+   |          name                                octet values          |
+   +--------------------------------------------------------------------+
+   |         DES3-KD                                 02 00              |
+   +--------------------------------------------------------------------+
+
+   This algorithm uses triple-DES with key derivation, with a usage
+   value KG_USAGE_SEAL.  (Unlike the EncryptedData definition in
+   [KrbRev], no integrity protection is needed, so this is "raw" triple-
+   DES, with no checksum attached to the encrypted data.)  Padding is
+   still to 8-byte multiples, and the IV for encrypting application data
+   is zero.
+
+   One new signing algorithm is defined, for use in MIC, Wrap, and
+   Delete tokens.
+
+
+   +--------------------------------------------------------------------+
+   |             name                               octet values        |
+   +--------------------------------------------------------------------+
+   |       HMAC SHA1 DES3-KD                           04 00            |
+   +--------------------------------------------------------------------+
+
+   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
+   with usage KG_USAGE_SIGN, as described in [KrbRev].
+
+   [N.B.: The current [KrbRev] description refers to expired I-Ds from
+   Marc Horowitz.  The text in [KrbRev] may be inadequate to produce an
+   interoperable implementation.]
+
+   The checksum size for this algorithm is 20 octets.  See section 4.3
+   below for the use of checksum lengths of other than eight bytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+3. Key Derivation
+
+   For purposes of key derivation, we add three new usage values to the
+   list defined in [KrbRev]; one for signing messages, one for sealing
+   messages, and one for encrypting sequence numbers:
+
+
+   +--------------------------------------------------------------------+
+   |             name                                    value          |
+   +--------------------------------------------------------------------+
+   |         KG_USAGE_SEAL                                22            |
+   |         KG_USAGE_SIGN                                23            |
+   |         KG_USAGE_SEQ                                 24            |
+   +--------------------------------------------------------------------+
+
+4. Adjustments to Previous Definitions
+
+4.1. Quality of Protection
+
+   The GSSAPI specification [GSSAPI] says that a zero QOP value
+   indicates the "default".  The original specification for the Kerberos
+   5 mechanism says that a zero QOP value (or a QOP value with the
+   appropriate bits clear) means DES encryption.
+
+   Rather than forcing the use of plain DES when the application doesn't
+   use mechanism-specific QOP values, we redefine the explicit DES QOP
+   value as a non-zero value, and define a triple-DES value as well.
+   Then a zero value continues to imply the default, which would be
+   triple-DES protection when given a triple-DES session key.
+
+   Our values are:
+
+   +--------------------------------------------------------------------+
+   |             name                  value      meaning               |
+   +--------------------------------------------------------------------+
+   | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1    0x0004     SHA-1 HMAC, using     |
+   |                                              key derivation        |
+   |                                                                    |
+   |    GSS_KRB5_CONF_C_QOP_DES        0x0100     plain DES encryption  |
+   |                                                                    |
+   |  GSS_KRB5_CONF_C_QOP_DES3_KD      0x0200     triple-DES with key   |
+   |                                              derivation            |
+   +--------------------------------------------------------------------+
+
+   Rather than attempt to specify a generic mechanism for deriving a key
+   of one type given a key of another type, and evaluate the security
+   implications of using a short key to generate a longer key to satisfy
+   the requested quality of protection, our implementation will simply
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   return an error if the nonzero QOP value specified does not
+   correspond to the session key type.
+
+4.2. MIC Sequence Number Encryption
+
+   The sequence numbers are encrypted in the context key (as defined in
+   [GSSAPI-KRB5] -- this will be either the Kerberos session key or
+   asubkey provided by the context initiator), using whatever encryption
+   system is designated by the type of that context key.  The IV is
+   formed from the first N bytes of the SGN_CKSUM field, where N is the
+   number of bytes needed for the IV.  (With all algorithms described
+   here and in [GSSAPI-KRB5], the checksum is at least as large as the
+   IV.)
+
+4.3. Message Layout
+
+   Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
+   checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was specified
+   as being 8 bytes long.  We now change this size to be "defined by the
+   checksum algorithm", and retroactively amend the descriptions of all
+   the checksum algorithms described in [GSSAPI-KRB5] to explicitly
+   specify 8-byte output.  Application data continues to immediately
+   follow the checksum field in the Wrap token.
+
+   The revised message descriptions are thus:
+
+   MIC token:
+
+   Byte #             Name                Description
+   ----------------------------------------------------------------------
+    0..1              TOK_ID              Identification field.
+    2..3              SGN_ALG             Integrity algorithm indicator.
+    4..7              Filler              Contains ff ff ff ff
+    8..15             SND_SEQ             Sequence number field.
+   16..s+15           SGN_CKSUM           Checksum of "to-be-signed
+                                          data", calculated according to
+                                          algorithm specified in SGN_ALG
+                                          field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   Wrap token:
+
+   Byte #           Name             Description
+   ----------------------------------------------------------------------
+    0..1            TOK_ID           Identification field.  Tokens
+                                     emitted by GSS_Wrap() contain the
+                                     hex value 02 01 in this field.
+    2..3            SGN_ALG          Checksum algorithm indicator.
+    4..5            SEAL_ALG         Sealing algorithm indicator.
+    6..7            Filler           Contains ff ff
+    8..15           SND_SEQ          Encrypted sequence number field.
+   16..s+15         SGN_CKSUM        Checksum of plaintext padded data,
+                                     calculated according to algorithm
+                                     specified in SGN_ALG field.
+   s+16..last       Data             encrypted or plaintext padded data
+
+
+   Where "s" indicates the size of the checksum.
+
+   As indicated above in section 2, we define the HMAC SHA1 DES3-KD
+   checksum algorithm to produce a 20-byte output, so encrypted data
+   begins at byte 36.
+
+5. Backwards Compatibility Considerations
+
+   The context initiator should request of the KDC credentials using
+   session-key cryptosystem types supported by that implementation; if
+   the only types returned by the KDC are not supported by the mechanism
+   implementation, it should indicate a failure.  This may seem obvious,
+   but early implementations of both Kerberos and the GSSAPI Kerberos
+   mechanism supported only DES keys, so the cryptosystem compatibility
+   question was easy to overlook.
+
+   Under the current mechanism, no negotiation of algorithm types
+   occurs, so server-side (acceptor) implementations cannot request that
+   clients not use algorithm types not understood by the server.
+   However, administration of the server's Kerberos data (e.g., the
+   service key) has to be done in communication with the KDC, and it is
+   from the KDC that the client will request credentials.  The KDC could
+   therefore be tasked with limiting session keys for a given service to
+   types actually supported by the Kerberos and GSSAPI software on the
+   server.
+
+   This does have a drawback for cases where a service principal name is
+   used both for GSSAPI-based and non-GSSAPI-based communication (most
+   notably the "host" service key), if the GSSAPI implementation does
+   not understand triple-DES but the Kerberos implementation does.  It
+   means that triple-DES session keys cannot be issued for that service
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   principal, which keeps the protection of non-GSSAPI services weaker
+   than necessary.
+
+   It would also be possible to have clients attempt to get single-DES
+   session keys before trying to get triple-DES session keys, and have
+   the KDC refuse to issue the single-DES keys only for the most
+   critical of services, for which single-DES protection is considered
+   inadequate.  However, that would eliminate the possibility of
+   connecting with the more secure cryptosystem to any service that can
+   be accessed with the weaker cryptosystem.
+
+   For MIT's 1.2 release, we chose to go with the former approach,
+   putting the burden on the KDC administration and gaining the best
+   protection possible for GSSAPI services, possibly at the cost of
+   weaker protection of non-GSSAPI Kerberos services running earlier
+   versions of the software.
+
+6. Security Considerations
+
+   Various tradeoffs arise regarding the mixing of new and old software,
+   or GSSAPI-based and non-GSSAPI Kerberos authentication.  They are
+   discussed in section 5.
+
+7. References
+
+   [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
+   Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
+   Associates, Inc., May, 1998.
+
+   [GSSAPI] Linn, J., "Generic Security Service Application Program
+   Interface Version 2, Update 1", RFC 2743, January, 2000.
+
+   [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+   RFC 1964, June, 1996.
+
+   [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
+   Authentication Service (V5)", draft-ietf-cat-kerberos-
+   revisions-06.txt, July 4, 2000.
+
+8. Author's Address
+
+   Kenneth Raeburn Massachusetts Institute of Technology 77
+   Massachusetts Avenue Cambridge, MA 02139
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+10. Document Change History
+
+>From -00 to -01:
+
+   Converted master to GNU troff and tbl, rewriting tables in the
+   process.
+
+   Specify informational category only.  Modify some text to emphasize
+   that this document intends to describe MIT's extensions.
+
+   Point out that while EncryptedData for 3des-kd includes a checksum,
+   DES3-KD GSS encryption does not.
+
+   Shorten backwards-compatibility descriptions a little.
+
+   Submit to Kerberos working group rather than CAT.
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 7]
+
diff --git a/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
new file mode 100644
index 000000000000..321c5ba09986
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
@@ -0,0 +1,929 @@
+
+
+DHC Working Group                                          S. Medvinsky
+Internet Draft                                                 Motorola
+Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
+Category: Standards Track                                    P.Lalwaney
+Expires: January 2001                                             Nokia
+
+                                                              July 2000
+
+
+        Kerberos V Authentication Mode for Uninitialized Clients
+
+
+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.
+
+   The distribution of this memo is unlimited.  It is filed as <draft-
+   smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
+   send comments to the authors.
+
+
+
+1. Abstract
+
+   The Dynamic Host Configuration Protocol (DHCP) [1] includes an
+   option that allows authentication of all DHCP messages, as specified
+   in [2].  This document specifies a DHCP authentication mode based on
+   Kerberos V tickets. This provides mutual authentication between a
+   DHCP client and server, as well as authentication of all DHCP
+   messages.
+
+   This document specifies Kerberos message exchanges between an
+   uninitialized client and the KDC (Key Distribution Center) using an
+   IAKERB proxy [7] so that the Kerberos key management phase is
+   decoupled from, and precedes the address allocation and network
+   configuration phase that uses the DHCP authentication option.  In
+   order to make use of the IAKERB proxy, this document specifies a
+   transport mechanism that works with an uninitialized client (i.e. a
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+   client without an assigned IP address). In addition, the document
+   specifies the format of the Kerberos authenticator to be used with
+   the DHCP authentication option.
+
+2. Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC-2119.
+
+3. Introduction
+
+   3.1 Terminology
+
+   o "DHCP client"
+
+   A DHCP client is an Internet host using DHCP to obtain configuration
+   parameters such as a network address.
+
+   o "DHCP server"
+
+   A DHCP server is an Internet host that returns configuration
+   parameters to DHCP clients.
+
+   O "Ticket"
+
+   A Kerberos term for 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.
+
+   o "Key Distribution Center"
+
+   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 (TGT) 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).
+
+   o "Realm"
+
+   A Kerberos administrative domain that represents a group of
+   principals registered at a KDC.  A single KDC may be responsible for
+   one or more realms.  A fully qualified principal name includes a
+   realm name along with a principal name unique within that realm.
+
+3.2 Protocol Overview
+
+
+
+S. Medvinsky, P. Lalwaney                                          -2-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+   DHCP as defined in [1] defines the protocol exchanges for a client
+   to obtain its IP address and network configuration information from
+   a DHCP Server. Kerberos V5 as described in [6] defines the protocol
+   and message exchanges to mutually authenticate two parties. It is
+   our goal to provide authentication support for DHCP using Kerberos.
+   This implies that the Kerberos key management exchange has to take
+   place before a client gets its IP address from the DHCP Server.
+   Kerberos assumes that the client has a network address and can
+   contact the Key Distribution Center to obtain its credentials for
+   authenticated communication with an application server.
+
+   In this specification we utilize the key exchange using an IAKERB
+   proxy described in [7]. This does not require any changes to either
+   the IAKERB or the Kerberos V5 specification.  This document also
+   specifies a particular transport that allows an uninitialized client
+   to contact an IAKERB proxy.
+
+   The Kerberos ticket returned from the key management exchange
+   discussed in Section 5 of this document is passed to the DHCP Server
+   inside the DHCP authentication option with the new Kerberos
+   authenticator type. This is described in Section 6 of this draft.
+
+
+3.3 Related Work
+
+   A prior Internet Draft [3] outlined the use of Kerberos-based
+   authentication for DHCP. The proposal tightly coupled the Kerberos
+   client state machines and the DHCP client state machines. As a
+   result, the Kerberos key management messages were carried in DHCP
+   messages, along with the Kerberos authenticators. In addition, the
+   first DHCP message exchange (request, offer) is not authenticated.
+
+   We propose a protocol exchange where Kerberos key management is
+   decoupled from and precedes authenticated DHCP exchanges. This
+   implies that the Kerberos ticket returned in the initial key
+   management exchange could be used to authenticate servers assigning
+   addresses by non-DHCP address assignment mechanisms like RSIP [4]
+   and for service specific parameter provisioning mechanisms using SLP
+   [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                          -3-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+4. System Architecture
+
+
+     Client
+    --------                            --------
+   |        |   5.Authenticated DHCP   |        |
+   |  DHCP  |<------------------------>| DHCP   |
+   | client |                          | server |
+   |        |                          |        |
+   |        |                          |        |
+   |Kerberos|                          |        |
+   | Client |                          |        |
+    --------                            --------
+       ^
+       |
+       |
+       |
+       |                                -------
+        ------------------------------>|       |
+         Kerberos Key Mgmt             | Proxy |
+         messages:                     |       |
+          1. AS Request  / 2.AS Reply   -------
+          3. TGS Request / 4.TGS Reply     ^
+                                           | Kerberos
+                                           | Key Mgmt messages
+                                           v (1, 2, 3, 4)
+                                        --------
+                                       |        |
+                                       |  KDC   |
+                                       |        |
+                                        --------
+
+     Figure 1: System blocks and message interactions between them
+
+
+   In this architecture, the DHCP client obtains a Kerberos ticket from
+   the Key Distribution Center (KDC) using standard Kerberos messages,
+   as specified in [6].  The client, however, contacts the KDC via a
+   proxy server, according to the IAKERB mechanism, described in [7].
+   The are several reasons why a client has to go through this proxy in
+   order to contact the KDC:
+
+  a)The client may not know the host address of the KDC and may be
+     sending its first request message as a broadcast on a local
+     network.  The KDC may not be located on the local network, and
+     even if it were - it will be unable to communicate with a client
+     without an IP address.  This document describes a specific
+     mechanism that may be used by a client to communicate with the
+     Kerberos proxy.
+
+
+
+S. Medvinsky, P. Lalwaney                                          -4-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+  b)The client may not know its Kerberos realm name.  The proxy is
+     able to fill in the missing client realm name in an AS Request
+     message, as specified in IAKERB.  Note that in the case that
+     PKINIT pre-authenticator is used [8], the realm name in the AS
+     Request may be the KDC realm name and not the clientÆs realm name.
+
+  c) The client does not know the realm name of the DHCP server.
+
+     According to IAKERB, when the client sends a TGS Request with a
+     missing server realm name, the proxy will return to the client an
+     error message containing the missing realm name.
+
+     Note that in this case the proxy could return the client a wrong
+     realm name and the client could be fooled into obtaining a ticket
+     for the wrong DHCP server (on the same local network).  However,
+     the wrong DHCP server must still be a registered principal in a
+     KDC database.  In some circumstances this may be an acceptable
+     compromise.  Also, see the security considerations section.
+
+     IAKERB describes the proxy as part of an application server - the
+     DHCP server in this case.  However, in this document we are not
+     requiring the proxy to be integrated with the DHCP server.  The
+     same IAKERB mechanisms apply in the more general case, where the
+     proxy is an independent application.  This proxy, however, MUST be
+     reachable by a client via a local network broadcast.
+
+     After a client has obtained a Kerberos ticket for the DHCP server,
+     it will use it as part of an authentication option in the DHCP
+     messages.  The only extension to the DHCP protocol is the addition
+     of a new authenticator type based on Kerberos tickets.
+
+4.1 Cross-Realm Authentication
+
+   Figure 1 shows a client communicating with a single KDC via a proxy.
+   However, the DHCP clientÆs realm may be different from the DHCP
+   serverÆs realm.  In that case, the client may need to first contact
+   the KDC in its local realm to obtain a cross-realm TGT.  Then, the
+   client would use the cross-realm TGT to contact the KDC in the DHCP
+   serverÆs realm, as specified in [6].
+
+   In the following example a client doesnÆt know its realm or the DHCP
+   serverÆs realm, which happens to be different from the clientÆs
+   realm.  Here are the steps in obtaining the ticket for the DHCP
+   server (based on [6] and [7]):
+
+        1) The client sends AS Request with NULL realm to the proxy.
+        2) The proxy fills in the realm and forwards the AS Request to
+           the KDC in the clientÆs realm.
+        3) The KDC issues a TGT and sends back an AS Reply to the
+           proxy.
+        4) The proxy forwards AS Reply to the client.
+
+
+S. Medvinsky, P. Lalwaney                                          -5-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+        5) The client sends TGS Request for a principal name "dhcpsrvr"
+           with NULL realm to the proxy.
+        6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the
+           DHCP serverÆs realm to the client.
+        7) The client sends another TGS Request for a cross-realm TGT
+           to the proxy.
+        8) The proxy forwards the TGS Request to the KDC in the
+           clientÆs realm.
+        9) The KDC issues a cross-realm TGT and sends back a TGS Reply
+           to the proxy.
+       10) The proxy forwards TGS Reply to the client.
+       11) The client sends a TGS Request to the proxy for a principal
+       "dhcpsrvr" with the realm name filled in, using a cross-realm
+       TGT.
+       12) The proxy forwards TGS Request to the KDC in the DHCP      
+       server's realm.
+       13) The KDC issues a ticket for the DHCP server and sends TGS
+       Reply back to the proxy.
+       14) The proxy forwards TGS Reply to the client.
+
+   In a most general case, the client may need to contact any number of
+   KDCs in different realms before it can get a ticket for the DHCP
+   server.  In each case, the client would contact a KDC via the proxy
+   server, as specified in Section 5 of this document.
+
+4.2 Public Key Authentication
+
+   This specification also allows clients to perform public key
+   authentication to the KDC, based on the PKINIT specification [8].
+   In this case, the size of an AS Request and AS Reply messages is
+   likely to exceed the size of typical link MTU's.
+
+   Here is an example, where PKINIT is used by a DHCP client that is
+   not a registered principal in the KDC principal database:
+
+        1) The client sends AS Request with a PKINIT Request pre-
+           authenticator to the proxy.  This includes the clientÆs
+           signature and X.509 certificate.  The KDC realm field is
+           left as NULL.
+        2) The proxy fills in the realm and forwards the AS Request to
+           the KDC in the filled in realm.  This is the realm of the
+           DHCP server.  Here, the clientÆs realm is the name of a
+           Certification Authority - not the same as the KDC realm.
+        3) The KDC issues a TGT and sends back an AS Reply with a
+           PKINIT Reply pre-authenticator to the proxy.
+        4) The proxy forwards the AS Reply to the client.
+        5) The client sends TGS Request for a principal name "dhcpsrvr"
+           with the realm found in the TGT to the proxy.
+        6) The proxy forwards TGS Request to the KDC in the DHCP
+           serverÆs realm.
+        7) The KDC issues a ticket for the DHCP server and sends TGS
+           Reply back to the proxy.
+
+S. Medvinsky, P. Lalwaney                                          -6-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+        8) The proxy forwards TGS Reply to the client.
+
+
+   5. Key Management Exchange that Precedes Network Address Allocation
+
+   An uninitialized host (e.g. on power-on and reset) does not have a
+   network address. It does have a link layer address or hardware
+   address. At this time, the client may not have any information on
+   its realm or the realm of the address allocation server (DHCP
+   Server).
+
+   In the Kerberos key management exchange, a client gets its ticket
+   granting ticket (TGT) by contacting the Authentication Server in the
+   KDC using the AS_Request / Reply messages (shown as messages 1 and 2
+   in Figure 1). The client then contacts the Ticket Granting Server in
+   the KDC to get the DHCP server ticket (to be used for mutual
+   authentication with the DHCP server) using the TGS_REQ / TGS_REP
+   messages (shown as messages 3 and 4 in the above figure).  It is
+   also possible for the client to obtain a DHCP server ticket directly
+   with the AS Request / Reply exchange, without the use of the TGT.
+
+   In the use of Kerberos for DHCP authentication, the client (a) does
+   not have an IP/network address (b) does not know he KDCÆs IP address
+   (c) the KDC may not be on the local network and (d) the client may
+   not know the DHCP ServerÆs IP address and realm.  We therefore
+   require a Kerberos proxy on the local network to accept broadcast
+   Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized
+   clients and relay them to the appropriate KDC.
+
+   The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as
+   follows:
+
+   The request payload contains the client hardware address in
+   addresses field with a negative value for the address type. Kerberos
+   v5 [6] allows for the usage of negative address types for "local"
+   use. Note that IAKERB [7] discourages the use of the addresses field
+   as network addresses may not be known or may change in situation
+   where proxies are used. In this draft we incorporate the negative
+   values permitted in the Kerberos transport in the address type field
+   of both the AS_REQ and TGS_REQ messages. The negative value SHOULD
+   be the negative number of the hardware address type "htype" value
+   (from assigned numbers RFC) used in RFC 2131. The address field of
+   the message contains the clients hardware address.
+
+   The request payload is UDP encapsulated and addressed to port 88 on
+   the server/proxy. The UDP source port is selected by the client. The
+   source and destination network addresses are the all-zeroÆs address
+   and the broadcast address, respectively. For IPv4, the source IP
+   address is set to 0.0.0.0 and the destination IP address is set to
+   255.255.255.255. The data link layer header source address
+   corresponds to the link layer/hardware address of the client. The
+
+
+S. Medvinsky, P. Lalwaney                                          -7-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+   destination link layer address is the broadcast address at the link
+   layer (e.g. for Ethernet the address is ffffffff).
+
+   In the case where AS_REQ message contains a PKINIT pre-authenticator
+   for public key-based client authentication (based on [8]), the
+   message will probably not fit into a single UDP packet given typical
+   link MTU's.
+
+   It is assumed that the proxy server on a network is configured with
+   a list of KDCÆs, their realms and their IP addresses. The proxy
+   server will act as a client to the KDC and forward standard Kerberos
+   messages to/from the KDC using unicast UDP or TCP transport
+   mechanisms, according to [6].
+
+   Upon receiving a broadcast request from a client, the proxy MUST
+   record the clientÆs hardware address that appears as the source
+   address on the frame as well as in the addresses field of the
+   request message. Based on the realm of the KDC specified in the
+   request, the proxy determines the KDC to which this message is
+   relayed as a unicast message from the proxy to the KDC.  In the case
+   that the client left the KDC realm name as NULL, it is up to the
+   proxy to first determine the correct realm name and fill it in the
+   request (according to [7]).
+
+   On receiving a request, the KDC formulates a response (AS_REP or
+   TGS_REP). It includes the clientÆs addresses field in the encrypted
+   part of the ticket (according to [6]). This response is unicast to
+   the proxy.
+
+   Upon receiving the reply, the proxy MUST first determine the
+   previously saved hardware address of the client.  The proxy
+   broadcasts the reply on its local network. This is a network layer
+   broadcast. At the link level, it uses the hardware address obtained
+   from the addresses field of the request.
+
+   The client on receiving the response (link layer destination address
+   as its hardware address, network layer address is the broadcast
+   address) must verify that the hardware address in the ticket
+   corresponds to its link layer address.
+
+   Upon receiving a TGS_REP (or an AS_REP with the application server
+   ticket) from the proxy, the client will have enough information to
+   securely communicate with the application server (the DHCP Server in
+   this case), as specified in the following section.
+
+
+
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                          -8-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+    6. Authenticated Message Exchange Between the DHCP Client and the
+   DHCP Server
+
+   The ticket returned in the TGS response is used by the DHCP client
+   in the construction of the Kerberos authenticator.  The Kerberos
+   ticket serves two purposes: to establish a shared session key with
+   the DHCP server, and is also included as part of a Kerberos
+   authenticator in the DHCP request.
+
+   If the size of the authenticator is greater than 255 bytes, the DHCP
+   authentication option is repeated multiple times.  When the values
+   of all the authentication options are concatenated together, they
+   will make up the complete authenticator.
+
+   Once the session key is established, the Kerberos structure
+   containing the ticket (AP REQ) can be omitted from the authenticator
+   for subsequent messages sent by both the DHCP client and the DHCP
+   server.
+
+   The Kerberos authenticator for a DHCP request message is specified
+   below:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |    Length     |    Protocol   |   Algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +              Replay Detection (64 bits)                       +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +              Authentication token (n octets)           ...    +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The format of this authenticator is in accordance with [2]. The code
+   for the authentication option is TBD, and the length field contains
+   the length of the remainder of the option, starting with the
+   protocol field.
+
+   The value of the protocol field for this authenticator MUST be set
+   to 2.
+
+   The algorithm field MUST take one of the following values:
+        1 - HMAC-MD5
+        2 - HMAC-SHA-1
+
+   Replay protection field is a monotonically increasing counter field.
+   When the Kerberos AP REQ structure is present in the authenticator
+   the counter may be set to any value.  The AP REQ contains its own
+   replay protection mechanism in the form of a timestamp.
+
+S. Medvinsky, P. Lalwaney                                          -9-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+   Once the session key has been established and the AP REQ is not
+   included in the authenticator, this field MUST be monotonically
+   increasing in the messages sent by the client.
+
+   Kerberos authenticator token consists of type-length-value
+   attributes:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |  Reserved     |       Payload Length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           attribute value...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The following attributes are included in the Kerberos authenticator
+   token:
+
+   Type         Attribute Name          Value
+   --------------------------------------------------------------------
+   0            Message Integrity Code  Depends on the value of the
+                                        algorithm field.  Its length is
+                                        16 bytes for HMAC-MD5 [9, 10]
+                                        and 20 bytes for HMAC-SHA-1
+                                        [11, 10].  The HMAC key must be
+                                        derived from Kerberos session
+                                        key found in the Kerberos
+                                        ticket according to the key
+                                        derivation rules in [6]:
+
+                                          HMAC Key = DK(sess key,
+                                                      key usage | 0x99)
+
+                                        Here, DK is defined in [12] and
+                                        the key usage value for DHCP is
+                                        TBD.
+
+                                        The HMAC is calculated over the
+                                        entire DHCP message. The
+                                        Message Integrity Code
+                                        attribute MUST be set to all 0s
+                                        for the computation of the
+                                        HMAC.  Because a DHCP relay
+                                        agent may alter the values of
+                                        the 'giaddr' and 'hops' fields
+                                        in the DHCP message, the
+                                        contents of those two fields
+                                        MUST also be set to zero for
+                                        the computation of the HMAC.
+                                        Rules specified in Section 3 of
+                                        [2] for the exclusion and
+
+S. Medvinsky, P. Lalwaney                                         -10-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+                                        processing of the relay agent
+                                        information are applicable here
+                                        too.
+
+                                        This field MUST always be
+                                        present in the Kerberos
+                                        authenticator.
+
+   1            AP_REQ                  ASN.1 encoding of a Kerberos
+                                        AP_REQ message, as specified
+                                        in [6]. This MUST be included
+                                        by the client when establishing
+                                        a new session key.  In all
+                                        other cases, this attribute
+                                        MUST be omitted.
+
+   AP_REQ contains the Kerberos ticket for the DHCP server and also
+   contains information needed by the DHCP server to authenticate the
+   client.  After verifying the AP_REQ and decrypting the Kerberos
+   ticket, the DHCP server is able to extract a session key which it
+   now shares with the DHCP client.
+
+   The Kerberos authenticator token contains its own replay protection
+   mechanism inside the AP_REQ structure.  The AP_REQ contains a
+   timestamp that must be within an agreed upon time window at the DHCP
+   server.  However, this does not require the DHCP clients to maintain
+   an accurate clock between reboots.  Kerberos allows clients to
+   synchronize their clock with the KDC with the help of Kerberos
+   KRB_AP_ERR_SKEW error message, as specified in [6].
+
+   The DHCP server MUST save both the session key and its associated
+   expiration time found in the Kerberos ticket.  Up until the
+   expiration time, the server must accept client requests with the
+   Kerberos authenticator that does not include the AP REQ, using the
+   saved session key in calculating HMAC values.
+
+   The Kerberos authenticator inside all DHCP server responses MUST NOT
+   contain the AP REQ and MUST use the saved Kerberos session key in
+   calculating HMAC values.
+
+   When the session key expires, it is the client's responsibility to
+   obtain a new ticket from the KDC and to include an AP REQ inside the
+   Kerberos authenticator for the next DHCP request message.
+
+
+
+
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -11-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+7. Detailed message flows for Kerberos and DHCP message Exchanges
+
+   The following flow depicts the Kerberos exchange in which a AS REQ
+   message is used to directly request the DHCP Server ticket. There
+   are no changes to transport mechanisms below when the additional
+   phase of using TGS requests/responses with TGTÆs is used.
+
+   Client                         IAKERB Proxy                 KDC
+
+   KB-client-------- AS_REQ ------>
+
+   AS REQ Address type = - (htype)
+   AS REQ Address= hw address
+
+   src UDP port = senders port
+   destination UDP port = 88
+
+   src IP = 0.0.0.0
+   destination IP = 255.255.255.255
+
+   src link layer address =
+   clientÆs HW/link address [e.g Ethernet address]
+
+   destination link layer address =
+   link broadcast address [e.g. ffffffff for Ethernet]
+
+
+                                         --------------------------->
+                                            (unicast to UDP port 88)
+
+
+
+                                          <--------------------------
+                                             (unicast AS REP)
+                                         Encrypted portion of ticket
+                                         Includes clients HW address
+
+
+      <---------------AS_REP -----------
+
+
+     Ticket includes clientÆs hardware address
+
+     src UDP port = 88
+     destination UDP port = copied from src port in AS_REQ
+
+     src IP = ProxyÆs IP address
+     destination IP = 255.255.255.255
+
+     src link layer address = ProxyÆs HW/link address
+     destination link layer address =
+         ClientÆs link layer address from AS_REQ
+
+
+S. Medvinsky, P. Lalwaney                                         -12-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+
+
+    The client uses the ticket received from the KDC in the DHCP
+Authentication option as described in Section 6.
+
+
+     Client
+     DHCP-client                                   DHCP Server
+
+             ------DHCPDISCOVER ---->
+             (Auth Protocol = 2, includes Kerberos
+              authenticator with AP REQ )
+                                   -----------------------------------
+                                   |  HMAC  |     AP   REQ           |
+                                    ----------------------------------
+                                            | Ticket| Client Authent |
+                                            --------------------------
+
+                                         1. Server decrypts ticket
+                                         (inside AP REQ) with service
+                                         key
+                                         2. Server decrypts client
+                                         authenticator (inside AP REQ)
+                                         and checks content and
+                                         checksum to validate the
+                                         client.
+                                         3. Recompute HMAC with session
+                                         key and compare.
+
+
+          <-------DHCPOFFER----------
+          (Auth Protocol = 2, no AP REQ )
+
+
+
+         ---------DHCPREQUEST------->
+         (Auth Protocol = 2, no AP REQ)
+
+
+          <--------DHCPACK-------------
+           (Auth Protocol = 2, no AP REQ )
+
+
+
+
+8. Security Considerations
+
+   DHCP clients that do not know the DHCP serverÆs realm name will get
+   it from the proxy, as specified in IAKERB [7].  Since the proxy is
+   not authenticated, a DHCP client can be fooled into obtaining a
+   ticket for the wrong DHCP server in the wrong realm.
+
+S. Medvinsky, P. Lalwaney                                         -13-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+   This could happen when the client leaves out the server realm name
+   in a TGS Request message to the proxy.  It is also possible,
+   however, for a client to directly request a DHCP server ticket with
+   an AS Request message.  In those cases, the same situation occurs
+   when the client leaves out the realm name in an AS Request.
+
+   This wrong DHCP server is still registered as a valid principal in a
+   database of a KDC that can be trusted by the client.  In some
+   circumstances a client may assume that a DHCP server that is a
+   Kerberos principal registered with a trusted KDC will not attempt to
+   deliberately misconfigure a client.
+
+   This specification provides a tradeoff between:
+
+        1) The DHCP clients knowing DHCP serverÆs realm ahead of time,
+           which provides for full 2-way authentication at the cost of
+           an additional configuration parameter.
+        2) The DHCP clients not requiring any additional configuration
+           information, besides a password or a key (and a public key
+           certificate if PKINIT is used).  This is at the cost of not
+           being able to fully authenticate the identity of the DHCP
+           server.
+
+
+
+9. References
+
+
+   [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
+      RFC 2131, Bucknell University, March 1997.
+
+   [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
+      draft-ietf-dhc-authentication-13.txt, June 2000.
+
+   [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
+      draft-hornstein-dhc-kerbauth-02.txt, February 2000.
+
+   [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
+      Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
+      protocol-06.txt, March 2000.
+
+   [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
+      Location Protocol, Version 2", RFC 2608, June 1999.
+
+   [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      05.txt, March 2000.
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -14-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+   [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
+      Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
+      draft-ietf-cat-iakerb-03.txt, September 1999.
+
+   [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
+      J. Trostle, "Public Key Cryptography for Initial Authentication
+      in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.
+
+   [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+      1992.
+
+   [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
+      Message Authentication," RFC 2104, February 1997.
+
+   [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
+
+   [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
+      Privacy", draft-horowitz-key-derivation-02.txt, August 1998.
+
+   [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
+   2026.
+
+
+
+ 10. Author's Addresses
+
+   Sasha Medvinsky
+   Motorola
+   6450 Sequence Drive
+   San Diego, CA 92121
+   Email: smedvinsky@gi.com
+
+   Poornima Lalwaney
+   Nokia
+   12278 Scripps Summit Drive
+   San Diego, CA  92131
+   Email: poornima.lalwaney@nokia.com
+
+
+11. Expiration
+
+   This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
+   expires January 1, 2001.
+
+
+
+12. Intellectual Property Notices
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -15-        
+
+Kerberos V Authentication Mode for Uninitialized Clients    March 2000
+
+
+      This section contains two notices as required by [13] for
+   standards track documents.  Per [13], section 10.4(A):
+
+     The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made
+   to obtain a general license or permission for the use of such
+   proprietary rights by implementers or users of this specification
+   can be obtained from the IETF Secretariat.
+
+      Per [13] section 10.4(D):
+
+      The IETF has been notified of intellectual property rights
+   claimed in regard to some or all of the specification contained in
+   this document.  For more information consult the online list of
+   claimed rights.
+
+   13. Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph
+   are included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.  The limited permissions granted above are perpetual and
+   will not be revoked by the Internet Society or its successors or
+   assigns. This document and the information contained herein is
+   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -16-
+
\ No newline at end of file
diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
new file mode 100644
index 000000000000..85d745684b2a
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on July 17, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
new file mode 100644
index 000000000000..85d745684b2a
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on July 17, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
new file mode 100644
index 000000000000..68c170b499ed
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
@@ -0,0 +1,1140 @@
+
+
+
+
+
+
+INTERNET-DRAFT   Kerberized USM Keying    M. Thomas
+                                          Cisco Systems
+                                          K. McCloghrie
+                                          Cisco Systems
+                                          July 13, 2000
+
+
+
+
+
+
+                         Kerberized USM Keying
+
+                   draft-thomas-snmpv3-kerbusm-00.txt
+
+
+
+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.
+
+Abstract
+
+   The KerbUSM MIB provides a means of leveraging a trusted third party
+   authentication and authorization mechanism using Kerberos for SNMP V3
+   USM users and their associated VACM views. The MIB encodes the normal
+   Kerberos AP-REQ and AP-REP means of both authenticating and creating
+   a shared secret between the SNMP V3 Manager and Agent.
+
+The SNMP Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:  An overall architecture, described in RFC 2571
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 1]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   [RFC2571].  Mechanisms for describing and naming objects and events
+   for the purpose of management.  The first version of this Structure
+   of Management Information (SMI) is called SMIv1 and described in STD
+   16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
+   [RFC1215].  The second version, called SMIv2, is described in STD 58,
+   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+   [RFC2580].  Message protocols for transferring management
+   information.  The first version of the SNMP message protocol is
+   called SNMPv1 and described in STD 15, RFC 1157 [RFC1157].  A second
+   version of the SNMP message protocol, which is not an Internet
+   standards track protocol, is called SNMPv2c and described in RFC 1901
+   [RFC1901] and RFC 1906 [RFC1906].  The third version of the message
+   protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC
+   2572 [RFC2572] and RFC 2574 [RFC2574].  Protocol operations for
+   accessing management information.  The first set of protocol
+   operations and associated PDU formats is described in STD 15, RFC
+   1157 [RFC1157].  A second set of protocol operations and associated
+   PDU formats is described in RFC 1905 [RFC1905].  A set of fundamental
+   applications described in RFC 2573 [RFC2573] and the view-based
+   access control mechanism described in RFC 2575 [RFC2575].
+
+   A more detailed introduction to the current SNMP Management Framework
+   can be found in RFC 2570 [RFC2570].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+   This memo specifies a MIB module that is compliant to the SMIv2.  A
+   MIB conforming to the SMIv1 can be produced through the appropriate
+   translations.  The resulting translated MIB must be semantically
+   equivalent, except where objects or events are omitted because no
+   translation is possible (use of Counter64).  Some machine readable
+   information in SMIv2 will be converted into textual descriptions in
+   SMIv1 during the translation process.  However, this loss of machine
+   readable information is not considered to change the semantics of the
+   MIB.
+
+
+Introduction
+
+   The User based Security Model of SNMP V3 (USM) [2] provides a means
+   of associating different users with different access privileges of
+   the various MIB's that an agent supports. In conjunction with the
+   View based Access Control Model of SNMP V3 (VACM) [3], SNMP V3
+   provides a means of providing resistance from various threats both
+   from outside attacks such as spoofing, and inside attacks such as an
+   user having, say, SET access to MIB variable for which they are not
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 2]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   authorized.
+
+   SNMP V3, unfortunately, does not specify a means of doing key
+   distribution between the managers and the agents. For small numbers
+   of agents and managers, the O(n*m) manual keying is a cumbersome, but
+   possibly tractable problem. For a large number of agents with
+   distribution of managers, the key distribution quickly goes from
+   cumbersome to unmanageable. Also: there is always the lingering
+   concern of the security precautions taken for keys on either local
+   management stations, or even directories.
+
+   Kerberos [1] provides a means of centralizing key management into an
+   authentication and authorization server known as a Key Distribution
+   Center (KDC).  At a minimum, Kerberos changes the key distribution
+   problem from a O(n*m) problem to a O(n) problem since keys are shared
+   between the KDC and the Kerberos principals rather directly between
+   each host pair. Kerberos also provides a means to use public key
+   based authentication which can be used to further scale down the
+   number of pre-shared secrets required. Furthermore, a KDC is intended
+   and explicitly expected to be a standalone server which is managed
+   with a much higher level of security concern than a management
+   station or even a central directory which may host many services and
+   thus be exposed to many more possible vectors of attack.
+
+   The MIB defined in this memo describes a means of using the desirable
+   properties of Kerberos within the context of SNMP V3. Kerberos
+   defines a standardized means of communicating with the KDC as well as
+   a standard format of Kerberos tickets which Kerberos principals
+   exchange in order to authenticate to one another. The actual means of
+   exchanging tickets, however, is left as application specific. This
+   MIB defines the SNMP MIB designed to transport Kerberos tickets and
+   by doing so set up SNMP V3 USM keys for authentication and privacy.
+
+   It should be noted that using Kerberos does introduce reliance on a
+   key network element, the KDC. This flies in the face of one of SNMP's
+   dictums of working when the network is misbehaving. While this is a
+   valid concern, the risk of reliance on the KDC can be significantly
+   diminished with a few common sense actions. Since Kerberos tickets
+   can have long life times (days, weeks) a manager of key network
+   elements can and should maintain Kerberos tickets well ahead ticket
+   expiration so that likelihood of not being able to rekey a session
+   while the network is misbehaving is minimized. For non-critical, but
+   high fanout elements such as user CPE, etc, requiring a pre-fetched
+   ticket may not be practical, which puts the KDC into the critical
+   path. However, if all KDC's are unreachable, the non-critical network
+   elements are probably the least of the worries.
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 3]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+Operation
+
+   The normal Kerberos application ticket exchange is accomplished by  a
+   client  first  fetching  a  service ticket from a KDC for the service
+   principal and then sending an AP-REQ  to  a  server  to  authenticate
+   itself  to  the  server. The server then sends a AP-REP to finish the
+   exchange. This MIB maps Kerberos' concept of client and  server  into
+   the  SNMP  V3  concept  of  Manager and Agent by designating that the
+   Kerberos Client is the SNMP V3 Agent. Although  it  could  be  argued
+   that an Agent is really a server, in practice there may be many, many
+   agents and relatively few managers. Also: Kerberos clients  may  make
+   use  of  public  key authentication as defined in [4], and it is very
+   advantageous to take advantage of that capability for  Agents  rather
+   than Managers.
+
+   The MIB is intended to be stateless and map USM users to Kerberos
+   principals. This mapping is explicitly done by putting a Kerberos
+   principal name into the usmUserSecurityName in the usmUser MIB and
+   instatiating the krbUsmMibEntry for the usmUserEntry. MIB variables
+   are accessed with INFORM's or TRAP PDU's and SET's to perform a
+   normal Kerberos AP-REQ/AP-REP exchange transaction which causes the
+   keys for a USM user to be derived and installed. The basic structure
+   of the MIB is a table which augements usmUserEntry's with a Kerberos
+   principal name as well as the transaction varbinds. In the normal
+   case, multiple varbinds should be sent in a single PDU which prevents
+   various race conditions, as well as increasing efficiency.
+
+   It should be noted that this MIB is silent on the subject of how the
+   Agent and Manager find the KDC. In practice, this may be either
+   statically provisioned or use either DNS SRV records (RFC 2782) or
+   Service Location (RFC 2608). This MIB is does not provide for a means
+   of doing cipher suite negotiation either. It is expected that the
+   choices for ciphers in the USM MIB will reflect site specific choices
+   for ciphers. This matches well with the general philosophy of
+   centralized keying.
+
+Keying Transactions
+
+   The following shows an error free transaction:
+
+   Note: optional steps or parameters are shown like [ ]
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 4]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+    Agent                       Manager                            KDC
+ +--                                                               --+
+ | 1) <-------------------------------                               |
+ |     SET (krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx;      |
+ |          [ krbUsmPrinTable[usmUserName].krbUsmMibTgt =            |
+ |                                  TGT[usmUserSecurityName] ]);     |
+ |                                                                   |
+ | 2) ------------------------------->                               |
+ |    Response                                                       |
+ +--                     (optional)                                --+
+
+   3) --------------------------------------------------------------->
+        TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName
+                 [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]);
+
+   4) <--------------------------------------------------------------
+        Tick[usmUserSecurityName] = TGS-REP ();
+
+   5)  ------------------------------>
+        INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq =
+                   AP_REQ[Tick[usmUserSecurityName]];
+                   [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]);
+
+   6)  <------------------------------
+        SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]);
+
+
+   7)  ------------------------------>
+       Response
+
+
+   The above flow translates to:
+
+
+   1)  This step is used when the Manager does not currently have a ses-
+       sion with the Agent but wishes to start one. The Manager MAY
+       place a ticket granting ticket into the krbUsmMibMgrTgt varbind
+       in the same PDU as the krbUsmMibNonce if it does not share a
+       secret with the KDC (as would be the case if the Manager used
+       PKinit to do initial authentication with the KDC).
+
+
+   2)  This step acknowledges the SET. There are no MIB specific errors
+       which can happen here.
+
+
+   3)  If the Agent is not already in possession of a service ticket for
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 5]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+       the Manager in its ticket cache, it MUST request a service ticket
+       from the Agent's KDC for the service principal given by
+       krbUsmMibMgrPrinName in the row that the krbUsmMibNonce was SET
+       in, optionally adding a krbUsmMibMgrTgt.  If the TGT is speci-
+       fied, the Manager's TGT must be placed in the additional-tickets
+       field with the ENC-TKT-IN-SKEY option set in the TGS-REQ to
+       obtain a service ticket (see section 3.3.3 of [1]).
+
+       Note:   a Kerberos TGS-REQ is but one way to obtain a service
+               ticket. An Agent may use any normal Kerberos means to
+               obtain the service ticket. This flow has also elided ini-
+               tial authentication (ie, AS-REQ) and any cross realm con-
+               siderations, though those may be necessary prerequisites
+               to obtaining the service ticket.
+
+   4)  If step 3 was performed, this step receives the ticket or an
+       error from the KDC.
+
+
+   5)  This step sends a krbUsmMibApReq to the Manager via an INFORM or
+       TRAP PDU.  If the message is the result of a request by the
+       Manager, krbUsmMibNonce received from the Manager MUST be sent in
+       the same PDU. If the Manager did not initiate the transaction,
+       the Agent MUST NOT send a krbUsmMibNonce varbind. The Agent also
+       MUST check krbUsmMibUnsolicitedNotify is not false, otherwise it
+       MUST abort the transaction.  All krbUsmMibApReq's MUST contain a
+       sequence nonce so that the resulting krbUsmMibApRep can provide a
+       proof of the freshness of the message to prevent replay attacks.
+
+       If the Agent encounters an error either generated by the KDC or
+       internally, the Agent MUST send an INFORM or TRAP PDU indicating
+       the error in the form of a KRB-ERROR placed in krbUsmMibApReq
+       with the same rules applied to krbUsmMibNonce and krbUsmMibUnsol-
+       icitedNotify above. If the Agent suspects that it is being
+       attacked by a purported Manager which is generating many failed
+       TGS-REQ's to the KDC, it SHOULD meter its TGS-REQ transactions
+       for that Manager to the KDC using an exponential backoff mechan-
+       ism truncated at 10 seconds.
+
+
+
+   6)  Upon recepit of an INFORM or TRAP PDU with a krbUsmMibApReq, a
+       Manager may accept the AP-REQ. If it is accompanied with a
+       krbUsmMibNonce it MUST correlate it with any outstanding transac-
+       tions using its stored nonce for the transaction. If it does not
+       correlate with a current nonce, the request MUST be rejected as
+       it may be a replay.
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 6]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+       If the Manager chooses to reject an unsolicited keying request,
+       it SHOULD send a WrongValue Error to the Agent with the krbUsmMi-
+       bApReq as the subject of the WrongValue. If an Agent receives a
+       WrongValue Error from a Manager it MUST cease retransmission of
+       the INFORM or TRAP PDU's so as to mitigate event avalanches by
+       Agents. There is a possible denial of service attack here, but it
+       must be weighed against the larger problem of network congestion,
+       flapping, etc. Therefore, if the Agent finds that it cannot can-
+       cel an unsolicited Notify (ie, it must be reliable), it MUST use
+       a truncated exponential backoff mechanism with the maximum trun-
+       cation interval set to 10 minutes.
+
+       Otherwise, the Manager MUST send a SET PDU to the Agent which
+       contains a krbUsmMibApRep.
+
+
+   7)  If the Agent detects an error (including detecting replays) in
+       the final AP-REP, it MUST send a WrongValue error with a pointer
+       to the krbUsmMibApRep varbind to indicate its inability to estab-
+       lish the security association. Otherwise, receipt of the positive
+       acknowledgement from the final SET indicates to the Manager that
+       the proper keys have been installed on the Agent in the USM MIB.
+
+Unsolicited Agent Keying Requests
+
+   An Agent may find that it needs to set up a security association for
+   a USM user in order to notify a Manager of some event. When the Agent
+   engine receives a request for a notify, it SHOULD check to see if
+   keying material has been established for the user and that the keying
+   material is valid. If the keying material is not valid and the USM
+   user has been tagged as being a Kerberos principal in a realm, the
+   Agent SHOULD first try to instantiate a security association by
+   obtaining a service ticket for the USM User and follow steps 3-7 of
+   the flow above. This insures that the USM User will have proper key-
+   ing material and providing a mechanism to allow for casual security
+   associations to be built up and torn down. This is especially useful
+   for Agents which may not normally need to be under constant Manager
+   supervision, such as the case with high fan out user residential CPE
+   and other SNMP managed "appliances". In all cases, the Agent MUST NOT
+   send an unsolicited Notify if krbUsmUnsolicitedNotify is set to
+   false.
+
+   How the Agent obtains the Manager's address, how it determines
+   whether a Manager, realm, and whether it can be keyed using this MIB
+   is outside of the scope of this memo.
+
+   Note:   Although the MIB allows for a Manager to set up a session
+           using User-User mode of Kerberos by sending a TGT along with
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 7]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+           the nonce, this, is limited to Manager initiated sessions
+           only since there is no easy way to store the Manager's ticket
+           in the MIB since it is publicly writable and as such would be
+           subject to denial of service attacks. Another method might be
+           to have the Agent send a krbUsmMibNonce to the Manager which
+           would tell it to instigate a session. Overall, it seems like
+           a marginal feature to allow a PKinit authenticated user be
+           the target of unsolicited informs and it would complicate the
+           transactions. For this reason, this scenario has been omitted
+           in favor of simplicity.
+
+Retransmissions
+
+   Since this MIB defines not only variables, but transactions, discus-
+   sion of the retransmission state machine is in order. There are two
+   similar but different state machines for the Manager Solicited and
+   Agent Unsolicited transactions.  There is one timer Timeout which
+   SHOULD take into consideration round trip considerations and MUST
+   implement a truncated exponential backoff mechanism. In addition, in
+   the case where an Agent makes an unsolicited Agent keying request,
+   the Agent SHOULD perform an initial random backoff if the keying
+   request to the Manager may result in a restart avalanche. A suitable
+   method is described in section 4.3.4 of [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 8]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+Manager Solicited Retransmission State Machine
+
+                Timeout
+                 +---+
+                 |   |
+                 |   V
+              +-----------+ Set-Ack (2) +----------+
+              |           |------------>|          |
+              | Set-Nonce |             |  Ap-Req  |
+              |   (1)     |<------------|   (5)    |
+              +-----------+   Timeout   +----------+
+                   ^                         |
+                   |                         | Set-Ap-Rep
+                   |      +----------+       |  (6)
+                   +------|          |<------+
+                  Timeout | Estab-wt |
+                          |   (7)    |
+                          +----------+
+                               |
+                               |  Set-Ap-Rep-Ack (7)
+                               V
+                          +----------+
+                          |          |
+                          |  Estab   |
+                          |          |
+
+                          +----------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 9]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+Agent Unsolicited Retransmission State Machine
+
+                             Timeout
+                              +---+
+                              |   |
+                              |   V
+                          +----------+
+                          |          |
+                   +----> |  Ap-Req  |-------+
+                   |      |   (5)    |       |
+                   |      +----------+       |
+                   |                         |
+                   |                         | Set-Ap-Rep
+                   |      +----------+       |  (6)
+                   +------|          |<------+
+                  Timeout | Estab-wt |
+                          |   (7)    |
+                          +----------+
+                               |
+                               |  Set-Ap-Rep-Ack (7)
+                               V
+                          +----------+
+                          |          |
+                          |  Estab   |
+                          |          |
+                          +----------+
+
+Session Duration and Failures
+
+   The KerbUsmMib uses the ticket lifetime to determine the life of the
+   USM session. The Agent MUST keep track of whether the ticket which
+   instigated the session is valid whenever it forms PDU's for that par-
+   ticular user. If a session expires, or if it wasn't valid to begin
+   with (from the Agent's perspective), the Agent MUST reject the PDU by
+   sending a XXX Error [mat: help me here Keith... what does USM say
+   about this?].
+
+   Kerberos also inherently implies adding state to the Agent and
+   Manager since they share not only a key, but a lifetime associated
+   with that key. This is in some sense soft state because failure of an
+   Agent will cause it to reject PDU's for Managers with whom it does
+   not share a secret. The Manager can use the Error PDU's as an indica-
+   tion that it needs to reauthenticate with the Agent, taking care not
+   to loop. The Manager is even easier: when it reboots, it can either
+   check its credential cache to reconstruct state or cause the Agent to
+   reauthenticate to the Manager with its service ticket by initiating a
+   authentication transaction with the manager.
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 10]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+Manager Collisions
+
+   Managers may freely set up keys for different USM users using this
+   MIB without problem since they access different rows in the krbUsm-
+   PrinTable. However, multiple Managers trying to set up keys for the
+   same USM user is possible but discouraged. The requirement for the
+   Manager is that they MUST share the same service key with the KDC so
+   that they can all decrypt the same service ticket. There are two race
+   conditions, however, which are not well handled:
+
+
+
+1)  At the end of a ticket lifetime, one manager may request the agent
+    to refresh its service ticket causing a new session key to be
+    installed for the USM user leaving the other managers with stale
+    keys. The workaround here is that the Agent will reject the stale
+    manager's PDU's which should inform them to do their own rekeying
+    operations.
+
+
+2)  If multiple managers try to access the same row at the same time,
+    the Agent SHOULD try to keep the transactions separate based on the
+    nonce values. The Managers or the Agents SHOULD NOT break the
+    krbUsmMibNonce and any other additional varbinds into separate PDU's
+    as this may result in a meta stable state. Given normal MTU sizes,
+    this should not be an issue in practice, and this should  at worst
+    devolve into the case above.
+
+   In all cases, the krbUsmMibNonce MUST be the last value to be
+   transmitted, though its position within a PDU is unimportant.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 11]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+   KrbUSM MIB
+
+   KRB-USM-MIB DEFINITIONS ::= BEGIN
+   IMPORTS
+       MODULE-IDENTITY,
+       OBJECT-TYPE, OBJECT-IDENTITY,
+       snmpModules, Counter32, Unsigned32 FROM SNMPv2-SMI
+       TruthValue, DisplayString          FROM SNMPv2-TC
+       usmUserEntry                       FROM SNMP-USER-BASED-SM-MIB
+
+
+
+   krbUsmMib MODULE-IDENTITY
+           LAST-UPDATED "00071300Z"
+           ORGANIZATION "IETF SNMP V3 Working Group"
+           CONTACT-INFO
+             "Michael Thomas
+              Cisco Systems
+              375 E Tasman Drive
+              San Jose, Ca 95134
+              Phone: +1 408-525-5386
+              Fax: +1 801-382-5284
+              email: mat@cisco.com"
+           DESCRIPTION
+              "This MIB contains the MIB variables to
+               exchange Kerberos credentials and a session
+               key to be used to authenticate and set up
+               USM keys"
+
+           ::= { snmpModules nnn }   -- not sure what needs to be here.
+   krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 }
+
+   krbUsmMibAuthInAttemps
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+               DESCRIPTION
+                   "Counter of the number of Kerberos
+                    authorization attempts as defined by
+                    receipt of a PDU from a Manager with a
+                     krbUsmMibNonce set in the principal table."
+               ::= { krbUsmMibObjects 1 }
+
+   krbUsmMibAuthOutAttemps
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 12]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+               DESCRIPTION
+                   "Counter of the number of unsolicited Kerberos
+                    authorization attempts as defined by
+                    an Agent sending an INFORM or TRAP PDU with a
+                    krbUsmMibApRep but without krbUsmApMibNonce
+                    varbind."
+               ::= { krbUsmMibObjects 2 }
+   krbUsmMibAuthInFail
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+               DESCRIPTION
+                   "Counter of the number of Kerberos
+                    authorization failures as defined by
+                    a Manager setting the krbUsmMibNonce
+                    in the principal table which results
+                    in some sort of failure to install keys
+                    in the requested USM user entry."
+               ::= { krbUsmMibObjects 3 }
+
+   krbUsmMibAuthOutFail
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+               DESCRIPTION
+                   "Counter of the number of unsolicited Kerberos
+                    authorization failures as defined by
+                    an Agent sending an INFORM or TRAP PDU with a
+                    krbUsmMibApRep but without a krbUsmMibNonce
+                    varbind which does not result in keys being
+                    installed for that USM user entry."
+               ::= { krbUsmMibObjects 4 }
+
+   krbUsmMibPrinTable OBJECT-TYPE
+               SYNTAX      SEQUENCE OF krbUsmMibEntry
+               MAX-ACCESS  not-accessible
+               STATUS      current
+               DESCRIPTION
+                   "Table which maps Kerberos principals with USM
+                    users as well as the per user variables to key
+                    up sessions"
+               ::= { krbUsmMibObjects 5 }
+
+   krbUsmMibPrinEntry OBJECT-TYPE
+               SYNTAX     KrbUsmMibPrinEntry
+               MAX-ACCESS  not-accessible
+               STATUS      current
+               DESCRIPTION
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 13]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+                   "an entry into the krbMibPrinTable which is a
+                    parallel table to UsmUserEntry table"
+               AUGMENTS { usmUserEntry }
+               ::= { krbUsmMibPrinTable 1 }
+
+   KrbUsmMibPrinEntry SEQUENCE
+    {
+                   krbUsmMibApReq                  OCTET STRING,
+                   krbUsmMibApRep                  OCTET STRING,
+                   krbUsmMibNonce                  OCTET STRING,
+                   krbUsmMibMgrTGT                 OCTET STRING,
+                   krbUsmMibUnsolicitedNotify      TruthValue,
+    }
+
+
+   krbUsmMibApReq OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  accessible-for-notify
+               STATUS      current
+               DESCRIPTION
+                   "This variable contains a DER encoded Kerberos
+                    AP-REQ or KRB-ERROR for the USM user which is
+                    to be keyed. This is sent from the Agent to
+                    the Manager in an INFORM or TRAP request.
+                    KRB-ERROR MUST only be sent to the Manager
+                    if it is in response to a keying request from
+                    the Manager.
+                   "
+               ::= { krbUsmMibPrinEntry 1 }
+
+   krbUsmMibApRep OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "This variable contains the DER encoded response
+                    to an AP-REQ. This variable is SET by the
+                    Manager to acknowledge receipt of an AP-REQ. If
+                    krbUsmMibApRep contains a Kerberos AP-REP, the
+                    Agent must derive keys from the session key
+                    of the Kerberos ticket in the AP-REQ and place
+                    them in the USM database in a manner specified
+                    by [RFC2574]. If the Manager detects an error,
+                    it will instead place a KRB-ERROR in this
+                    variable to inform the Agent of the error.
+
+                    This variable is in effect a write-only variable.
+                    attempts to read this variable will result in a
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 14]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+                    null octet string being returned"
+               ::= { krbUsmMibPrinEntry 2 }
+
+   krbUsmMibNonce OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "SET'ing a krbUsmMibnonce allows a Manager to
+                    determine whether an INFORM or TRAP from an
+                    Agent is an outstanding keying request, or
+                    unsolicited from the Agent. The Manager
+                    initiates keying for a particular USM user
+                    by writing a nonce into the row for which
+                    desires to establish a security association.
+                    The nonce is an ASCII string of the form
+                    ``host:port?nonce'' where:
+
+                    host:  is either an FQDN, or valid ipv4 or ipv6
+                           numerical notation of the Manager which
+                           desires to initiate keying
+                    port:  is the destination port at which that the
+                           Manager may be contacted
+                    nonce: is a number generated by the Manager to
+                           correlate the transaction
+
+                    The same nonce MUST be sent to the Manager in a
+                    subsequent INFORM or TRAP with a krbUsmApReq.
+                    The Agent MUST use the host address and port
+                    supplied in the nonce as the destination of a
+                    subsequent INFORM or TRAP. Unsolicited keying
+                    requests MUST NOT contain a nonce, and should
+                    instead use the destination stored Notifies of
+                    this type.
+
+                    Nonces MUST be highly collision resistant either
+                    using a time based method or a suitable random
+                    number generator. Managers MUST never create
+                    nonces which are 0.
+
+                    This variable is in effect a write-only variable.
+                    Attempts to read this variable will result in a
+                    nonce of value 0 being returned"
+
+
+               ::= { krbUsmMibPrinEntry 3 }
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 15]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   krbUsmMibMgrTgt OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "If the Manager does not possess a symmetric
+                    key with the KDC as would be the case with
+                    a Manager using PKinit for authentication,
+                    the Manager MUST SET its DER encoded ticket
+                    granting ticket into KrbUsmMgrTgt along
+                    with krbUsmMibNonce.
+
+                    The agent will then attach the Manager's TGT
+                    into the additional tickets field of the
+                    TGS-REQ message to the KDC to get a User-User
+                    service ticket.
+
+                    This variable is in effect a write-only variable.
+                    Attempts to read this variable will result in a
+                    null octet string being returned"
+               ::= { krbUsmMibPrinEntry 4 }
+
+
+   krbUsmMibUnsolicitedNotify OBJECT-TYPE
+               SYNTAX      TruthValue
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "If this variable is false, the Agent MUST NOT
+                    send unsolicited INFORM or TRAP PDU's to the
+                    Manager.
+
+                    Attempts to SET this variable by the no-auth
+                    no-priv user MUST be rejected."
+               ::= { krbUsmMibPrinEntry 5 }
+
+   --
+   -- Conformance section... nothing optional.
+
+   krbUsmMibCompliences MODULE-COMPLIANCE
+               STATUS       current
+               DESCRIPTION "The compliance statement for SNMP
+                            engines whichimplement the KRB-USM-MIB
+                   "
+               MODULE       -- this module
+                       MANDATORY-GROUPS { krbUsmMib }
+       ::= { krbUsmMibCompliances 1 }
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 16]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   END
+
+
+Key Derivation
+
+   The session key provides the basis for the keying material for the
+   USM user specified in the AP-REQ.  The actual keys for use for the
+   authentication and privacy are produced using the cryptographic hash-
+   ing function used to protect the ticket itself.  The keying material
+   is derived using this function, F(key, salt), using successive
+   interations of F over the salt string "SNMPV3RULZ%d", where %d is a
+   monotonic counter starting at zero. The bits are taken directly from
+   the successive interations to produce two keys of appropriate size
+   (as specified in the USM user row) for the authentication transform
+   first, and the privacy transform second. If the authentication
+   transform is null, the first bits of the derived key are used for the
+   privacy transform.
+
+Security Considerations
+
+   Various elements of this MIB must be readable and writable as the
+   no-auth, no-priv user. Unless specifically necessary for the key
+   negotiation, elements of this MIB SHOULD be protected by VACM views
+   which limit access. In particular, there is no reason anything in
+   this MIB should be visible to a no-auth, no-priv user with the excep-
+   tion of KrbUsmMibApReq, KrbUsmMibApRep, KrbUsmMibNonce, and
+   KrbUsmMibMgrTgt, and then only with the restrictions placed on them
+   in the MIB. As such, probing attacks are still possible, but should
+   not be profitable: all of the writable variables with interesting
+   information in them are defined in such a way as to be write only.
+
+   There are some interesting denial of service attacks which are possi-
+   ble by attackers spoofing managers and putting load on the KDC to
+   generate unnecessary tickets. For large numbers or agents this could
+   be problematic. This can probably be mitigated by the KDC prioritiz-
+   ing TGS-REQ's though.
+
+
+References
+
+[1]         The CAT Working Group,  J.  Kohl,  C.Neuman,  "The  Kerberos
+            Network  Authentication  Service  (V5)", RFC 1510, September
+            1993
+
+[2]         The SNMPV3 Working Group, U.  Blumenthal,  B.  Wijnen,  "The
+            User-based Security Model of SNMP V3", RFC 2574, April 1999
+
+[3]         The SNMPV3 Working Group, B. Wijnen, R. Presuhn,
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 17]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+            K.McCloghrie, "The View-based Access Control Model of SNMP
+            V3", RFC 2575, April 1999
+
+[4]         The CAT Working Group, Tung, et al, "Public Key Cryptography
+            for Initial Authentication in Kerberos", draft-ietf-cat-pk-
+            init-11, November 1999
+
+[5]         Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC
+            2705, October 1999
+
+
+[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, An Architecture
+            for Describing SNMP Management Frameworks, RFC 2571, April
+            1999.
+
+[RFC1155]   Rose, M., and K. McCloghrie, Structure and Identification of
+            Management Information for TCP/IP-based Internets, STD 16,
+            RFC 1155, May 1990.
+
+[RFC1212]   Rose, M., and K. McCloghrie, Concise MIB Definitions, STD
+            16, RFC 1212, March 1991.
+
+[RFC1215]   M. Rose, A Convention for Defining Traps for use with the
+            SNMP, RFC 1215, March 1991.
+
+[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+            Rose, M., and S. Waldbusser, Structure of Management Infor-
+            mation Version 2 (SMIv2), STD 58, RFC 2578, April 1999.
+
+[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+            Rose, M., and S. Waldbusser, Textual Conventions for SMIv2,
+            STD 58, RFC 2579, April 1999.
+
+[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+            Rose, M., and S. Waldbusser, Conformance Statements for
+            SMIv2, STD 58, RFC 2580, April 1999.
+
+[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple
+            Network Management Protocol, STD 15, RFC 1157, May 1990.
+
+[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+            Introduction to Community-based SNMPv2, RFC 1901, January
+            1996.
+
+[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Tran-
+            sport Mappings for Version 2 of the Simple Network Manage-
+            ment Protocol (SNMPv2), RFC 1906, January 1996.
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 18]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, Message
+            Processing and Dispatching for the Simple Network Management
+            Protocol (SNMP), RFC 2572, April 1999.
+
+[RFC2574]   Blumenthal, U., and B. Wijnen, User-based Security Model
+            (USM) for version 3 of the Simple Network Management Proto-
+            col (SNMPv3), RFC 2574, April 1999.
+
+[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Pro-
+            tocol Operations for Version 2 of the Simple Network Manage-
+            ment Protocol (SNMPv2), RFC 1905, January 1996.
+
+[RFC2573]   Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications,
+            RFC 2573, April 1999.
+
+[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, View-based
+            Access Control Model (VACM) for the Simple Network Manage-
+            ment Protocol (SNMP), RFC 2575, April 1999.
+
+[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart, Introduc-
+            tion to Version 3 of the Internet-standard Network Manage-
+            ment Framework, RFC 2570, April 1999.
+
+Author's Address
+
+          Michael Thomas
+          Cisco Systems
+          375 E Tasman Rd
+          San Jose, Ca, 95134, USA
+          Tel: +1 408-525-5386
+          email: mat@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 19]
+
+
diff --git a/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
new file mode 100644
index 000000000000..b89108a53be9
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
@@ -0,0 +1,227 @@
+
+CAT Working Group                                     Mike Swift 
+draft-trostle-win2k-cat-kerberos-set-passwd-00.txt    Microsoft               
+February 2000                                         Jonathan Trostle
+Category: Informational                               Cisco Systems
+                                                      John Brezak
+                                                      Microsoft
+
+         Extending Change Password for Setting Kerberos Passwords
+
+
+0. 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.
+
+   Comments and suggestions on this document are encouraged.  Comments 
+   on this document should be sent to the CAT working group discussion 
+   list:
+                       ietf-cat-wg@stanford.edu
+
+1. Abstract
+
+   The Kerberos [1] change password protocol [2], does not allow for 
+   an administrator to set a password for a new user. This functionality
+   is useful in some environments, and this proposal extends [2] to
+   allow password setting. The changes are: adding new fields to the 
+   request message to indicate the principal which is having its 
+   password set, not requiring the initial flag in the service ticket, 
+   using a new protocol version number, and adding three new result 
+   codes. 
+   
+2. The Protocol
+
+   The service must accept requests on UDP port 464 and TCP port 464 as 
+   well. The protocol consists of a single request message followed by 
+   a single reply message.  For UDP transport, each message must be fully 
+   contained in a single UDP packet.
+
+   For TCP transport, there is a 4 octet header in network byte order
+   precedes the message and specifies the length of the message. This
+
+   requirement is consistent with the TCP transport header in 1510bis.
+
+Request Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REQ length        |         AP_REQ data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                        KRB-PRIV message                       /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   All 16 bit fields are in big-endian order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0xff80 (big-endian 
+   integer).
+
+   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REQ data: (see [1]) The AP-REQ message must be for the service 
+   principal kadmin/changepw@REALM, where REALM is the REALM of the user 
+   who wishes to change/set his password. The ticket in the AP-REQ must 
+   must include a subkey in the Authenticator. To enable setting of 
+   passwords, it is not required that the initial flag be set in the 
+   Kerberos service ticket.
+
+   KRB-PRIV message (see [1]) This KRB-PRIV message must be generated 
+   using the subkey from the authenticator in the AP-REQ data. 
+
+   The user-data component of the message consists of the following ASN.1 
+   structure encoded as an OCTET STRING:
+
+   ChangePasswdData ::=  SEQUENCE {
+                       newpasswd[0]   OCTET STRING,
+                       targname[2]    PrincipalName OPTIONAL,
+                       targrealm[3]   Realm OPTIONAL
+                       }  
+
+   The server must verify the AP-REQ message, check whether the client 
+   principal in the ticket is authorized to set/change the password 
+   (either for that principal, or for the principal in the targname 
+   field if present), and decrypt the new password. The server also 
+   checks whether the initial flag is required for this request, 
+   replying with status 0x0007 if it is not set and should be. An 
+   authorization failure is cause to respond with status 0x0005. For 
+   forward compatibility, the server should be prepared to ignore fields 
+   after targrealm in the structure that it does not understand. 
+
+   The newpasswd field contains the cleartext password, and the server 
+   should apply any local policy checks including password policy checks. 
+   The server then generates the appropriate keytypes from the password
+
+   and stores them in the KDC database. If all goes well, status 0x0000 
+   is returned to the client in the reply message (see below).
+
+Reply Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REP length        |         AP-REP data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                         KRB-PRIV message                      /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   All 16 bit fields are in big-endian order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0001 (big-endian 
+   integer). (The reply message has the same format as in [2]).
+
+   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
+   packet.
+   
+   KRB-PRIV from [2]: This KRB-PRIV message must be generated using the 
+   subkey in the authenticator in the AP-REQ data.
+
+   The server will respond with a KRB-PRIV message unless it cannot
+   decode the client AP-REQ or KRB-PRIV message, in which case it will
+   respond with a KRB-ERROR message. NOTE: Unlike change password version
+   1, the KRB-ERROR message will be sent back without any encapsulation.
+
+   The user-data component of the KRB-PRIV message, or e-data component 
+   of the KRB-ERROR message, must consist of the following data.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          result code          |        result string          /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      result code (16 bits) (result codes 0-4 are from [2]):
+         The result code must have one of the following values (big-
+         endian integer):
+         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
+                                     allowed in a KRB-ERROR message)
+         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
+         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
+                                     processing the request (for example, 
+                                     there is a resource or other problem 
+                                     causing the request to fail)
+
+         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
+                                     authentication processing
+         KRB5_KPASSWD_SOFTERROR    4 request fails due to a "soft" error 
+                                     in processing the request 
+         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
+         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
+         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
+         0xFFFF if the request fails for some other reason.
+         Although only a few non-zero result codes are specified here,
+         the client should accept any non-zero result code as indicating
+         failure.
+      result string - from [2]:
+         This field should contain information which the server thinks
+         might be useful to the user, such as feedback about policy
+         failures.  The string must be encoded in UTF-8.  It may be
+         omitted if the server does not wish to include it.  If it is
+         present, the client should display the string to the user.
+         This field is analogous to the string which follows the numeric
+         code in SMTP, FTP, and similar protocols.
+
+3. References
+ 
+   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
+   Service (V5). Request for Comments 1510.
+
+   [2] M. Horowitz. Kerberos Change Password Protocol.
+   ftp://ds.internic.net/internet-drafts/
+   draft-ietf-cat-kerb-chg-password-02.txt
+
+4. Expiration Date
+
+   This draft expires in August 2000.   
+
+5. Authors' Addresses
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+   Email: jtrostle@cisco.com
+
+   Mike Swift 
+   1 Microsoft Way
+   Redmond, WA 98052
+   mikesw@microsoft.com
+
+   John Brezak
+   1 Microsoft Way
+   Redmond, WA 98052
+   jbrezak@microsoft.com
diff --git a/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt
new file mode 100644
index 000000000000..e9611e395bfd
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt
@@ -0,0 +1,327 @@
+Network Working Group                                    T. Ts'o, Editor
+Internet-Draft                     Massachusetts Institute of Technology
+draft-tso-telnet-krb5-04.txt                                  April 2000
+
+               Telnet Authentication: Kerberos Version 5
+
+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 mate-
+   rial 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.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+0. Abstract
+
+   This document describes how Kerberos Version 5 [1] is used with the
+   telnet protocol.   It describes an telnet authentication sub-option
+   to be used with the telnet authentication option [2].   This mecha-
+   nism can also used to provide keying material to provide data confi-
+   dentiality services in conjuction with the telnet encryption option
+   [3].
+
+1. Command Names and Codes
+
+   Authentication Types
+
+      KERBEROS_V5    2
+
+   Sub-option Commands
+
+                           Expires Sept 2000                    [Page 1]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+      AUTH               0
+      REJECT             1
+      ACCEPT             2
+      RESPONSE           3
+      FORWARD            4
+      FORWARD_ACCEPT     5
+      FORWARD_REJECT     6
+
+2.  Command Meanings
+
+   IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
+   KRB_AP_REQ message> IAC SE
+
+      This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
+      remote side of the connection.  The first octet of the <authenti-
+      cation-type-pair> value is KERBEROS_V5, to indicate that Version 5
+      of Kerberos is being used.  The Kerberos V5 authenticator in the
+      KRB_AP_REQ message     must contain a Kerberos V5 checksum of the
+      two-byte authentication type pair.  This checksum must be verified
+      by the server to assure that the authentication type pair was cor-
+      rectly negotiated.  The Kerberos V5 authenticator must also in-
+      clude the optional subkey field, which shall be filled in with a
+      randomly chosen key.  This key shall be used for encryption pur-
+      poses if encryption is negotiated, and shall be used as the nego-
+      tiated session key (i.e., used as keyid 0) for the purposes of the
+      telnet encryption option; if the subkey is not filled in, then the
+      ticket session key will be used instead.
+
+      If data confidentiality services is desired the ENCRYPT_US-
+      ING_TELOPT flag must be set in the authentication-type-pair as
+      specified in [2].
+
+   IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
+
+      This command indicates that the authentication was successful.
+
+      If the AUTH_HOW_MUTUAL bit is set in the second octet of the au-
+      thentication-type-pair, the RESPONSE command must be sent before
+      the ACCEPT command is sent.
+
+   IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op-
+   tional reason for rejection> IAC SE
+
+      This command indicates that the authentication was not successful,
+      and if there is any more data in the sub-option, it is an ASCII
+      text message of the reason for the rejection.
+
+   IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
+   <KRB_AP_REP message> IAC SE
+
+                           Expires Sept 2000                    [Page 2]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+      This command is used to perform mutual authentication.  It is only
+      used when the AUTH_HOW_MUTUAL bit is set in the second octet of
+      the authentication-type-pair.  After an AUTH command is verified,
+      a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
+      message to perform the mutual authentication.
+
+   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
+   message> IAC SE
+
+      This command is used to forward kerberos credentials for use by
+      the remote session.  The credentials are passed as a Kerberos V5
+      KRB_CRED message which includes, among other things, the forwarded
+      Kerberos ticket and a session key associated with the ticket. Part
+      of the KRB_CRED message is encrypted in the key previously ex-
+      changed for the telnet session by the AUTH suboption.
+
+   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
+   SE
+
+      This command indicates that the credential forwarding was success-
+      ful.
+
+   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op-
+   tional reason for rejection> IAC SE
+
+      This command indicates that the credential forwarding was not suc-
+      cessful, and if there is any more data in the sub-option, it is an
+      ASCII text message of the reason for the rejection.
+
+3.  Implementation Rules
+
+   If the second octet of the authentication-type-pair has the AUTH_WHO
+   bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
+   AUTH command, and the server responds with either ACCEPT or REJECT.
+   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv-
+   er will send a RESPONSE before it sends the ACCEPT.
+
+   If the second octet of the authentication-type-pair has the AUTH_WHO
+   bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
+   AUTH command, and the client responds with either ACCEPT or REJECT.
+   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
+   client will send a RESPONSE before it sends the ACCEPT.
+
+   The Kerberos principal used by the server will generally be of the
+   form "host/<hostname>@realm".  That is, the first component of the
+   Kerberos principal is "host"; the second component is the fully qual-
+   ified lower-case hostname of the server; and the realm is the Ker-
+   beros realm to which the server belongs.
+
+                           Expires Sept 2000                    [Page 3]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+   Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
+   messages, the KRB_CRED structure, or the optional rejection text
+   string must be doubled as specified in [4].  Otherwise the following
+   byte might be mis-interpreted as a Telnet command.
+
+4.  Examples
+
+   User "joe" may wish to log in as user "pete" on machine "foo".  If
+   "pete" has set things up on "foo" to allow "joe" access to his ac-
+   count, then the client would send IAC SB AUTHENTICATION NAME "pete"
+   IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
+   IAC SE
+
+   The server would then authenticate the user as "joe" from the
+   KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
+   Kerberos, and if "pete" has allowed "joe" to use his account, the
+   server would then continue the authentication sequence by sending a
+   RESPONSE (to do mutual authentication, if it was requested) followed
+   by the ACCEPT.
+
+   If forwarding has been requested, the client then sends IAC SB AU-
+   THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure
+   with credentials to be forwarded> IAC SE.  If the server succeeds in
+   reading the forwarded credentials, the server sends FORWARD_ACCEPT
+   else, a FORWARD_REJECT is sent back.
+
+       Client                           Server
+                                        IAC DO AUTHENTICATION
+       IAC WILL AUTHENTICATION
+
+       [ The server is now free to request authentication information.
+         ]
+
+                                        IAC SB AUTHENTICATION SEND
+                                        KERBEROS_V5 CLIENT|MUTUAL
+                                        KERBEROS_V5 CLIENT|ONE_WAY IAC
+                                        SE
+
+       [ The server has requested mutual Version 5 Kerberos
+         authentication.  If mutual authentication is not supported,
+         then the server is willing to do one-way authentication.
+
+         The client will now respond with the name of the user that it
+         wants to log in as, and the Kerberos ticket.  ]
+
+       IAC SB AUTHENTICATION NAME
+       "pete" IAC SE
+       IAC SB AUTHENTICATION IS
+       KERBEROS_V5 CLIENT|MUTUAL AUTH
+       <KRB_AP_REQ message> IAC SE
+
+                           Expires Sept 2000                    [Page 4]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+       [ Since mutual authentication is desired, the server sends across
+         a RESPONSE to prove that it really is the right server.  ]
+
+                                        IAC SB AUTHENTICATION REPLY
+                                        KERBEROS_V5 CLIENT|MUTUAL
+                                        RESPONSE <KRB_AP_REP message>
+                                        IAC SE
+
+       [ The server responds with an ACCEPT command to state that the
+         authentication was successful.  ]
+
+                                        IAC SB AUTHENTICATION REPLY KER-
+                                        BEROS_V5 CLIENT|MUTUAL ACCEPT
+                                        IAC SE
+
+       [ If so requested, the client now sends the FORWARD command to
+         forward credentials to the remote site.  ]
+
+       IAC SB AUTHENTICATION IS KER-
+       BEROS_V5 CLIENT|MUTUAL
+       FORWARD <KRB_CRED message> IAC
+       SE
+
+       [ The server responds with a FORWARD_ACCEPT command to state that
+         the credential forwarding was successful.  ]
+
+                           Expires Sept 2000                    [Page 5]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+                                        IAC SB AUTHENTICATION REPLY KER-
+                                        BEROS_V5 CLIENT|MUTUAL FOR-
+                                        WARD_ACCEPT IAC SE
+
+5. Security Considerations
+
+   The selection of the random session key in the Kerberos V5 authenti-
+   cator is critical, since this key will be used for encrypting the
+   telnet data stream if encryption is enabled.  It is strongly advised
+   that the random key selection be done using cryptographic techniques
+   that involve the Kerberos ticket's session key.  For example, using
+   the current time, encrypting it with the ticket session key, and then
+   correcting for key parity is a strong way to generate a subsession
+   key, since the ticket session key is assumed to be never disclosed to
+   an attacker.
+
+   Care should be taken before forwarding a user's Kerberos credentials
+   to the remote server.  If the remote server is not trustworthy, this
+   could result in the user's credentials being compromised.  Hence, the
+   user interface should not forward credentials by default; it would be
+   far safer to either require the user to explicitly request creden-
+   tials forwarding for each connection, or to have a trusted list of
+   hosts for which credentials forwarding is enabled, but to not enable
+   credentials forwarding by default for all machines.
+
+6. IANA Considerations
+
+   The authentication type KERBEROS_V5 and its associated suboption values
+   are registered with IANA.  Any suboption values used to extend 
+   the protocol as described in this document must be registered
+   with IANA before use.  IANA is instructed not to issue new suboption
+   values without submission of documentation of their use.
+
+7. Acknowledgments
+
+   This document was originally written by Dave Borman of Cray Research,
+   Inc.  Theodore Ts'o of MIT revised it to reflect the latest implemen-
+   tation experience.  Cliff Neuman and Prasad Upasani of USC's Informa-
+   tion Sciences Institute developed the credential forwarding support.
+
+   In addition, the contributions of the Telnet Working Group are also
+   gratefully acknowledged.
+
+8. References
+
+   [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
+       tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem-
+       ber 1993.
+
+   [2] Internet Engineering Task Force, "Telnet Authentication", draft-
+       tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems,
+           April 2000.
+
+   [3] Internet Engineering Task Force, "Telnet Data Encryption Option",
+       draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux
+       Systems,     April 2000.
+
+   [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
+
+                           Expires Sept 2000                    [Page 6]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+       855, STD 8, USC/Information Sciences Institute, May 1983.
+
+Editor's Address
+
+   Theodore Ts'o
+   Massachusetts Institute of Technology
+   MIT Room E40-343
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone: (617) 253-8091
+   EMail: tytso@mit.edu
+
+                           Expires Sept 2000                    [Page 7]
+
+
+    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
+                 The Kermit Project * Columbia University
+              612 West 115th St #716 * New York, NY * 10025
+  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org
+
+
diff --git a/crypto/heimdal/doc/standardisation/rc4-hmac.txt b/crypto/heimdal/doc/standardisation/rc4-hmac.txt
new file mode 100644
index 000000000000..202d44e8639c
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/rc4-hmac.txt
@@ -0,0 +1,587 @@
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-03.txt              Microsoft 
+Category: Informational                                       June 2000 
+ 
+ 
+           The Windows 2000 RC4-HMAC Kerberos encryption type 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1]. 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. 
+    
+1. Abstract 
+    
+   The Windows 2000 implementation of Kerberos introduces a new 
+   encryption type based on the RC4 encryption algorithm and using an 
+   MD5 HMAC for checksum. This is offered as an alternative to using 
+   the existing DES based encryption types. 
+    
+   The RC4-HMAC encryption types are used to ease upgrade of existing 
+   Windows NT environments, provide strong crypto (128-bit key 
+   lengths), and provide exportable (meet United States government 
+   export restriction requirements) encryption. 
+    
+   The Windows 2000 implementation of Kerberos contains new encryption 
+   and checksum types for two reasons: for export reasons early in the 
+   development process, 56 bit DES encryption could not be exported, 
+   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
+   accounts will not have the appropriate DES keying material to do the 
+   standard DES encryption. Furthermore, 3DES is not available for 
+   export, and there was a desire to use a single flavor of encryption 
+   in the product for both US and international products. 
+    
+   As a result, there are two new encryption types and one new checksum 
+   type introduced in Windows 2000. 
+    
+    
+2. Conventions used in this document 
+    
+
+  
+Swift                  Category - Informational                      1 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+3. Key Generation 
+    
+   On upgrade from existing Windows NT domains, the user accounts would 
+   not have a DES based key available to enable the use of DES base 
+   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
+   the same as the existing Windows NT key (NT Password Hash) for 
+   compatibility reasons. Once the account password is changed, the DES 
+   based keys are created and maintained. Once the DES keys are 
+   available DES based encryption types can be used with Kerberos.  
+    
+   The RC4-HMAC String to key function is defined as follow: 
+    
+   String2Key(password) 
+    
+        K = MD4(UNICODE(password)) 
+         
+   The RC4-HMAC keys are generated by using the Windows UNICODE version 
+   of the password. Each Windows UNICODE character is encoded in 
+   little-endian format of 2 octets each. Then performing an MD4 [6] 
+   hash operation on just the UNICODE characters of the password (not 
+   including the terminating zero octets). 
+    
+   For an account with a password of "foo", this String2Key("foo") will 
+   return: 
+    
+        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
+        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
+    
+4. Basic Operations 
+    
+   The MD5 HMAC function is defined in [3]. It is used in this 
+   encryption type for checksum operations. Refer to [3] for details on 
+   its operation. In this document this function is referred to as 
+   HMAC(Key, Data) returning the checksum using the specified key on 
+   the data. 
+    
+   The basic MD5 hash operation is used in this encryption type and 
+   defined in [7]. In this document this function is referred to as 
+   MD5(Data) returning the checksum of the data. 
+    
+   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
+   compatible cipher is described in [8]. In this document the function 
+   is referred to as RC4(Key, Data) returning the encrypted data using 
+   the specified key on the data. 
+    
+   These encryption types use key derivation as defined in [9] (RFC-
+   1510BIS) in Section titled "Key Derivation". With each message, the 
+   message type (T) is used as a component of the keying material. This 
+   summarizes the different key derivation values used in the various 
+  
+Swift                  Category - Informational                      2 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   operations. Note that these differ from the key derivations used in 
+   other Kerberos encryption types. 
+    
+        T = 1 for TS-ENC-TS in the AS-Request 
+        T = 8 for the AS-Reply  
+        T = 7 for the Authenticator in the TGS-Request 
+        T = 8 for the TGS-Reply  
+        T = 2 for the Server Ticket in the AP-Request 
+        T = 11 for the Authenticator in the AP-Request 
+        T = 12 for the Server returned AP-Reply 
+        T = 15 in the generation of checksum for the MIC token 
+        T = 0 in the generation of sequence number for the MIC token  
+        T = 13 in the generation of checksum for the WRAP token 
+        T = 0 in the generation of sequence number for the WRAP token  
+        T = 0 in the generation of encrypted data for the WRAPPED token 
+    
+   All strings in this document are ASCII unless otherwise specified. 
+   The lengths of ASCII encoded character strings include the trailing 
+   terminator character (0). 
+    
+   The concat(a,b,c,...) function will return the logical concatenation 
+   (left to right) of the values of the arguments. 
+    
+   The nonce(n) function returns a pseudo-random number of "n" octets. 
+    
+5. Checksum Types 
+    
+   There is one checksum type used in this encryption type. The 
+   Kerberos constant for this type is: 
+        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
+    
+   The function is defined as follows: 
+    
+   K - is the Key 
+   T - the message type, encoded as a little-endian four byte integer 
+    
+   CHKSUM(K, T, data) 
+    
+        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
+        tmp = MD5(concat(T, data)) 
+        CHKSUM = HMAC(Ksign, tmp) 
+    
+    
+6. Encryption Types 
+    
+   There are two encryption types used in these encryption types. The 
+   Kerberos constants for these types are: 
+        #define KERB_ETYPE_RC4_HMAC             23 
+        #define KERB_ETYPE_RC4_HMAC_EXP         24 
+    
+   The basic encryption function is defined as follow: 
+    
+   T = the message type, encoded as a little-endian four byte integer. 
+  
+Swift                  Category - Informational                      3 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+    
+        BYTE L40[14] = "fortybits"; 
+        BYTE SK = "signaturekey"; 
+         
+        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 10 + 4, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            add_8_random_bytes(data, data_len, conf_plus_data); 
+            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
+            HMAC (K1, checksum, 16, K3); 
+            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
+            memcpy (edata, checksum, 16); 
+            edata_len = 16 + 8 + data_len; 
+        }         
+         
+        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            HMAC (K1, edata, 16, K3); // checksum is at edata 
+            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
+            data_len = edata_len - 16 - 8; 
+            memcpy (data, edata + 16 + 8, data_len); 
+             
+            // verify generated and received checksums 
+            HMAC (K2, edata + 16, edata_len - 16, checksum); 
+            if (memcmp(edata, checksum, 16) != 0)  
+                printf("CHECKSUM ERROR  !!!!!!\n"); 
+        } 
+    
+   The header field on the encrypted data in KDC messages is: 
+    
+        typedef struct _RC4_MDx_HEADER { 
+            UCHAR Checksum[16]; 
+            UCHAR Confounder[8]; 
+        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
+         
+   The KDC message is encrypted using the ENCRYPT function not 
+   including the Checksum in the RC4_MDx_HEADER. 
+    
+  
+Swift                  Category - Informational                      4 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+7. Key Strength Negotiation 
+    
+   A Kerberos client and server can negotiate over key length if they 
+   are using mutual authentication. If the client is unable to perform 
+   full strength encryption, it may propose a key in the "subkey" field 
+   of the authenticator, using a weaker encryption type. The server 
+   must then either return the same key or suggest its own key in the 
+   subkey field of the AP reply message. The key used to encrypt data 
+   is derived from the key returned by the server. If the client is 
+   able to perform strong encryption but the server is not, it may 
+   propose a subkey in the AP reply without first being sent a subkey 
+   in the authenticator. 
+ 
+8. GSSAPI Kerberos V5 Mechanism Type  
+ 
+8.1 Mechanism Specific Changes 
+    
+   The GSSAPI per-message tokens also require new checksum and 
+   encryption types. The GSS-API per-message tokens must be changed to 
+   support these new encryption types (See [5] Section 1.2.2). The 
+   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
+   is: 
+        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
+    
+   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
+        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
+    
+   The only support quality of protection is: 
+        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
+    
+   In addition, when using an RC4 based encryption type, the sequence 
+   number is sent in big-endian rather than little-endian order. 
+    
+   The Windows 2000 implementation also defines new GSSAPI flags in the 
+   initial token passed when initializing a security context. These 
+   flags are passed in the checksum field of the authenticator (See [5] 
+   Section 1.1.1). 
+    
+   GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s 
+   implementation of DCE RPC, which initially expected three legs of 
+   authentication. Setting this flag causes an extra AP reply to be 
+   sent from the client back to the server after receiving the server’s 
+   AP reply. In addition, the context negotiation tokens do not have 
+   GSSAPI framing - they are raw AP message and do not include object 
+   identifiers. 
+        #define GSS_C_DCE_STYLE                 0x1000 
+    
+
+  
+Swift                  Category - Informational                      5 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
+   server that it should only allow the server application to identify 
+   the client by name and ID, but not to impersonate the client. 
+        #define GSS_C_IDENTIFY_FLAG             0x2000 
+         
+   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
+   client wants to be informed of extended error information. In 
+   particular, Windows 2000 status codes may be returned in the data 
+   field of a Kerberos error message. This allows the client to 
+   understand a server failure more precisely. In addition, the server 
+   may return errors to the client that are normally handled at the 
+   application layer in the server, in order to let the client try to 
+   recover. After receiving an error message, the client may attempt to 
+   resubmit an AP request. 
+        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
+    
+   These flags are only used if a client is aware of these conventions 
+   when using the SSPI on the Windows platform, they are not generally 
+   used by default. 
+    
+   When NetBIOS addresses are used in the GSSAPI, they are identified 
+   by the GSS_C_AF_NETBIOS value. This value is defined as: 
+        #define GSS_C_AF_NETBIOS                0x14 
+   NetBios addresses are 16-octet addresses typically composed of 1 to 
                                                                 th
   15 characters, trailing blank (ascii char 20) filled, with a 16  
+   octet of 0x0. 
+    
+8.2 GSSAPI Checksum Type 
+    
+   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
+   the first 8 octets of the checksum are used. The resulting checksum 
+   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
+   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
+    
+        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
+             MIC_seq, MIC_checksum) 
+        { 
+            HMAC (K, SK, 13, K4); 
+            T = 15; 
+            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
+            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
+                                                // 0101 1100 FFFFFFFF 
+            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
+            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
+            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
+            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K5); 
+            }else{ 
+                HMAC (K, &T, 4, K5); 
+  
+Swift                  Category - Informational                      6 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            } 
+            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
+            HMAC(K5, MIT_checksum, 8, K6); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K6, seq_plus_direction, 8, MIC_seq); 
+        } 
+    
+8.3 GSSAPI Encryption Types 
+    
+   There are two encryption types for GSSAPI message tokens, one that 
+   is 128 bits in strength, and one that is 56 bits in strength as 
+   defined in Section 6. 
+    
+   All padding is rounded up to 1 byte. One byte is needed to say that 
+   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
+   padding. See [5] Section 1.2.2.3. 
+    
+   The encryption mechanism used for GSS wrap based messages is as 
+   follow: 
+    
+    
+        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
+              WRAP_seq, WRAP_checksum, edata, edata_len) 
+        { 
+            HMAC (K, SK, 13, K7); 
+            T = 13; 
+            PAD = 1; 
+            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
+            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
+        FFFFFFFF 
+            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
+            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
+            MD5 (T_hdr_conf_msg_pad, 
+                 4 + 8 + 8 + msg_len + 1, 
+                 MD5_of_T_hdr_conf_msg_pad); 
+            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
+            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
+        bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K8); 
+            }else{ 
+                HMAC (K, &T, 4, K8); 
+            } 
+            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
+            HMAC(K8, WRAP_checksum, 8, K9); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+  
+Swift                  Category - Informational                      7 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
+          
+            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
+        of key with 0xF0 
+            T = 0; 
+            if (fRC4_EXP){ 
+                *(DWORD *)(L40+10) = T; 
+                HMAC(K10, L40, 14, K11); 
+                memset(K11+7, 0xAB, 9); 
+            }else{ 
+                HMAC(K10, &T, 4, K11);  
+            } 
+            HMAC(K11, seq_num, 4, K12); 
+            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
+        edata); /* skip T & hdr */ 
+            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
+         } 
+          
+    
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+9. Security Considerations 
+ 
+   Care must be taken in implementing this encryption type because it 
+   uses a stream cipher. If a different IV isn’t used in each direction 
+   when using a session key, the encryption is weak. By using the 
+   sequence number as an IV, this is avoided. 
+    
+10. Acknowledgements 
+    
+   We would like to thank Salil Dangi for the valuable input in 
+   refining the descriptions of the functions and review input. 
+     
+11. References 
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
+      Message Authentication", RFC 2104, February 1997 
+    
+   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
+      Service (V5)", RFC 1510, September 1993 
+ 
+ 
+  
+Swift                  Category - Informational                      8 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+ 
+   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
+      June 1996 
+ 
+   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
+      1992 
+ 
+   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
+      1992 
+ 
+   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
+      Algorithm", Work in Progress. 
+ 
+   9  RC4 is a proprietary encryption algorithm available under license 
+      from RSA Data Security Inc.  For licensing information, contact: 
+       
+         RSA Data Security, Inc. 
+         100 Marine Parkway 
+         Redwood City, CA 94065-1031 
+ 
+   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      04.txt, June 25, 1999 
+ 
+    
+12. Author's Addresses 
+    
+   Mike Swift 
+   Dept. of Computer Science 
+   Sieg Hall 
+   University of Washington 
+   Seattle, WA 98105 
+   Email: mikesw@cs.washington.edu  
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      9 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+    
+13. Full Copyright Statement 
+ 
+   "Copyright (C) The Internet Society (2000). All Rights Reserved. 
+    
+   This document and translations of it may be copied and          
+   furnished to others, and derivative works that comment on or          
+   otherwise explain it or assist in its implementation may be          
+   prepared, copied, published and distributed, in whole or in          
+   part, without restriction of any kind, provided that the above          
+   copyright notice and this paragraph are included on all such          
+   copies and derivative works.  However, this document itself may          
+   not be modified in any way, such as by removing the copyright          
+   notice or references to the Internet Society or other Internet          
+   organizations, except as needed for the purpose of developing          
+   Internet standards in which case the procedures for copyrights          
+   defined in the Internet Standards process must be followed, or          
+   as required to translate it into languages other than English. 
+    
+   The limited permissions granted above are perpetual and will          
+   not be revoked by the Internet Society or its successors or          
+   assigns. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                     10 
+
diff --git a/crypto/heimdal/kadmin/add-random-users.c b/crypto/heimdal/kadmin/add-random-users.c
new file mode 100644
index 000000000000..24cde703cc01
--- /dev/null
+++ b/crypto/heimdal/kadmin/add-random-users.c
@@ -0,0 +1,157 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include "kadmin_locl.h"
+
+RCSID("$Id: add-random-users.c,v 1.2 2000/12/31 07:43:39 assar Exp $");
+
+#define WORDS_FILENAME "/usr/share/dict/words"
+
+#define NUSERS 1000
+
+static unsigned
+read_words (const char *filename, char ***ret_w)
+{
+    unsigned n, alloc;
+    FILE *f;
+    char buf[256];
+    char **w = NULL;
+
+    f = fopen (filename, "r");
+    if (f == NULL)
+	err (1, "cannot open %s", filename);
+    alloc = n = 0;
+    while (fgets (buf, sizeof(buf), f) != NULL) {
+	if (buf[strlen (buf) - 1] == '\n')
+	    buf[strlen (buf) - 1] = '\0';
+	if (n >= alloc) {
+	    alloc += 16;
+	    w = erealloc (w, alloc * sizeof(char **));
+	}
+	w[n++] = estrdup (buf);
+    }
+    *ret_w = w;
+    return n;
+}
+
+static void
+add_user (krb5_context context, void *kadm_handle,
+	  unsigned nwords, char **words)
+{
+    kadm5_principal_ent_rec princ;
+    char name[64];
+    int r1, r2;
+    krb5_error_code ret;
+    int mask;
+
+    r1 = rand();
+    r2 = rand();
+
+    snprintf (name, sizeof(name), "%s%d", words[r1 % nwords], r2 % 1000);
+
+    mask = KADM5_PRINCIPAL;
+
+    memset(&princ, 0, sizeof(princ));
+    ret = krb5_parse_name(context, name, &princ.principal);
+    if (ret)
+	krb5_err(context, 1, ret, "krb5_parse_name");
+
+    ret = kadm5_create_principal (kadm_handle, &princ, mask, name);
+    if (ret)
+	krb5_err (context, 1, ret, "kadm5_create_principal");
+    kadm5_free_principal_ent(kadm_handle, &princ);
+    printf ("%s\n", name);
+}
+
+static void
+add_users (unsigned n)
+{
+    krb5_error_code ret;
+    int i;
+    void *kadm_handle;
+    krb5_context context;
+    unsigned nwords;
+    char **words;
+
+    ret = krb5_init_context(&context);
+    if (ret)
+	errx (1, "krb5_init_context failed: %d", ret);
+    ret = kadm5_s_init_with_password_ctx(context, 
+					 KADM5_ADMIN_SERVICE,
+					 NULL,
+					 KADM5_ADMIN_SERVICE,
+					 NULL, 0, 0, 
+					 &kadm_handle);
+    if(ret)
+	krb5_err(context, 1, ret, "kadm5_init_with_password");
+
+    nwords = read_words (WORDS_FILENAME, &words);
+    
+    for (i = 0; i < n; ++i)
+	add_user (context, kadm_handle, nwords, words);
+    kadm5_destroy(kadm_handle);
+    krb5_free_context(context);
+}
+
+static int version_flag	= 0;
+static int help_flag	= 0;
+
+static struct getargs args[] = {
+    { "version", 	0,   arg_flag, &version_flag },
+    { "help",		0,   arg_flag, &help_flag }
+};
+
+static void
+usage (int ret)
+{
+    arg_printusage (args,
+		    sizeof(args)/sizeof(*args),
+		    NULL,
+		    NULL);
+    exit (ret);
+}
+
+int
+main(int argc, char **argv)
+{
+    int optind = 0;
+
+    set_progname(argv[0]);
+    if(getarg(args, sizeof(args) / sizeof(args[0]), argc, argv, &optind))
+	usage(1);
+    if (help_flag)
+	usage (0);
+    srand (0);
+    add_users (NUSERS);
+    return 0;
+}
diff --git a/crypto/heimdal/kadmin/kadm_conn.c b/crypto/heimdal/kadmin/kadm_conn.c
new file mode 100644
index 000000000000..28bf1779d2ed
--- /dev/null
+++ b/crypto/heimdal/kadmin/kadm_conn.c
@@ -0,0 +1,288 @@
+/*
+ * Copyright (c) 2000 - 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 "kadmin_locl.h"
+#ifdef HAVE_SYS_WAIT_H
+#include <sys/wait.h>
+#endif
+
+RCSID("$Id: kadm_conn.c,v 1.11 2001/01/29 08:43:01 assar Exp $");
+
+struct kadm_port {
+    char *port;
+    unsigned short def_port;
+    struct kadm_port *next;
+} *kadm_ports;
+
+static void
+add_kadm_port(krb5_context context, const char *service, unsigned int port)
+{
+    struct kadm_port *p;
+    p = malloc(sizeof(*p));
+    if(p == NULL) {
+	krb5_warnx(context, "failed to allocate %lu bytes\n", 
+		   (unsigned long)sizeof(*p));
+	return;
+    }
+    
+    p->port = strdup(service);
+    p->def_port = port;
+
+    p->next = kadm_ports;
+    kadm_ports = p;
+}
+
+static void
+add_standard_ports (krb5_context context)
+{
+    add_kadm_port(context, "kerberos-adm", 749);
+#ifdef KRB4
+    add_kadm_port(context, "kerberos-master", 751);
+#endif
+}
+
+/*
+ * parse the set of space-delimited ports in `str' and add them.
+ * "+" => all the standard ones
+ * otherwise it's port|service[/protocol]
+ */
+
+void
+parse_ports(krb5_context context, const char *str)
+{
+    char p[128];
+
+    while(strsep_copy(&str, " \t", p, sizeof(p)) != -1) {
+	if(strcmp(p, "+") == 0)
+	    add_standard_ports(context);
+	else
+	    add_kadm_port(context, p, 0);
+    }
+}
+
+static pid_t pgrp;
+sig_atomic_t term_flag, doing_useful_work;
+
+static RETSIGTYPE
+sigchld(int sig)
+{
+    int status;
+    waitpid(-1, &status, 0);
+    SIGRETURN(0);
+}
+
+static RETSIGTYPE
+terminate(int sig)
+{
+    if(getpid() == pgrp) {
+	/* parent */
+	term_flag = 1;
+	signal(sig, SIG_IGN);
+	killpg(pgrp, sig);
+    } else {
+	/* child */
+	if(doing_useful_work)
+	    term_flag = 1;
+	else
+	    exit(0);
+    }
+    SIGRETURN(0);
+}
+
+static int
+spawn_child(krb5_context context, int *socks, int num_socks, int this_sock)
+{
+    int e, i;
+    struct sockaddr_storage __ss;
+    struct sockaddr *sa = (struct sockaddr *)&__ss;
+    socklen_t sa_size = sizeof(__ss);
+    int s;
+    pid_t pid;
+    krb5_address addr;
+    char buf[128];
+    size_t buf_len;
+
+    s = accept(socks[this_sock], sa, &sa_size);
+    if(s < 0) {
+	krb5_warn(context, errno, "accept");
+	return 1;
+    }
+    e = krb5_sockaddr2address(sa, &addr);
+    if(e)
+	krb5_warn(context, e, "krb5_sockaddr2address");
+    else {
+	e = krb5_print_address (&addr, buf, sizeof(buf), 
+				&buf_len);
+	if(e) 
+	    krb5_warn(context, e, "krb5_sockaddr2address");
+	else
+	    krb5_warnx(context, "connection from %s", buf);
+	krb5_free_address(context, &addr);
+    }
+    
+    pid = fork();
+    if(pid == 0) {
+	for(i = 0; i < num_socks; i++)
+	    close(socks[i]);
+	dup2(s, STDIN_FILENO);
+	dup2(s, STDOUT_FILENO);
+	if(s != STDIN_FILENO && s != STDOUT_FILENO)
+	    close(s);
+	return 0;
+    } else {
+	close(s);
+    }
+    return 1;
+}
+
+static int
+wait_for_connection(krb5_context context,
+		    int *socks, int num_socks)
+{
+    int i, e;
+    fd_set orig_read_set, read_set;
+    int max_fd = -1;
+    
+    FD_ZERO(&orig_read_set);
+    
+    for(i = 0; i < num_socks; i++) {
+	if (socks[i] >= FD_SETSIZE)
+	    errx (1, "fd too large");
+	FD_SET(socks[i], &orig_read_set);
+	max_fd = max(max_fd, socks[i]);
+    }
+    
+    pgrp = getpid();
+
+    if(setpgid(0, pgrp) < 0)
+	err(1, "setpgid");
+
+    signal(SIGTERM, terminate);
+    signal(SIGINT, terminate);
+    signal(SIGCHLD, sigchld);
+
+    while (term_flag == 0) {
+	read_set = orig_read_set;
+	e = select(max_fd + 1, &read_set, NULL, NULL, NULL);
+	if(e < 0) {
+	    if(errno != EINTR)
+		krb5_warn(context, errno, "select");
+	} else if(e == 0)
+	    krb5_warnx(context, "select returned 0");
+	else {
+	    for(i = 0; i < num_socks; i++) {
+		if(FD_ISSET(socks[i], &read_set))
+		    if(spawn_child(context, socks, num_socks, i) == 0)
+			return 0;
+	    }
+	}
+    }
+    signal(SIGCHLD, SIG_IGN);
+    while(1) {
+	int status;
+	pid_t pid;
+	pid = waitpid(-1, &status, 0);
+	if(pid == -1 && errno == ECHILD)
+	    break;
+    }
+    exit(0);
+}
+
+
+int
+start_server(krb5_context context)
+{
+    int e;
+    struct kadm_port *p;
+
+    int *socks = NULL, *tmp;
+    int num_socks = 0;
+    int i;
+
+    for(p = kadm_ports; p; p = p->next) {
+	struct addrinfo hints, *ai, *ap;
+	char portstr[32];
+	memset (&hints, 0, sizeof(hints));
+	hints.ai_flags    = AI_PASSIVE;
+	hints.ai_socktype = SOCK_STREAM;
+
+	e = getaddrinfo(NULL, p->port, &hints, &ai);
+	if(e) {
+	    snprintf(portstr, sizeof(portstr), "%u", p->def_port);
+	    e = getaddrinfo(NULL, portstr, &hints, &ai);
+	}
+
+	if(e) {
+	    krb5_warn(context, krb5_eai_to_heim_errno(e), "%s", portstr);
+	    continue;
+	}
+	i = 0;
+	for(ap = ai; ap; ap = ap->ai_next) 
+	    i++;
+	tmp = realloc(socks, (num_socks + i) * sizeof(*socks));
+	if(tmp == NULL) {
+	    krb5_warnx(context, "failed to reallocate %lu bytes", 
+		       (unsigned long)(num_socks + i) * sizeof(*socks));
+	    continue;
+	}
+	socks = tmp;
+	for(ap = ai; ap; ap = ap->ai_next) {
+	    int one = 1;
+	    int s = socket(ap->ai_family, ap->ai_socktype, ap->ai_protocol);
+	    if(s < 0) {
+		krb5_warn(context, errno, "socket");
+		continue;
+	    }
+#if defined(SO_REUSEADDR) && defined(HAVE_SETSOCKOPT)
+	    if(setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (void *)&one,
+			  sizeof(one)) < 0)
+		krb5_warn(context, errno, "setsockopt");
+#endif
+	    if (bind (s, ap->ai_addr, ap->ai_addrlen) < 0) {
+		krb5_warn(context, errno, "bind");
+		close(s);
+		continue;
+	    }
+	    if (listen (s, SOMAXCONN) < 0) {
+		krb5_warn(context, errno, "listen");
+		close(s);
+		continue;
+	    }
+	    socks[num_socks++] = s;
+	}
+	freeaddrinfo (ai);
+    }
+    if(num_socks == 0)
+	krb5_errx(context, 1, "no sockets to listen to - exiting");
+    return wait_for_connection(context, socks, num_socks);
+}
diff --git a/crypto/heimdal/kadmin/kadmin.8 b/crypto/heimdal/kadmin/kadmin.8
new file mode 100644
index 000000000000..bfb4cfc27a66
--- /dev/null
+++ b/crypto/heimdal/kadmin/kadmin.8
@@ -0,0 +1,239 @@
+.\" $Id: kadmin.8,v 1.2 2000/09/19 12:29:48 assar Exp $
+.\"
+.Dd September 10, 2000
+.Dt KADMIN 8
+.Os HEIMDAL
+.Sh NAME
+.Nm kadmin
+.Nd
+Kerberos administration utility
+.Sh SYNOPSIS
+.Nm
+.Oo Fl p Ar string \*(Ba Xo
+.Fl -principal= Ns Ar string Oc
+.Xc
+.Oo Fl c Ar file \*(Ba Xo
+.Fl -config-file= Ns Ar file Oc
+.Xc
+.Oo Fl k Ar file \*(Ba Xo
+.Fl -key-file= Ns Ar file Oc
+.Xc
+.Oo Fl r Ar realm \*(Ba Xo
+.Fl -realm= Ns Ar realm Oc
+.Xc
+.Oo Fl a Ar host \*(Ba Xo
+.Fl -admin-server= Ns Ar host Oc
+.Xc
+.Oo Fl s Ar port number \*(Ba Xo
+.Fl -server-port= Ns Ar port number Oc
+.Xc
+.Op Fl l | Fl -local
+.Op Fl h | Fl -help
+.Op Fl v | Fl -version
+.Op Ar command
+.Sh DESCRIPTION
+The
+.Nm
+program is used to make modification to the Kerberos database, either remotely via the 
+.Xr kadmind 8
+daemon, or locally (with the 
+.Fl l 
+option).
+.Pp
+Supported options:
+.Bl -tag -width Ds
+.It Xo
+.Fl p Ar string Ns ,
+.Fl -principal= Ns Ar string
+.Xc
+principal to authenticate as
+.It Xo
+.Fl c Ar file Ns ,
+.Fl -config-file= Ns Ar file
+.Xc
+location of config file
+.It Xo
+.Fl k Ar file Ns ,
+.Fl -key-file= Ns Ar file
+.Xc
+location of master key file
+.It Xo
+.Fl r Ar realm Ns ,
+.Fl -realm= Ns Ar realm
+.Xc
+realm to use
+.It Xo
+.Fl a Ar host Ns ,
+.Fl -admin-server= Ns Ar host
+.Xc
+server to contact
+.It Xo
+.Fl s Ar port number Ns ,
+.Fl -server-port= Ns Ar port number
+.Xc
+port to use
+.It Xo
+.Fl l Ns ,
+.Fl -local
+.Xc
+local admin mode
+.El
+.Pp
+If no 
+.Ar command
+is given on the command line,
+.Nm 
+will prompt for commands to process. Commands include:
+.\" not using a list here, since groff apparently gets confused 
+.\" with nested Xo/Xc
+.Bd -ragged -offset indent
+.Nm add
+.Op Fl r | Fl -random-key
+.Op Fl -random-password
+.Oo Fl p Ar string \*(Ba Xo
+.Fl -password= Ns Ar string Oc
+.Xc
+.Op Fl -key= Ns Ar string
+.Op Fl -max-ticket-life= Ns Ar lifetime
+.Op Fl -max-renewable-life= Ns Ar lifetime
+.Op Fl -attributes= Ns Ar attributes
+.Op Fl -expiration-time= Ns Ar time
+.Op Fl -pw-expiration-time= Ns Ar time
+.Ar principal...
+.Pp
+.Bd -filled -offset indent
+creates a new principal
+.Ed
+.Pp
+.Nm passwd
+.Op Fl r | Fl -random-key
+.Op Fl -random-password
+.Oo Fl p Ar string \*(Ba Xo
+.Fl -password= Ns Ar string Oc
+.Xc
+.Op Fl -key= Ns Ar string
+.Ar principal...
+.Pp
+.Bd -filled -offset indent
+changes the password of an existing principal
+.Ed
+.Pp
+.Nm delete
+.Ar principal...
+.Pp
+.Bd -filled -offset indent
+removes a principal
+.Ed
+.Pp
+.Nm del_enctype
+.Ar principal enctypes...
+.Pp
+.Bd -filled -offset indent
+removes some enctypes from a principal, this can be useful the service
+belonging to the principal is known to not handle certain enctypes
+.Ed
+.Pp
+.Nm ext_keytab
+.Oo Fl k Ar string \*(Ba Xo
+.Fl -keytab= Ns Ar string Oc
+.Xc
+.Ar principal...
+.Pp
+.Bd -filled -offset indent
+creates a keytab with the keys of the specified principals
+.Ed
+.Pp
+.Nm get
+.Op Fl l | Fl -long
+.Op Fl s | Fl -short
+.Op Fl t | Fl -terse
+.Ar expression...
+.Pp
+.Bd -filled -offset indent
+lists the principals that match the expressions (which are shell glob
+like), long format gives more information, and terse just prints the
+names
+.Ed
+.Pp
+.Nm rename
+.Ar from to
+.Pp
+.Bd -filled -offset indent
+renames a principal
+.Ed
+.Pp
+.Nm modify
+.Oo Fl a Ar attributes \*(Ba Xo
+.Fl -attributes= Ns Ar attributes Oc
+.Xc
+.Op Fl -max-ticket-life= Ns Ar lifetime
+.Op Fl -max-renewable-life= Ns Ar lifetime
+.Op Fl -expiration-time= Ns Ar time
+.Op Fl -pw-expiration-time= Ns Ar time
+.Op Fl -kvno= Ns Ar number
+.Ar principal
+.Pp
+.Bd -filled -offset indent
+modifies certain attributes of a principal
+.Ed
+.Pp
+.Nm privileges
+.Pp
+.Bd -filled -offset indent
+lists the operations you are allowd to perform
+.Ed
+.Pp
+.Ed
+
+When running in local mode, the following commands can also be used.
+
+.Bd -ragged -offset indent
+.Nm dump
+.Op Fl d | Fl -decrypt
+.Op Ar dump-file
+.Pp
+.Bd -filled -offset indent
+writes the database in
+.Dq human readable
+form to the specified file, or standard out
+.Ed
+.Pp
+.Nm init
+.Op Fl -realm-max-ticket-life= Ns Ar string
+.Op Fl -realm-max-renewable-life= Ns Ar string
+.Ar realm
+.Pp
+.Bd -filled -offset indent
+initialises the Kerberos database with entries for a new realm, it's
+possible to have more than one realm served by one server
+.Ed
+.Pp
+.Nm load
+.Ar file
+.Pp
+.Bd -filled -offset indent
+reads a previously dumped database, and re-creates that database from scratch
+.Ed
+.Pp
+.Nm merge
+.Ar file
+.Pp
+.Bd -filled -offset indent
+similar to 
+.Nm list
+but just modifies the database with the entries in the dump file
+.Ed
+.Pp
+.Ed
+
+.\".Sh ENVIRONMENT
+.\".Sh FILES
+.\".Sh EXAMPLES
+.\".Sh DIAGNOSTICS
+.Sh SEE ALSO
+.Xr kadmind 8 ,
+.Xr kdc 8
+.\".Sh STANDARDS
+.\".Sh HISTORY
+.\".Sh AUTHORS
+.\".Sh BUGS
diff --git a/crypto/heimdal/kadmin/kadmind.8 b/crypto/heimdal/kadmin/kadmind.8
new file mode 100644
index 000000000000..67d5c9b5bac6
--- /dev/null
+++ b/crypto/heimdal/kadmin/kadmind.8
@@ -0,0 +1,133 @@
+.Dd June  7, 2000
+.Dt KADMIND 8
+.Os HEIMDAL
+.Sh NAME
+.Nm kadmind
+.Nd
+server for administrative access to kerberos database
+.Sh SYNOPSIS
+.Nm
+.Oo Fl c Ar file \*(Ba Xo
+.Fl -config-file= Ns Ar file Oc
+.Xc
+.Oo Fl k Ar file \*(Ba Xo
+.Fl -key-file= Ns Ar file Oc
+.Xc
+.Op Fl -keytab= Ns Ar keytab
+.Oo Fl r Ar realm \*(Ba Xo
+.Fl -realm= Ns Ar realm Oc
+.Xc
+.Op Fl d | Fl -debug
+.Oo Fl p Ar port \*(Ba Xo
+.Fl -ports= Ns Ar port Oc
+.Xc
+.Sh DESCRIPTION
+.Nm
+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 
+.Xr inetd 8 ,
+otherwise it behaves as a daemon, forking processes for each new
+connection. The 
+.Fl -debug
+option causes 
+.Nm
+to accept exactly one connection, which is useful for debugging. 
+
+If built with krb4 support, it implements both the Heimdal Kerberos 5
+administrative protocol and the Kerberos 4 protocol. Password changes
+via the Kerberos 4 protocol are also performed by
+.Nm kadmind ,
+but the
+.Xr kpasswdd 8 
+daemon is responsible for the Kerberos 5 password changing protocol
+(used by
+.Xr kpasswd 1 ).
+.Pp
+This daemon should only be run on ther master server, and not on any
+slaves.
+.Pp
+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
+.Pa /var/heimdal/kadmind.acl .
+The format of this file is:
+.Bd -ragged
+.Va principal
+.Va rights
+.Op Va principal-pattern
+.Ed
+.Pp
+Where rights is any combination of:
+.Bl -bullet
+.It
+change-password | cpw
+.It
+list
+.It
+delete
+.It
+modify
+.It
+add
+.It
+get
+.It
+all
+.El
+.Pp
+And the optional
+.Ar principal-pattern
+restricts the rights to principals that match the glob-style pattern.
+.Pp
+Supported options:
+.Bl -tag -width Ds
+.It Xo
+.Fl c Ar file Ns ,
+.Fl -config-file= Ns Ar file
+.Xc
+location of config file
+.It Xo
+.Fl k Ar file Ns ,
+.Fl -key-file= Ns Ar file
+.Xc
+location of master key file
+.It Xo
+.Fl -keytab= Ns Ar keytab
+.Xc
+what keytab to use
+.It Xo
+.Fl r Ar realm Ns ,
+.Fl -realm= Ns Ar realm
+.Xc
+realm to use
+.It Xo
+.Fl d Ns ,
+.Fl -debug
+.Xc
+enable debugging
+.It Xo
+.Fl p Ar port Ns ,
+.Fl -ports= Ns Ar port
+.Xc
+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 special string 
+.Dq +
+representing the default set of ports.
+.El
+.\".Sh ENVIRONMENT
+.Sh FILES
+.Pa /var/heimdal/kadmind.acl
+.Sh EXAMPLES
+This will cause kadmind to listen to port 4711 in addition to any
+compiled in defaults:
+.Bd -literal -offset indent
+# kadmind --ports="+ 4711" &
+.Ed
+.\".Sh DIAGNOSTICS
+.Sh SEE ALSO
+.Xr kdc 8 ,
+.Xr kadmin 1 ,
+.Xr kpasswdd 8 ,
+.Xr kpasswd 1
diff --git a/crypto/heimdal/kdc/mit_dump.c b/crypto/heimdal/kdc/mit_dump.c
new file mode 100644
index 000000000000..336d26579175
--- /dev/null
+++ b/crypto/heimdal/kdc/mit_dump.c
@@ -0,0 +1,370 @@
+/*
+ * Copyright (c) 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.
+ */
+
+#include "hprop.h"
+
+RCSID("$Id: mit_dump.c,v 1.3 2000/08/09 09:57:37 joda Exp $");
+
+/*
+can have any number of princ stanzas.
+format is as follows (only \n indicates newlines)
+princ\t%d\t (%d is KRB5_KDB_V1_BASE_LENGTH, always 38)
+%d\t (strlen of principal e.g. shadow/foo@ANDREW.CMU.EDU)
+%d\t (number of tl_data)
+%d\t (number of key data, e.g. how many keys for this user)
+%d\t (extra data length) 
+%s\t (principal name)
+%d\t (attributes)
+%d\t (max lifetime, seconds)
+%d\t (max renewable life, seconds)
+%d\t (expiration, seconds since epoch or 2145830400 for never)
+%d\t (password expiration, seconds, 0 for never) 
+%d\t (last successful auth, seconds since epoch)
+%d\t (last failed auth, per above)
+%d\t (failed auth count)
+foreach tl_data 0 to number of tl_data - 1 as above
+  %d\t%d\t (data type, data length)
+  foreach tl_data 0 to length-1
+    %02x (tl data contents[element n])
+  except if tl_data length is 0
+    %d (always -1)
+  \t
+foreach key 0 to number of keys - 1 as above
+  %d\t%d\t (key data version, kvno)
+  foreach version 0 to key data version - 1 (a key or a salt)
+    %d\t%d\t(data type for this key, data length for this key)
+    foreach key data length 0 to length-1
+      %02x (key data contents[element n])
+    except if key_data length is 0
+      %d (always -1)
+    \t    
+foreach extra data length 0 to length - 1
+  %02x (extra data part)
+unless no extra data
+  %d (always -1)
+;\n
+
+*/
+
+static int
+hex_to_octet_string(const char *ptr, krb5_data *data)
+{
+    int i;
+    unsigned int v;
+    for(i = 0; i < data->length; i++) {
+	if(sscanf(ptr + 2 * i, "%02x", &v) != 1)
+	    return -1;
+	((unsigned char*)data->data)[i] = v;
+    }
+    return 2 * i;
+}
+
+static char *
+nexttoken(char **p)
+{
+    char *q;
+    do {
+	q = strsep(p, " \t");
+    } while(q && *q == '\0');
+    return q;
+}
+
+static size_t
+getdata(char **p, unsigned char *buf, size_t len)
+{
+    size_t i;
+    int v;
+    char *q = nexttoken(p);
+    i = 0;
+    while(*q && i < len) {
+	if(sscanf(q, "%02x", &v) != 1)
+	    break;
+	buf[i++] = v;
+	q += 2;
+    }
+    return i;
+}
+
+static int
+getint(char **p)
+{
+    int val;
+    char *q = nexttoken(p);
+    sscanf(q, "%d", &val);
+    return val;
+}
+
+#include <kadm5/admin.h>
+
+static void
+attr_to_flags(unsigned attr, HDBFlags *flags)
+{
+    flags->postdate =		!(attr & KRB5_KDB_DISALLOW_POSTDATED);
+    flags->forwardable =	!(attr & KRB5_KDB_DISALLOW_FORWARDABLE);
+    flags->initial =	       !!(attr & KRB5_KDB_DISALLOW_TGT_BASED);
+    flags->renewable =		!(attr & KRB5_KDB_DISALLOW_RENEWABLE);
+    flags->proxiable =		!(attr & KRB5_KDB_DISALLOW_PROXIABLE);
+    /* DUP_SKEY */
+    flags->invalid =	       !!(attr & KRB5_KDB_DISALLOW_ALL_TIX);
+    flags->require_preauth =   !!(attr & KRB5_KDB_REQUIRES_PRE_AUTH);
+    /* HW_AUTH */
+    flags->server =		!(attr & KRB5_KDB_DISALLOW_SVR);
+    flags->change_pw = 	       !!(attr & KRB5_KDB_PWCHANGE_SERVICE);
+    flags->client =	        1; /* XXX */
+}
+
+#define KRB5_KDB_SALTTYPE_NORMAL	0
+#define KRB5_KDB_SALTTYPE_V4		1
+#define KRB5_KDB_SALTTYPE_NOREALM	2
+#define KRB5_KDB_SALTTYPE_ONLYREALM	3
+#define KRB5_KDB_SALTTYPE_SPECIAL	4
+#define KRB5_KDB_SALTTYPE_AFS3		5
+
+static krb5_error_code
+fix_salt(krb5_context context, hdb_entry *ent, int key_num)
+{
+    krb5_error_code ret;
+    Salt *salt = ent->keys.val[key_num].salt;
+    /* fix salt type */
+    switch((int)salt->type) {
+    case KRB5_KDB_SALTTYPE_NORMAL:
+	salt->type = KRB5_PADATA_PW_SALT;
+	break;
+    case KRB5_KDB_SALTTYPE_V4:
+	krb5_data_free(&salt->salt);
+	salt->type = KRB5_PADATA_PW_SALT;
+	break;
+    case KRB5_KDB_SALTTYPE_NOREALM:
+    {
+	size_t len;
+	int i;
+	krb5_error_code ret;
+	char *p;
+	    
+	len = 0;
+	for (i = 0; i < ent->principal->name.name_string.len; ++i)
+	    len += strlen(ent->principal->name.name_string.val[i]);
+	ret = krb5_data_alloc (&salt->salt, len);
+	if (ret)
+	    return ret;
+	p = salt->salt.data;
+	for (i = 0; i < ent->principal->name.name_string.len; ++i) {
+	    memcpy (p,
+		    ent->principal->name.name_string.val[i],
+		    strlen(ent->principal->name.name_string.val[i]));
+	    p += strlen(ent->principal->name.name_string.val[i]);
+	}
+
+	salt->type = KRB5_PADATA_PW_SALT;
+	break;
+    }
+    case KRB5_KDB_SALTTYPE_ONLYREALM:
+	krb5_data_free(&salt->salt);
+	ret = krb5_data_copy(&salt->salt, 
+			     ent->principal->realm, 
+			     strlen(ent->principal->realm));
+	if(ret)
+	    return ret;
+	salt->type = KRB5_PADATA_PW_SALT;
+	break;
+    case KRB5_KDB_SALTTYPE_SPECIAL:
+	salt->type = KRB5_PADATA_PW_SALT;
+	break;
+    case KRB5_KDB_SALTTYPE_AFS3:
+	krb5_data_free(&salt->salt);
+	ret = krb5_data_copy(&salt->salt, 
+		       ent->principal->realm, 
+		       strlen(ent->principal->realm));
+	if(ret)
+	    return ret;
+	salt->type = KRB5_PADATA_AFS3_SALT;
+	break;
+    default:
+	abort();
+    }
+    return 0;
+}
+
+int
+mit_prop_dump(void *arg, const char *file)
+{
+    krb5_error_code ret;
+    char buf [1024];
+    FILE *f;
+    int lineno = 0;
+    struct hdb_entry ent;
+
+    struct prop_data *pd = arg;
+
+    f = fopen(file, "r");
+    if(f == NULL)
+	return errno;
+    
+    while(fgets(buf, sizeof(buf), f)) {
+	char *p = buf, *q;
+
+	int i;
+
+	int num_tl_data;
+	int num_key_data;
+	int extra_data_length;
+	int attributes;
+
+	int tmp;
+
+	lineno++;
+
+	memset(&ent, 0, sizeof(ent));
+
+	q = nexttoken(&p);
+	if(strcmp(q, "kdb5_util") == 0) {
+	    int major;
+	    q = nexttoken(&p); /* load_dump */
+	    if(strcmp(q, "load_dump"))
+		errx(1, "line %d: unknown version", lineno);
+	    q = nexttoken(&p); /* load_dump */
+	    if(strcmp(q, "version"))
+		errx(1, "line %d: unknown version", lineno);
+	    q = nexttoken(&p); /* x.0 */
+	    if(sscanf(q, "%d", &major) != 1)
+		errx(1, "line %d: unknown version", lineno);
+	    if(major != 4)
+		errx(1, "unknown dump file format, got %d, expected 4", major);
+	    continue;
+	} else if(strcmp(q, "princ") != 0) {
+	    warnx("line %d: not a principal", lineno);
+	    continue;
+	}
+	tmp = getint(&p);
+	if(tmp != 38) {
+	    warnx("line %d: bad base length %d != 38", lineno, tmp);
+	    continue;
+	}
+	q = nexttoken(&p); /* length of principal */
+	num_tl_data = getint(&p); /* number of tl-data */
+	num_key_data = getint(&p); /* number of key-data */
+	extra_data_length = getint(&p);  /* length of extra data */
+	q = nexttoken(&p); /* principal name */
+	krb5_parse_name(pd->context, q, &ent.principal);
+	attributes = getint(&p); /* attributes */
+	attr_to_flags(attributes, &ent.flags);
+	tmp = getint(&p); /* max life */
+	if(tmp != 0) {
+	    ALLOC(ent.max_life);
+	    *ent.max_life = tmp;
+	}
+	tmp = getint(&p); /* max renewable life */
+	if(tmp != 0) {
+	    ALLOC(ent.max_renew);
+	    *ent.max_renew = tmp;
+	}
+	tmp = getint(&p); /* expiration */
+	if(tmp != 0 && tmp != 2145830400) {
+	    ALLOC(ent.valid_end);
+	    *ent.valid_end = tmp;
+	}
+	tmp = getint(&p); /* pw expiration */
+	if(tmp != 0) {
+	    ALLOC(ent.pw_end);
+	    *ent.pw_end = tmp;
+	}
+	q = nexttoken(&p); /* last auth */
+	q = nexttoken(&p); /* last failed auth */
+	q = nexttoken(&p); /* fail auth count */
+	for(i = 0; i < num_tl_data; i++) {
+	    unsigned long val;
+	    int tl_type, tl_length;
+	    unsigned char *buf;
+	    krb5_principal princ;
+
+	    tl_type = getint(&p); /* data type */
+	    tl_length = getint(&p); /* data length */
+
+#define KRB5_TL_LAST_PWD_CHANGE	1
+#define KRB5_TL_MOD_PRINC	2
+	    switch(tl_type) {
+	    case KRB5_TL_MOD_PRINC:
+		buf = malloc(tl_length);
+		getdata(&p, buf, tl_length); /* data itself */
+		val = buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
+		ret = krb5_parse_name(pd->context, buf + 4, &princ);
+		free(buf);
+		ALLOC(ent.modified_by);
+		ent.modified_by->time = val;
+		ent.modified_by->principal = princ;
+		break;
+	    default:
+		nexttoken(&p);
+		break;
+	    }
+	}
+	ALLOC_SEQ(&ent.keys, num_key_data);
+	for(i = 0; i < num_key_data; i++) {
+	    int key_versions;
+	    key_versions = getint(&p); /* key data version */
+	    ent.kvno = getint(&p); /* XXX kvno */
+	    
+	    ALLOC(ent.keys.val[i].mkvno);
+	    *ent.keys.val[i].mkvno = 0;
+	    
+	    /* key version 0 -- actual key */
+	    ent.keys.val[i].key.keytype = getint(&p); /* key type */
+	    tmp = getint(&p); /* key length */
+	    /* the first two bytes of the key is the key length --
+	       skip it */
+	    krb5_data_alloc(&ent.keys.val[i].key.keyvalue, tmp - 2);
+	    q = nexttoken(&p); /* key itself */
+	    hex_to_octet_string(q + 4, &ent.keys.val[i].key.keyvalue);
+
+	    if(key_versions > 1) {
+		/* key version 1 -- optional salt */
+		ALLOC(ent.keys.val[i].salt);
+		ent.keys.val[i].salt->type = getint(&p); /* salt type */
+		tmp = getint(&p); /* salt length */
+		if(tmp > 0) {
+		    krb5_data_alloc(&ent.keys.val[i].salt->salt, tmp - 2);
+		    q = nexttoken(&p); /* salt itself */
+		    hex_to_octet_string(q + 4, &ent.keys.val[i].salt->salt);
+		} else {
+		    ent.keys.val[i].salt->salt.length = 0;
+		    ent.keys.val[i].salt->salt.data = NULL;
+		    tmp = getint(&p);	/* -1, if no data. */
+		}
+		fix_salt(pd->context, &ent, i);
+	    }
+	}
+	q = nexttoken(&p); /* extra data */
+	v5_prop(pd->context, NULL, &ent, arg);
+    }
+    return 0;
+}
diff --git a/crypto/heimdal/kdc/string2key.8 b/crypto/heimdal/kdc/string2key.8
new file mode 100644
index 000000000000..be8b1f65f88d
--- /dev/null
+++ b/crypto/heimdal/kdc/string2key.8
@@ -0,0 +1,76 @@
+.\" $Id: string2key.8,v 1.2 2000/03/04 14:02:55 assar Exp $
+.\"
+.Dd March  4, 2000
+.Dt STRING2KEY 8
+.Os HEIMDAL
+.Sh NAME
+.Nm string2key
+.Nd
+map a password into a key
+.Sh SYNOPSIS
+.Nm
+.Op Fl 5 | Fl -version5
+.Op Fl 4 | Fl -version4
+.Op Fl a | Fl -afs
+.Oo Fl c Ar cell \*(Ba Xo
+.Fl -cell= Ns Ar cell Oc
+.Xc
+.Oo Fl w Ar password \*(Ba Xo
+.Fl -password= Ns Ar password Oc
+.Xc
+.Oo Fl p Ar principal \*(Ba Xo
+.Fl -principal= Ns Ar principal Oc
+.Xc
+.Oo Fl k Ar string \*(Ba Xo
+.Fl -keytype= Ns Ar string Oc
+.Xc
+.Ar password
+.Sh DESCRIPTION
+.Nm
+performs the string-to-key function.
+This is useful when you want to handle the raw key instead of the password.
+Supported options:
+.Bl -tag -width Ds
+.It Xo
+.Fl 5 Ns ,
+.Fl -version5
+.Xc
+Output Kerberos v5 string-to-key
+.It Xo
+.Fl 4 Ns ,
+.Fl -version4
+.Xc
+Output Kerberos v4 string-to-key
+.It Xo
+.Fl a Ns ,
+.Fl -afs
+.Xc
+Output AFS string-to-key
+.It Xo
+.Fl c Ar cell Ns ,
+.Fl -cell= Ns Ar cell
+.Xc
+AFS cell to use
+.It Xo
+.Fl w Ar password Ns ,
+.Fl -password= Ns Ar password
+.Xc
+Password to use
+.It Xo
+.Fl p Ar principal Ns ,
+.Fl -principal= Ns Ar principal
+.Xc
+Kerberos v5 principal to use
+.It Xo
+.Fl k Ar string Ns ,
+.Fl -keytype= Ns Ar string
+.Xc
+Keytype
+.It Xo
+.Fl -version
+.Xc
+print version
+.It Xo
+.Fl -help
+.Xc
+.El
diff --git a/crypto/heimdal/kdc/v4_dump.c b/crypto/heimdal/kdc/v4_dump.c
new file mode 100644
index 000000000000..dc0a8f20d439
--- /dev/null
+++ b/crypto/heimdal/kdc/v4_dump.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (c) 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.
+ */
+
+#include "hprop.h"
+
+RCSID("$Id: v4_dump.c,v 1.4 2001/01/26 15:55:07 joda Exp $");
+
+static time_t
+time_parse(const char *cp)
+{
+    char wbuf[5];
+    struct tm tp;
+    int local;
+
+    memset(&tp, 0, sizeof(tp));	/* clear out the struct */
+    
+    /* new format is YYYYMMDDHHMM UTC,
+       old format is YYMMDDHHMM local time */
+    if (strlen(cp) > 10) {		/* new format */
+	strlcpy(wbuf, cp, sizeof(wbuf));
+	tp.tm_year = atoi(wbuf) - 1900;
+	cp += 4;
+	local = 0;
+    } else {
+	wbuf[0] = *cp++;
+	wbuf[1] = *cp++;
+	wbuf[2] = '\0';
+	tp.tm_year = atoi(wbuf);
+	if(tp.tm_year < 38)
+	    tp.tm_year += 100;
+	local = 1;
+    }
+
+    wbuf[0] = *cp++;
+    wbuf[1] = *cp++;
+    wbuf[2] = 0;
+    tp.tm_mon = atoi(wbuf) - 1;
+
+    wbuf[0] = *cp++;
+    wbuf[1] = *cp++;
+    tp.tm_mday = atoi(wbuf);
+    
+    wbuf[0] = *cp++;
+    wbuf[1] = *cp++;
+    tp.tm_hour = atoi(wbuf);
+    
+    wbuf[0] = *cp++;
+    wbuf[1] = *cp++;
+    tp.tm_min = atoi(wbuf);
+    
+    return(tm2time(tp, local));
+}
+
+/* convert a version 4 dump file */
+int
+v4_prop_dump(void *arg, const char *file)
+{
+    char buf [1024];
+    FILE *f;
+    int lineno = 0;
+
+    f = fopen(file, "r");
+    if(f == NULL)
+	return errno;
+    
+    while(fgets(buf, sizeof(buf), f)) {
+	int ret;
+	unsigned long key[2]; /* yes, long */
+	char exp_date[64], mod_date[64];
+	struct v4_principal pr;
+	int attributes;
+    
+	memset(&pr, 0, sizeof(pr));
+	errno = 0;
+	lineno++;
+	ret = sscanf(buf, "%s %s %d %d %d %d %lx %lx %s %s %s %s",
+		     pr.name, pr.instance,
+		     &pr.max_life, &pr.mkvno, &pr.kvno,
+		     &attributes,
+		     &key[0], &key[1],
+		     exp_date, mod_date,
+		     pr.mod_name, pr.mod_instance);
+	if(ret != 12){
+	    warnx("Line %d malformed (ignored)", lineno);
+	    continue;
+	}
+	if(attributes != 0) {
+	    warnx("Line %d (%s.%s) has non-zero attributes - skipping", 
+		  lineno, pr.name, pr.instance);
+	    continue;
+	}
+	pr.key[0] = (key[0] >> 24) & 0xff;
+	pr.key[1] = (key[0] >> 16) & 0xff;
+	pr.key[2] = (key[0] >> 8) & 0xff;
+	pr.key[3] = (key[0] >> 0) & 0xff;
+	pr.key[4] = (key[1] >> 24) & 0xff;
+	pr.key[5] = (key[1] >> 16) & 0xff;
+	pr.key[6] = (key[1] >> 8) & 0xff;
+	pr.key[7] = (key[1] >> 0) & 0xff;
+	pr.exp_date = time_parse(exp_date);
+	pr.mod_date = time_parse(mod_date);
+	if (pr.instance[0] == '*')
+	    pr.instance[0] = '\0';
+	if (pr.mod_name[0] == '*')
+	    pr.mod_name[0] = '\0';
+	if (pr.mod_instance[0] == '*')
+	    pr.mod_instance[0] = '\0';
+	v4_prop(arg, &pr);
+	memset(&pr, 0, sizeof(pr));
+    }
+    return 0;
+}
diff --git a/crypto/heimdal/kpasswd/kpasswd-generator.c b/crypto/heimdal/kpasswd/kpasswd-generator.c
new file mode 100644
index 000000000000..6bd836c98041
--- /dev/null
+++ b/crypto/heimdal/kpasswd/kpasswd-generator.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include "kpasswd_locl.h"
+
+RCSID("$Id: kpasswd-generator.c,v 1.2 2000/12/31 07:47:38 assar Exp $");
+
+static unsigned
+read_words (const char *filename, char ***ret_w)
+{
+    unsigned n, alloc;
+    FILE *f;
+    char buf[256];
+    char **w = NULL;
+
+    f = fopen (filename, "r");
+    if (f == NULL)
+	err (1, "cannot open %s", filename);
+    alloc = n = 0;
+    while (fgets (buf, sizeof(buf), f) != NULL) {
+	if (buf[strlen (buf) - 1] == '\n')
+	    buf[strlen (buf) - 1] = '\0';
+	if (n >= alloc) {
+	    alloc += 16;
+	    w = erealloc (w, alloc * sizeof(char **));
+	}
+	w[n++] = estrdup (buf);
+    }
+    *ret_w = w;
+    return n;
+}
+
+static int
+nop_prompter (krb5_context context,
+	      void *data,
+	      const char *banner,
+	      int num_prompts,
+	      krb5_prompt prompts[])
+{
+    return 0;
+}
+
+static void
+generate_requests (const char *filename, unsigned nreq)
+{
+    krb5_context context;
+    krb5_error_code ret;
+    int i;
+    char **words;
+    unsigned nwords;
+
+    ret = krb5_init_context (&context);
+    if (ret)
+	errx (1, "krb5_init_context failed: %d", ret);
+
+    nwords = read_words (filename, &words);
+
+    for (i = 0; i < nreq; ++i) {
+	char *name = words[rand() % nwords];
+	krb5_get_init_creds_opt opt;
+	krb5_creds cred;
+	krb5_principal principal;
+	int result_code;
+	krb5_data result_code_string, result_string;
+	char *old_pwd, *new_pwd;
+
+	krb5_get_init_creds_opt_init (&opt);
+	krb5_get_init_creds_opt_set_tkt_life (&opt, 300);
+	krb5_get_init_creds_opt_set_forwardable (&opt, FALSE);
+	krb5_get_init_creds_opt_set_proxiable (&opt, FALSE);
+
+	ret = krb5_parse_name (context, name, &principal);
+	if (ret)
+	    krb5_err (context, 1, ret, "krb5_parse_name %s", name);
+
+	asprintf (&old_pwd, "%s", name);
+	asprintf (&new_pwd, "%s2", name);
+
+	ret = krb5_get_init_creds_password (context,
+					    &cred,
+					    principal,
+					    old_pwd,
+					    nop_prompter,
+					    NULL,
+					    0,
+					    "kadmin/changepw",
+					    &opt);
+	if( ret == KRB5KRB_AP_ERR_BAD_INTEGRITY
+	    || ret == KRB5KRB_AP_ERR_MODIFIED) {
+	    char *tmp;
+
+	    tmp = new_pwd;
+	    new_pwd = old_pwd;
+	    old_pwd = tmp;
+
+	    ret = krb5_get_init_creds_password (context,
+						&cred,
+						principal,
+						old_pwd,
+						nop_prompter,
+						NULL,
+						0,
+						"kadmin/changepw",
+						&opt);
+	}
+	if (ret)
+	    krb5_err (context, 1, ret, "krb5_get_init_creds_password");
+
+	krb5_free_principal (context, principal);
+
+	ret = krb5_change_password (context, &cred, new_pwd,
+				    &result_code,
+				    &result_code_string,
+				    &result_string);
+	if (ret)
+	    krb5_err (context, 1, ret, "krb5_change_password");
+
+	free (old_pwd);
+	free (new_pwd);
+	krb5_free_creds_contents (context, &cred);
+    }
+}
+
+static int version_flag	= 0;
+static int help_flag	= 0;
+
+static struct getargs args[] = {
+    { "version", 	0,   arg_flag, &version_flag },
+    { "help",		0,   arg_flag, &help_flag }
+};
+
+static void
+usage (int ret)
+{
+    arg_printusage (args,
+		    sizeof(args)/sizeof(*args),
+		    NULL,
+		    "file [number]");
+    exit (ret);
+}
+
+int
+main(int argc, char **argv)
+{
+    int optind = 0;
+    int nreq;
+    char *end;
+
+    set_progname(argv[0]);
+    if(getarg(args, sizeof(args) / sizeof(args[0]), argc, argv, &optind))
+	usage(1);
+    argc -= optind;
+    argv += optind;
+
+    if (argc != 2)
+	usage (1);
+    srand (0);
+    nreq = strtol (argv[1], &end, 0);
+    if (argv[1] == end || *end != '\0')
+	usage (1);
+    generate_requests (argv[0], nreq);
+    return 0;
+}
diff --git a/crypto/heimdal/kuser/generate-requests.c b/crypto/heimdal/kuser/generate-requests.c
new file mode 100644
index 000000000000..f7f5dd1bbe59
--- /dev/null
+++ b/crypto/heimdal/kuser/generate-requests.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include "kuser_locl.h"
+
+RCSID("$Id: generate-requests.c,v 1.2 2000/12/31 07:49:27 assar Exp $");
+
+static krb5_error_code
+null_key_proc (krb5_context context,
+	       krb5_enctype type,
+	       krb5_salt salt,
+	       krb5_const_pointer keyseed,
+	       krb5_keyblock **key)
+{
+    return ENOTTY;
+}
+
+static unsigned
+read_words (const char *filename, char ***ret_w)
+{
+    unsigned n, alloc;
+    FILE *f;
+    char buf[256];
+    char **w = NULL;
+
+    f = fopen (filename, "r");
+    if (f == NULL)
+	err (1, "cannot open %s", filename);
+    alloc = n = 0;
+    while (fgets (buf, sizeof(buf), f) != NULL) {
+	if (buf[strlen (buf) - 1] == '\n')
+	    buf[strlen (buf) - 1] = '\0';
+	if (n >= alloc) {
+	    alloc += 16;
+	    w = erealloc (w, alloc * sizeof(char **));
+	}
+	w[n++] = estrdup (buf);
+    }
+    *ret_w = w;
+    return n;
+}
+
+static void
+generate_requests (const char *filename, unsigned nreq)
+{
+    krb5_context context;
+    krb5_error_code ret;
+    krb5_creds cred;
+    int i;
+    char **words;
+    unsigned nwords;
+
+    ret = krb5_init_context (&context);
+    if (ret)
+	errx (1, "krb5_init_context failed: %d", ret);
+
+    nwords = read_words (filename, &words);
+
+    for (i = 0; i < nreq; ++i) {
+	char *name = words[rand() % nwords];
+	krb5_realm *client_realm;
+
+	memset(&cred, 0, sizeof(cred));
+
+	ret = krb5_parse_name (context, name, &cred.client);
+	if (ret)
+	    krb5_err (context, 1, ret, "krb5_parse_name %s", name);
+	client_realm = krb5_princ_realm (context, cred.client);
+
+	ret = krb5_make_principal(context, &cred.server, *client_realm,
+				  KRB5_TGS_NAME, *client_realm, NULL);
+	if (ret)
+	    krb5_err (context, 1, ret, "krb5_make_principal");
+
+	ret = krb5_get_in_cred (context, 0, NULL, NULL, NULL, NULL,
+				null_key_proc, NULL, NULL, NULL,
+				&cred, NULL);
+	krb5_free_creds_contents (context, &cred);
+    }
+}
+
+static int version_flag	= 0;
+static int help_flag	= 0;
+
+static struct getargs args[] = {
+    { "version", 	0,   arg_flag, &version_flag },
+    { "help",		0,   arg_flag, &help_flag }
+};
+
+static void
+usage (int ret)
+{
+    arg_printusage (args,
+		    sizeof(args)/sizeof(*args),
+		    NULL,
+		    "file number");
+    exit (ret);
+}
+
+int
+main(int argc, char **argv)
+{
+    int optind = 0;
+    int nreq;
+    char *end;
+
+    set_progname(argv[0]);
+    if(getarg(args, sizeof(args) / sizeof(args[0]), argc, argv, &optind))
+	usage(1);
+    argc -= optind;
+    argv += optind;
+
+    if (argc != 2)
+	usage (1);
+    srand (0);
+    nreq = strtol (argv[1], &end, 0);
+    if (argv[1] == end || *end != '\0')
+	usage (1);
+    generate_requests (argv[0], nreq);
+    return 0;
+}
diff --git a/crypto/heimdal/lib/asn1/asn1-common.h b/crypto/heimdal/lib/asn1/asn1-common.h
new file mode 100644
index 000000000000..d3a30f275680
--- /dev/null
+++ b/crypto/heimdal/lib/asn1/asn1-common.h
@@ -0,0 +1,16 @@
+/* $Id: asn1-common.h,v 1.1 2000/04/14 15:41:31 joda Exp $ */
+
+#include <stddef.h>
+#include <time.h>
+
+#ifndef __asn1_common_definitions__
+#define __asn1_common_definitions__
+
+typedef struct octet_string {
+    size_t length;
+    void *data;
+} octet_string;
+
+typedef char *general_string;
+
+#endif
diff --git a/crypto/heimdal/lib/asn1/pkinit.asn1 b/crypto/heimdal/lib/asn1/pkinit.asn1
new file mode 100644
index 000000000000..92c5de75daac
--- /dev/null
+++ b/crypto/heimdal/lib/asn1/pkinit.asn1
@@ -0,0 +1,189 @@
+PKINIT DEFINITIONS ::= BEGIN
+
+IMPORTS  EncryptionKey, PrincipalName, Realm, KerberosTime, TypedData 
+	FROM krb5;
+IMPORTS SignedData, EnvelopedData FROM CMS;
+IMPORTS CertificateSerialNumber, AttributeTypeAndValue, Name FROM X509;
+
+
+-- 3.1
+
+CertPrincipalName ::= SEQUENCE {
+	name-type[0]		INTEGER,
+	name-string[1]		SEQUENCE OF UTF8String
+}
+
+
+-- 3.2.2
+
+
+TrustedCertifiers ::= SEQUENCE OF PrincipalName
+				-- X.500 name encoded as a principal name
+				-- see Section 3.1
+CertificateIndex  ::= INTEGER
+				-- 0 = 1st certificate,
+				--     (in order of encoding)
+				-- 1 = 2nd certificate, etc
+
+PA-PK-AS-REP ::= CHOICE {
+				-- PA TYPE 15
+	dhSignedData[0]		SignedData,
+				-- Defined in CMS and used only with
+				-- Diffie-Hellman key exchange (if the
+				-- client public value was present in the
+				-- request).
+				-- This choice MUST be supported
+				-- by compliant implementations.
+	encKeyPack[1]		EnvelopedData
+				-- Defined in CMS
+				-- The temporary key is encrypted
+				-- using the client public key
+				-- key
+				-- SignedReplyKeyPack, encrypted
+				-- with the temporary key, is also
+				-- included.
+}
+
+
+
+KdcDHKeyInfo ::= SEQUENCE {
+				-- used only when utilizing Diffie-Hellman
+	nonce[0]		INTEGER,
+				-- binds responce to the request
+	subjectPublicKey[2]	BIT STRING
+				-- Equals public exponent (g^a mod p)
+				-- INTEGER encoded as payload of
+				-- BIT STRING
+}
+
+ReplyKeyPack ::= SEQUENCE {
+				-- not used for Diffie-Hellman
+	replyKey[0]		EncryptionKey,
+				-- used to encrypt main reply
+				-- ENCTYPE is at least as strong as
+				-- ENCTYPE of session key
+	nonce[1]		INTEGER
+				-- binds response to the request
+				-- must be same as the nonce
+				-- passed in the PKAuthenticator
+}
+
+-- subjectAltName EXTENSION ::= {
+-- 	SYNTAX GeneralNames
+-- 	IDENTIFIED BY id-ce-subjectAltName
+-- }
+
+OtherName ::= SEQUENCE {
+	type-id			OBJECT IDENTIFIER,
+	value[0]		OCTET STRING
+--	value[0] EXPLICIT ANY DEFINED BY type-id
+}
+
+GeneralName ::= CHOICE {
+	otherName       [0] OtherName,
+	...
+}
+
+GeneralNames ::= SEQUENCE -- SIZE(1..MAX)
+	OF GeneralName
+
+KerberosName ::= SEQUENCE {
+	realm[0]		Realm,
+				-- as defined in RFC 1510
+	principalName[1]	CertPrincipalName
+				-- defined above
+}
+
+
+-- krb5 OBJECT IDENTIFIER ::= {
+-- 	iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
+-- }
+
+-- krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+-- 3.2.1
+
+
+IssuerAndSerialNumber ::= SEQUENCE {
+	issuer			Name,
+	serialNumber		CertificateSerialNumber
+}
+
+TrustedCas ::= CHOICE {
+	principalName[0]	KerberosName,
+				-- as defined below
+	caName[1]		Name,
+				-- fully qualified X.500 name
+				-- as defined by X.509
+	issuerAndSerial[2]	IssuerAndSerialNumber
+				-- Since a CA may have a number of
+				-- certificates, only one of which
+				-- a client trusts
+}
+
+PA-PK-AS-REQ ::= SEQUENCE {
+	-- PA TYPE 14
+	signedAuthPack[0]	SignedData,
+				-- defined in CMS [11]
+				-- AuthPack (below) defines the data
+				-- that is signed
+	trustedCertifiers[1]	SEQUENCE OF TrustedCas OPTIONAL,
+				-- CAs that the client trusts
+	kdcCert[2]		IssuerAndSerialNumber OPTIONAL,
+				-- as defined in CMS [11]
+				-- specifies a particular KDC
+				-- certificate if the client
+				-- already has it;
+	encryptionCert[3]	IssuerAndSerialNumber OPTIONAL
+				-- For example, this may be the
+				-- client's Diffie-Hellman
+				-- certificate, or it may be the
+				-- client's RSA encryption
+				-- certificate.
+}
+
+PKAuthenticator ::= SEQUENCE {
+	kdcName[0]		PrincipalName,
+	kdcRealm[1]		Realm,
+	cusec[2]		INTEGER,
+				-- for replay prevention as in RFC1510
+	ctime[3]		KerberosTime,
+				-- for replay prevention as in RFC1510
+	nonce[4]		INTEGER
+}
+
+-- This is the real definition of AlgorithmIdentifier
+-- AlgorithmIdentifier ::= SEQUENCE {
+-- 	algorithm		ALGORITHM.&id,
+--	parameters		ALGORITHM.&Type
+-- }   -- as specified by the X.509 recommendation[10]
+
+-- But we'll use this one instead:
+
+AlgorithmIdentifier ::= SEQUENCE {
+	algorithm		OBJECT IDENTIFIER,
+	parameters		CHOICE {
+					a INTEGER
+				}
+}
+
+
+
+SubjectPublicKeyInfo ::= SEQUENCE {
+	algorithm		AlgorithmIdentifier,
+				-- dhKeyAgreement
+	subjectPublicKey	BIT STRING
+				-- for DH, equals
+				-- public exponent (INTEGER encoded
+				-- as payload of BIT STRING)
+} -- as specified by the X.509 recommendation[10]
+
+AuthPack ::= SEQUENCE {
+	pkAuthenticator[0]	PKAuthenticator,
+	clientPublicValue[1]	SubjectPublicKeyInfo OPTIONAL
+				-- if client is using Diffie-Hellman
+				-- (ephemeral-ephemeral only)
+}
+
+
+END
diff --git a/crypto/heimdal/lib/asn1/rfc2459.asn1 b/crypto/heimdal/lib/asn1/rfc2459.asn1
new file mode 100644
index 000000000000..c9adec6093c6
--- /dev/null
+++ b/crypto/heimdal/lib/asn1/rfc2459.asn1
@@ -0,0 +1,21 @@
+RFC2459 DEFINITIONS ::= BEGIN
+
+AttributeType ::= OBJECT-IDENTIFIER
+
+AttributeValue ::= OCTET STRING --ANY DEFINED BY AttributeType
+
+AttributeTypeAndValue ::= SEQUENCE {
+	type AttributeType,
+	value AttributeValue
+}
+
+RelativeDistinguishedName ::= --SET
+SEQUENCE OF AttributeTypeAndValue
+
+RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+Name ::= CHOICE { -- RFC2459
+	x RDNSequence
+}
+
+END
\ No newline at end of file
diff --git a/crypto/heimdal/lib/asn1/x509.asn1 b/crypto/heimdal/lib/asn1/x509.asn1
new file mode 100644
index 000000000000..4a15844c8563
--- /dev/null
+++ b/crypto/heimdal/lib/asn1/x509.asn1
@@ -0,0 +1,23 @@
+X509 DEFINITIONS ::= BEGIN
+
+CertificateSerialNumber ::= INTEGER -- X.509 '97
+
+AttributeType ::= OBJECT-IDENTIFIER
+
+AttributeValue ::= OCTET STRING --ANY DEFINED BY AttributeType
+
+AttributeTypeAndValue ::= SEQUENCE {
+	type AttributeType,
+	value AttributeValue
+}
+
+RelativeDistinguishedName ::= --SET
+SEQUENCE OF AttributeTypeAndValue
+
+RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+Name ::= CHOICE { -- RFC2459
+	x RDNSequence
+}
+
+END
\ No newline at end of file
diff --git a/crypto/heimdal/lib/com_err/ChangeLog b/crypto/heimdal/lib/com_err/ChangeLog
new file mode 100644
index 000000000000..1ca005bce825
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/ChangeLog
@@ -0,0 +1,127 @@
+2000-08-16  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.am: bump version to 1:1:0
+
+2000-07-31  Assar Westerlund  <assar@sics.se>
+
+	* com_right.h (initialize_error_table_r): fix prototype
+
+2000-04-05  Assar Westerlund  <assar@sics.se>
+
+	* com_err.c (_et_lit): explicitly initialize it to NULL to make
+	dyld on Darwin/MacOS X happy
+
+2000-01-16  Assar Westerlund  <assar@sics.se>
+
+	* com_err.h: remove __P definition (now in com_right.h).  this
+	file always includes com_right.h so that's where it should reside.
+	* com_right.h: moved __P here and added it to the function
+	prototypes
+	* com_err.h (error_table_name): add __P
+
+1999-07-03  Assar Westerlund  <assar@sics.se>
+
+	* parse.y (statement): use asprintf
+
+1999-06-13  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.in: make it solaris make vpath-safe
+
+Thu Apr  1 11:13:53 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* compile_et.c: use getargs
+
+Sat Mar 20 00:16:30 1999  Assar Westerlund  <assar@sics.se>
+
+	* compile_et.c: static-ize
+
+Thu Mar 18 11:22:13 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* Makefile.am: include Makefile.am.common
+
+Tue Mar 16 22:30:05 1999  Assar Westerlund  <assar@sics.se>
+
+	* parse.y: use YYACCEPT instead of return
+
+Sat Mar 13 22:22:56 1999  Assar Westerlund  <assar@sics.se>
+
+	* compile_et.c (generate_h): cast when calling is* to get rid of a
+ 	warning
+
+Thu Mar 11 15:00:51 1999  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* parse.y: prototype for error_message
+
+Sun Nov 22 10:39:02 1998  Assar Westerlund  <assar@sics.se>
+
+	* compile_et.h: include ctype and roken
+
+	* compile_et.c: include err.h
+	(generate_h): remove unused variable
+
+	* Makefile.in (WFLAGS): set
+
+Fri Nov 20 06:58:59 1998  Assar Westerlund  <assar@sics.se>
+
+	* lex.l: undef ECHO to work around AIX lex bug
+
+Sun Sep 27 02:23:59 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* com_err.c (error_message): try to pass code to strerror, to see
+ 	if it might be an errno code (this if broken, but some MIT code
+ 	seems to expect this behaviour)
+
+Sat Sep 26 17:42:39 1998  Johan Danielsson  <joda@hella.pdc.kth.se>
+
+	* compile_et.c: <foo_err.h> -> "foo_err.h"
+
+Tue Jun 30 17:17:36 1998  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.in: add str{cpy,cat}_truncate
+
+Mon May 25 05:24:39 1998  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.in (clean): try to remove shared library debris
+
+Sun Apr 19 09:50:17 1998  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.in: add symlink magic for linux
+
+Sun Apr  5 09:22:11 1998  Assar Westerlund  <assar@sics.se>
+
+	* parse.y: define alloca to malloc in case we're using bison but
+ 	don't have alloca
+
+Tue Mar 24 05:13:01 1998  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.in: link with snprintf (From Derrick J Brashear
+ 	<shadow@dementia.org>)
+
+Fri Feb 27 05:01:42 1998  Assar Westerlund  <assar@sics.se>
+
+	* parse.y: initialize ec->next
+
+Thu Feb 26 02:22:25 1998  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.am: @LEXLIB@
+
+Sat Feb 21 15:18:54 1998  assar westerlund  <assar@sics.se>
+
+	* Makefile.in: set YACC and LEX
+
+Tue Feb 17 22:20:27 1998  Bjoern Groenvall  <bg@sics.se>
+
+	* com_right.h: Change typedefs so that one may mix MIT compile_et
+ 	generated code with krb4 dito.
+
+Tue Feb 17 16:30:55 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* compile_et.c (generate): Always return a value.
+
+	* parse.y: Files don't have to end with `end'.
+
+Mon Feb 16 16:09:20 1998  Johan Danielsson  <joda@emma.pdc.kth.se>
+
+	* lex.l (getstring): Replace getc() with input().
+
+	* Makefile.am: Fixes for new compile_et.
diff --git a/crypto/heimdal/lib/com_err/Makefile.am b/crypto/heimdal/lib/com_err/Makefile.am
new file mode 100644
index 000000000000..8e1810801541
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/Makefile.am
@@ -0,0 +1,24 @@
+# $Id: Makefile.am,v 1.24 2000/08/16 11:24:54 assar Exp $
+
+include $(top_srcdir)/Makefile.am.common
+
+YFLAGS = -d
+
+lib_LTLIBRARIES = libcom_err.la
+libcom_err_la_LDFLAGS = -version-info 1:1:0
+
+bin_PROGRAMS = compile_et
+
+include_HEADERS = com_err.h com_right.h
+
+compile_et_SOURCES = compile_et.c compile_et.h parse.y lex.l
+
+libcom_err_la_SOURCES = error.c com_err.c roken_rename.h
+
+CLEANFILES = lex.c parse.c parse.h
+
+$(compile_et_OBJECTS): parse.h
+
+compile_et_LDADD = \
+	$(LIB_roken) \
+	$(LEXLIB)
diff --git a/crypto/heimdal/lib/com_err/Makefile.in b/crypto/heimdal/lib/com_err/Makefile.in
new file mode 100644
index 000000000000..986e078caae3
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/Makefile.in
@@ -0,0 +1,649 @@
+# Makefile.in generated automatically by automake 1.4a from Makefile.am
+
+# Copyright (C) 1994, 1995-9, 2000 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.
+
+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
+
+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@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_FLAG =
+transform = @program_transform_name@
+
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+
+@SET_MAKE@
+host_alias = @host_alias@
+host_triplet = @host@
+AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
+AMDEP = @AMDEP@
+AMTAR = @AMTAR@
+AS = @AS@
+AWK = @AWK@
+CANONICAL_HOST = @CANONICAL_HOST@
+CATMAN = @CATMAN@
+CATMANEXT = @CATMANEXT@
+CC = @CC@
+CPP = @CPP@
+CXX = @CXX@
+CXXCPP = @CXXCPP@
+DBLIB = @DBLIB@
+DEPDIR = @DEPDIR@
+DIR_des = @DIR_des@
+DIR_roken = @DIR_roken@
+DLLTOOL = @DLLTOOL@
+EXEEXT = @EXEEXT@
+EXTRA_LIB45 = @EXTRA_LIB45@
+GROFF = @GROFF@
+INCLUDES_roken = @INCLUDES_roken@
+INCLUDE_ = @INCLUDE_@
+LEX = @LEX@
+LIBOBJS = @LIBOBJS@
+LIBTOOL = @LIBTOOL@
+LIB_ = @LIB_@
+LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
+LIB_des = @LIB_des@
+LIB_des_appl = @LIB_des_appl@
+LIB_kdb = @LIB_kdb@
+LIB_otp = @LIB_otp@
+LIB_roken = @LIB_roken@
+LIB_security = @LIB_security@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAKEINFO = @MAKEINFO@
+NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@
+NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@
+NROFF = @NROFF@
+OBJDUMP = @OBJDUMP@
+OBJEXT = @OBJEXT@
+PACKAGE = @PACKAGE@
+RANLIB = @RANLIB@
+STRIP = @STRIP@
+VERSION = @VERSION@
+VOID_RETSIGTYPE = @VOID_RETSIGTYPE@
+WFLAGS = @WFLAGS@
+WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
+WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
+YACC = @YACC@
+dpagaix_CFLAGS = @dpagaix_CFLAGS@
+dpagaix_LDADD = @dpagaix_LDADD@
+install_sh = @install_sh@
+
+# $Id: Makefile.am,v 1.24 2000/08/16 11:24:54 assar Exp $
+
+
+# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $
+
+
+# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $
+
+
+AUTOMAKE_OPTIONS = foreign no-dependencies
+
+SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x
+
+INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken)
+
+AM_CFLAGS =  $(WFLAGS)
+
+CP = cp
+
+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_pidfile = @LIB_pidfile@
+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@
+
+LIBS = @LIBS@
+
+HESIODLIB = @HESIODLIB@
+HESIODINCLUDE = @HESIODINCLUDE@
+INCLUDE_hesiod = @INCLUDE_hesiod@
+LIB_hesiod = @LIB_hesiod@
+
+INCLUDE_krb4 = @INCLUDE_krb4@
+LIB_krb4 = @LIB_krb4@
+
+INCLUDE_openldap = @INCLUDE_openldap@
+LIB_openldap = @LIB_openldap@
+
+INCLUDE_readline = @INCLUDE_readline@
+
+LEXLIB = @LEXLIB@
+
+NROFF_MAN = groff -mandoc -Tascii
+
+@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
+
+@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
+@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
+@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la
+
+CHECK_LOCAL = $(PROGRAMS)
+
+YFLAGS = -d
+
+lib_LTLIBRARIES = libcom_err.la
+libcom_err_la_LDFLAGS = -version-info 1:1:0
+
+bin_PROGRAMS = compile_et
+
+include_HEADERS = com_err.h com_right.h
+
+compile_et_SOURCES = compile_et.c compile_et.h parse.y lex.l
+
+libcom_err_la_SOURCES = error.c com_err.c roken_rename.h
+
+CLEANFILES = lex.c parse.c parse.h
+
+compile_et_LDADD = \
+	$(LIB_roken) \
+	$(LEXLIB)
+
+subdir = lib/com_err
+mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
+CONFIG_HEADER = ../../include/config.h
+CONFIG_CLEAN_FILES = 
+LTLIBRARIES =  $(lib_LTLIBRARIES)
+
+
+DEFS = @DEFS@ -I. -I$(srcdir) -I../../include
+CPPFLAGS = @CPPFLAGS@
+LDFLAGS = @LDFLAGS@
+X_CFLAGS = @X_CFLAGS@
+X_LIBS = @X_LIBS@
+X_EXTRA_LIBS = @X_EXTRA_LIBS@
+X_PRE_LIBS = @X_PRE_LIBS@
+libcom_err_la_LIBADD = 
+am_libcom_err_la_OBJECTS =  error.lo com_err.lo
+libcom_err_la_OBJECTS =  $(am_libcom_err_la_OBJECTS)
+bin_PROGRAMS =  compile_et$(EXEEXT)
+PROGRAMS =  $(bin_PROGRAMS)
+
+am_compile_et_OBJECTS =  compile_et.$(OBJEXT) parse.$(OBJEXT) \
+lex.$(OBJEXT)
+compile_et_OBJECTS =  $(am_compile_et_OBJECTS)
+compile_et_DEPENDENCIES = 
+compile_et_LDFLAGS = 
+COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+CFLAGS = @CFLAGS@
+LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
+CCLD = $(CC)
+LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
+DIST_SOURCES =  $(libcom_err_la_SOURCES) $(compile_et_SOURCES)
+HEADERS =  $(include_HEADERS)
+
+depcomp = 
+DIST_COMMON =  $(include_HEADERS) ChangeLog Makefile.am Makefile.in \
+lex.c parse.c parse.h
+
+
+DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
+
+GZIP_ENV = --best
+SOURCES = $(libcom_err_la_SOURCES) $(compile_et_SOURCES)
+OBJECTS = $(am_libcom_err_la_OBJECTS) $(am_compile_et_OBJECTS)
+
+all: all-redirect
+.SUFFIXES:
+.SUFFIXES: .1 .3 .5 .8 .c .cat1 .cat3 .cat5 .cat8 .et .h .l .lo .o .obj .x .y
+$(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 lib/com_err/Makefile
+
+Makefile: $(srcdir)/Makefile.in  $(top_builddir)/config.status
+	cd $(top_builddir) \
+	  && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
+
+
+mostlyclean-libLTLIBRARIES:
+
+clean-libLTLIBRARIES:
+	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
+
+distclean-libLTLIBRARIES:
+
+maintainer-clean-libLTLIBRARIES:
+
+install-libLTLIBRARIES: $(lib_LTLIBRARIES)
+	@$(NORMAL_INSTALL)
+	$(mkinstalldirs) $(DESTDIR)$(libdir)
+	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
+	  if test -f $$p; then \
+	    echo " $(LIBTOOL)  --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(libdir)/$$p"; \
+	    $(LIBTOOL)  --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(libdir)/$$p; \
+	  else :; fi; \
+	done
+
+uninstall-libLTLIBRARIES:
+	@$(NORMAL_UNINSTALL)
+	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
+	  echo " $(LIBTOOL)  --mode=uninstall rm -f $(DESTDIR)$(libdir)/$$p"; \
+	  $(LIBTOOL)  --mode=uninstall rm -f $(DESTDIR)$(libdir)/$$p; \
+	done
+
+mostlyclean-compile:
+	-rm -f *.o core *.core
+	-rm -f *.$(OBJEXT)
+
+clean-compile:
+
+distclean-compile:
+	-rm -f *.tab.c
+
+maintainer-clean-compile:
+
+mostlyclean-libtool:
+	-rm -f *.lo
+
+clean-libtool:
+	-rm -rf .libs _libs
+
+distclean-libtool:
+
+maintainer-clean-libtool:
+
+libcom_err.la: $(libcom_err_la_OBJECTS) $(libcom_err_la_DEPENDENCIES)
+	$(LINK) -rpath $(libdir) $(libcom_err_la_LDFLAGS) $(libcom_err_la_OBJECTS) $(libcom_err_la_LIBADD) $(LIBS)
+
+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 \
+	    f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \
+	    echo " $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f"; \
+	    $(LIBTOOL)  --mode=install $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f; \
+	  else :; fi; \
+	done
+
+uninstall-binPROGRAMS:
+	@$(NORMAL_UNINSTALL)
+	@list='$(bin_PROGRAMS)'; for p in $$list; do \
+	  f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \
+	  echo " rm -f $(DESTDIR)$(bindir)/$$f"; \
+	  rm -f $(DESTDIR)$(bindir)/$$f; \
+	done
+
+compile_et$(EXEEXT): $(compile_et_OBJECTS) $(compile_et_DEPENDENCIES)
+	@rm -f compile_et$(EXEEXT)
+	$(LINK) $(compile_et_LDFLAGS) $(compile_et_OBJECTS) $(compile_et_LDADD) $(LIBS)
+.c.o:
+	$(COMPILE) -c $<
+.c.obj:
+	$(COMPILE) -c `cygpath -w $<`
+.c.lo:
+	$(LTCOMPILE) -c -o $@ $<
+.l.c:
+	$(LEX) $(AM_LFLAGS) $(LFLAGS) $< && mv $(LEX_OUTPUT_ROOT).c $@
+.y.c:
+	$(YACC) $(AM_YFLAGS) $(YFLAGS) $< && mv y.tab.c $*.c
+	if test -f y.tab.h; then \
+	if cmp -s y.tab.h $*.h; then rm -f y.tab.h; else mv y.tab.h $*.h; fi; \
+	else :; fi
+parse.h: parse.c
+
+
+install-includeHEADERS: $(include_HEADERS)
+	@$(NORMAL_INSTALL)
+	$(mkinstalldirs) $(DESTDIR)$(includedir)
+	@list='$(include_HEADERS)'; for p in $$list; do \
+	  if test -f "$$p"; then d= ; else d="$(srcdir)/"; fi; \
+	  f="`echo $$p | sed -e 's|^.*/||'`"; \
+	  echo " $(INSTALL_DATA) $$d$$p $(DESTDIR)$(includedir)/$$f"; \
+	  $(INSTALL_DATA) $$d$$p $(DESTDIR)$(includedir)/$$f; \
+	done
+
+uninstall-includeHEADERS:
+	@$(NORMAL_UNINSTALL)
+	@list='$(include_HEADERS)'; for p in $$list; do \
+	  f="`echo $$p | sed -e 's|^.*/||'`"; \
+	  echo " rm -f $(DESTDIR)$(includedir)/$$f"; \
+	  rm -f $(DESTDIR)$(includedir)/$$f; \
+	done
+
+tags: TAGS
+
+ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
+	list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \
+	unique=`for i in $$list; do \
+	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+	  done | \
+	  $(AWK) '    { files[$$0] = 1; } \
+	       END { for (i in files) print i; }'`; \
+	mkid -fID $$unique $(LISP)
+
+TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
+		$(TAGS_FILES) $(LISP)
+	tags=; \
+	here=`pwd`; \
+	list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \
+	unique=`for i in $$list; do \
+	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+	  done | \
+	  $(AWK) '    { files[$$0] = 1; } \
+	       END { for (i in files) print i; }'`; \
+	test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
+	  || etags $(ETAGS_ARGS) $$tags  $$unique $(LISP)
+
+mostlyclean-tags:
+
+clean-tags:
+
+distclean-tags:
+	-rm -f TAGS ID
+
+maintainer-clean-tags:
+
+distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
+
+distdir: $(DISTFILES)
+	@for file in $(DISTFILES); do \
+	  d=$(srcdir); \
+	  if test -d $$d/$$file; then \
+	    cp -pR $$d/$$file $(distdir) \
+	    || exit 1; \
+	  else \
+	    test -f $(distdir)/$$file \
+	    || cp -p $$d/$$file $(distdir)/$$file \
+	    || exit 1; \
+	  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-libLTLIBRARIES install-binPROGRAMS
+	@$(NORMAL_INSTALL)
+	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
+install-exec: install-exec-am
+
+install-data-am: install-includeHEADERS 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-libLTLIBRARIES uninstall-binPROGRAMS \
+		uninstall-includeHEADERS
+uninstall: uninstall-am
+all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
+all-redirect: all-am
+install-strip:
+	$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
+installdirs:
+	$(mkinstalldirs)  $(DESTDIR)$(libdir) $(DESTDIR)$(bindir) \
+		$(DESTDIR)$(includedir)
+
+
+mostlyclean-generic:
+
+clean-generic:
+	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
+
+distclean-generic:
+	-rm -f Makefile $(CONFIG_CLEAN_FILES)
+	-rm -f config.cache config.log stamp-h stamp-h[0-9]*
+
+maintainer-clean-generic:
+	-rm -f Makefile.in
+	-test -z "lex.cparse.hparse.c" || rm -f lex.c parse.h parse.c
+mostlyclean-am:  mostlyclean-libLTLIBRARIES mostlyclean-compile \
+		mostlyclean-libtool mostlyclean-binPROGRAMS \
+		mostlyclean-tags mostlyclean-generic
+
+mostlyclean: mostlyclean-am
+
+clean-am:  clean-libLTLIBRARIES clean-compile clean-libtool \
+		clean-binPROGRAMS clean-tags clean-generic \
+		mostlyclean-am
+
+clean: clean-am
+
+distclean-am:  distclean-libLTLIBRARIES distclean-compile \
+		distclean-libtool distclean-binPROGRAMS distclean-tags \
+		distclean-generic clean-am
+	-rm -f libtool
+
+distclean: distclean-am
+
+maintainer-clean-am:  maintainer-clean-libLTLIBRARIES \
+		maintainer-clean-compile maintainer-clean-libtool \
+		maintainer-clean-binPROGRAMS 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-libLTLIBRARIES distclean-libLTLIBRARIES \
+clean-libLTLIBRARIES maintainer-clean-libLTLIBRARIES \
+uninstall-libLTLIBRARIES install-libLTLIBRARIES mostlyclean-compile \
+distclean-compile clean-compile maintainer-clean-compile \
+mostlyclean-libtool distclean-libtool clean-libtool \
+maintainer-clean-libtool mostlyclean-binPROGRAMS distclean-binPROGRAMS \
+clean-binPROGRAMS maintainer-clean-binPROGRAMS uninstall-binPROGRAMS \
+install-binPROGRAMS uninstall-includeHEADERS install-includeHEADERS \
+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-am install-exec \
+install-data-local install-data-am install-data install-am install \
+uninstall-am uninstall all-local all-redirect all-am all install-strip \
+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 \
+	echo "*"; \
+	echo "* Failed to install $$x setuid root"; \
+	echo "*"; \
+	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-cat-mans:
+	$(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_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
+
+$(compile_et_OBJECTS): parse.h
+
+# 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/lib/com_err/com_err.c b/crypto/heimdal/lib/com_err/com_err.c
new file mode 100644
index 000000000000..25c679ef6100
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/com_err.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 1997 - 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: com_err.c,v 1.15 2000/04/04 22:04:55 assar Exp $");
+#endif
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <roken.h>
+#include "com_err.h"
+
+struct et_list *_et_list = NULL;
+
+
+const char *
+error_message (long code)
+{
+    static char msg[128];
+    const char *p = com_right(_et_list, code);
+    if (p == NULL)
+	p = strerror(code);
+    if (p != NULL && *p != '\0') {
+	strncpy(msg, p, sizeof(msg) - 1);
+	msg[sizeof(msg) - 1] = 0;
+    } else 
+	sprintf(msg, "Unknown error %ld", code);
+    return msg;
+}
+
+int
+init_error_table(const char **msgs, long base, int count)
+{
+    initialize_error_table_r(&_et_list, msgs, count, base);
+    return 0;
+}
+
+static void
+default_proc (const char *whoami, long code, const char *fmt, va_list args)
+{
+    if (whoami)
+      fprintf(stderr, "%s: ", whoami);
+    if (code)
+      fprintf(stderr, "%s ", error_message(code));
+    if (fmt)
+      vfprintf(stderr, fmt, args);
+    fprintf(stderr, "\r\n");	/* ??? */
+}
+
+static errf com_err_hook = default_proc;
+
+void 
+com_err_va (const char *whoami, 
+	    long code, 
+	    const char *fmt, 
+	    va_list args)
+{
+    (*com_err_hook) (whoami, code, fmt, args);
+}
+
+void
+com_err (const char *whoami,
+	 long code,
+	 const char *fmt, 
+	 ...)
+{
+    va_list ap;
+    va_start(ap, fmt);
+    com_err_va (whoami, code, fmt, ap);
+    va_end(ap);
+}
+
+errf
+set_com_err_hook (errf new)
+{
+    errf old = com_err_hook;
+
+    if (new)
+	com_err_hook = new;
+    else
+	com_err_hook = default_proc;
+    
+    return old;
+}
+
+errf
+reset_com_err_hook (void) 
+{
+    return set_com_err_hook(NULL);
+}
+
+#define ERRCODE_RANGE   8       /* # of bits to shift table number */
+#define BITS_PER_CHAR   6       /* # bits to shift per character in name */
+
+static const char char_set[] =
+        "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_";
+
+static char buf[6];
+
+const char *
+error_table_name(int num)
+{
+    int ch;
+    int i;
+    char *p;
+
+    /* num = aa aaa abb bbb bcc ccc cdd ddd d?? ??? ??? */
+    p = buf;
+    num >>= ERRCODE_RANGE;
+    /* num = ?? ??? ??? aaa aaa bbb bbb ccc ccc ddd ddd */
+    num &= 077777777;
+    /* num = 00 000 000 aaa aaa bbb bbb ccc ccc ddd ddd */
+    for (i = 4; i >= 0; i--) {
+        ch = (num >> BITS_PER_CHAR * i) & ((1 << BITS_PER_CHAR) - 1);
+        if (ch != 0)
+            *p++ = char_set[ch-1];
+    }
+    *p = '\0';
+    return(buf);
+}
diff --git a/crypto/heimdal/lib/com_err/com_err.h b/crypto/heimdal/lib/com_err/com_err.h
new file mode 100644
index 000000000000..9703336a0337
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/com_err.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 1997 - 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. 
+ */
+
+/* $Id: com_err.h,v 1.6 2000/01/16 04:51:16 assar Exp $ */
+
+/* MIT compatible com_err library */
+
+#ifndef __COM_ERR_H__
+#define __COM_ERR_H__
+
+#include <com_right.h>
+
+typedef void (*errf) __P((const char *, long, const char *, va_list));
+
+const char * error_message __P((long));
+int init_error_table __P((const char**, long, int));
+
+void com_err_va __P((const char *, long, const char *, va_list));
+void com_err __P((const char *, long, const char *, ...));
+
+errf set_com_err_hook __P((errf));
+errf reset_com_err_hook __P((void));
+
+const char *error_table_name  __P((int num));
+
+#endif /* __COM_ERR_H__ */
diff --git a/crypto/heimdal/lib/com_err/com_right.h b/crypto/heimdal/lib/com_err/com_right.h
new file mode 100644
index 000000000000..c87bb0d1def8
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/com_right.h
@@ -0,0 +1,66 @@
+/*
+ * Copyright (c) 1997 - 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. 
+ */
+
+/* $Id: com_right.h,v 1.11 2000/07/31 01:11:08 assar Exp $ */
+
+#ifndef __COM_RIGHT_H__
+#define __COM_RIGHT_H__
+
+#ifdef __STDC__
+#include <stdarg.h>
+#endif
+
+#ifndef __P
+#ifdef __STDC__
+#define __P(X) X
+#else
+#define __P(X) ()
+#endif
+#endif
+
+struct error_table {
+    char const * const * msgs;
+    long base;
+    int n_msgs;
+};
+struct et_list {
+    struct et_list *next;
+    struct error_table *table;
+};
+extern struct et_list *_et_list;
+
+const char *com_right __P((struct et_list *list, long code));
+void initialize_error_table_r __P((struct et_list **, const char **, int, long));
+void free_error_table __P((struct et_list *));
+
+#endif /* __COM_RIGHT_H__ */
diff --git a/crypto/heimdal/lib/com_err/compile_et.c b/crypto/heimdal/lib/com_err/compile_et.c
new file mode 100644
index 000000000000..f982dcd5a5ff
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/compile_et.c
@@ -0,0 +1,235 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#undef ROKEN_RENAME
+#include "compile_et.h"
+#include <getarg.h>
+
+RCSID("$Id: compile_et.c,v 1.13 1999/12/02 16:58:38 joda Exp $");
+
+#include <roken.h>
+#include <err.h>
+#include "parse.h"
+
+int numerror;
+extern FILE *yyin;
+
+extern void yyparse(void);
+
+long base;
+int number;
+char *prefix;
+char *id_str;
+
+char name[128];
+char Basename[128];
+
+#ifdef YYDEBUG
+extern int yydebug = 1;
+#endif
+
+char *filename;
+char hfn[128];
+char cfn[128];
+
+struct error_code *codes = NULL;
+
+static int
+generate_c(void)
+{
+    int n;
+    struct error_code *ec;
+
+    FILE *c_file = fopen(cfn, "w");
+    if(c_file == NULL)
+	return 1;
+
+    fprintf(c_file, "/* Generated from %s */\n", filename);
+    if(id_str) 
+	fprintf(c_file, "/* %s */\n", id_str);
+    fprintf(c_file, "\n");
+    fprintf(c_file, "#include <stddef.h>\n");
+    fprintf(c_file, "#include <com_err.h>\n");
+    fprintf(c_file, "#include \"%s\"\n", hfn);
+    fprintf(c_file, "\n");
+
+    fprintf(c_file, "static const char *text[] = {\n");
+
+    for(ec = codes, n = 0; ec; ec = ec->next, n++) {
+	while(n < ec->number) {
+	    fprintf(c_file, "\t/* %03d */ \"Reserved %s error (%d)\",\n",
+		    n, name, n);
+	    n++;
+	    
+	}
+	fprintf(c_file, "\t/* %03d */ \"%s\",\n", ec->number, ec->string);
+    }
+
+    fprintf(c_file, "\tNULL\n");
+    fprintf(c_file, "};\n");
+    fprintf(c_file, "\n");
+    fprintf(c_file, 
+	    "void initialize_%s_error_table_r(struct et_list **list)\n", 
+	    name);
+    fprintf(c_file, "{\n");
+    fprintf(c_file, 
+	    "    initialize_error_table_r(list, text, "
+	    "%s_num_errors, ERROR_TABLE_BASE_%s);\n", name, name);
+    fprintf(c_file, "}\n");
+    fprintf(c_file, "\n");
+    fprintf(c_file, "void initialize_%s_error_table(void)\n", name);
+    fprintf(c_file, "{\n");
+    fprintf(c_file,
+	    "    init_error_table(text, ERROR_TABLE_BASE_%s, "
+	    "%s_num_errors);\n", name, name);
+    fprintf(c_file, "}\n");
+
+    fclose(c_file);
+    return 0;
+}
+
+static int
+generate_h(void)
+{
+    struct error_code *ec;
+    char fn[128];
+    FILE *h_file = fopen(hfn, "w");
+    char *p;
+
+    if(h_file == NULL)
+	return 1;
+
+    snprintf(fn, sizeof(fn), "__%s__", hfn);
+    for(p = fn; *p; p++)
+	if(!isalnum((unsigned char)*p))
+	    *p = '_';
+    
+    fprintf(h_file, "/* Generated from %s */\n", filename);
+    if(id_str) 
+	fprintf(h_file, "/* %s */\n", id_str);
+    fprintf(h_file, "\n");
+    fprintf(h_file, "#ifndef %s\n", fn);
+    fprintf(h_file, "#define %s\n", fn);
+    fprintf(h_file, "\n");
+    fprintf(h_file, "#include <com_right.h>\n");
+    fprintf(h_file, "\n");
+    fprintf(h_file, 
+	    "void initialize_%s_error_table_r(struct et_list **);\n",
+	    name);
+    fprintf(h_file, "\n");
+    fprintf(h_file, "void initialize_%s_error_table(void);\n", name);
+    fprintf(h_file, "#define init_%s_err_tbl initialize_%s_error_table\n", 
+	    name, name);
+    fprintf(h_file, "\n");
+    fprintf(h_file, "typedef enum %s_error_number{\n", name);
+    fprintf(h_file, "\tERROR_TABLE_BASE_%s = %ld,\n", name, base);
+    fprintf(h_file, "\t%s_err_base = %ld,\n", name, base);
+
+    for(ec = codes; ec; ec = ec->next) {
+	fprintf(h_file, "\t%s = %ld,\n", ec->name, base + ec->number);
+    }
+
+    fprintf(h_file, "\t%s_num_errors = %d\n", name, number);
+    fprintf(h_file, "} %s_error_number;\n", name);
+    fprintf(h_file, "\n");
+    fprintf(h_file, "#endif /* %s */\n", fn);
+
+
+    fclose(h_file);
+    return 0;
+}
+
+static int
+generate(void)
+{
+    return generate_c() || generate_h();
+}
+
+int version_flag;
+int help_flag;
+struct getargs args[] = {
+    { "version", 0, arg_flag, &version_flag },
+    { "help", 0, arg_flag, &help_flag }
+};
+int num_args = sizeof(args) / sizeof(args[0]);
+
+static void
+usage(int code)
+{
+    arg_printusage(args, num_args, NULL, "error-table");
+    exit(code);
+}
+
+int
+main(int argc, char **argv)
+{
+    char *p;
+    int optind = 0;
+
+    set_progname(argv[0]);
+    if(getarg(args, num_args, argc, argv, &optind))
+	usage(1);
+    if(help_flag)
+	usage(0);
+    if(version_flag) {
+	print_version(NULL);
+	exit(0);
+    }
+
+    if(optind == argc) 
+	usage(1);
+    filename = argv[optind];
+    yyin = fopen(filename, "r");
+    if(yyin == NULL)
+	err(1, "%s", filename);
+	
+    
+    p = strrchr(filename, '/');
+    if(p)
+	p++;
+    else
+	p = filename;
+    strncpy(Basename, p, sizeof(Basename));
+    Basename[sizeof(Basename) - 1] = '\0';
+    
+    Basename[strcspn(Basename, ".")] = '\0';
+    
+    snprintf(hfn, sizeof(hfn), "%s.h", Basename);
+    snprintf(cfn, sizeof(cfn), "%s.c", Basename);
+    
+    yyparse();
+    if(numerror)
+	return 1;
+
+    return generate();
+}
diff --git a/crypto/heimdal/lib/com_err/compile_et.h b/crypto/heimdal/lib/com_err/compile_et.h
new file mode 100644
index 000000000000..86dd1131a7a7
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/compile_et.h
@@ -0,0 +1,79 @@
+/*
+ * 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. 
+ */
+
+/* $Id: compile_et.h,v 1.6 2000/07/01 20:21:48 assar Exp $ */
+
+#ifndef __COMPILE_ET_H__
+#define __COMPILE_ET_H__
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <ctype.h>
+#include <roken.h>
+
+extern long base;
+extern int number;
+extern char *prefix;
+extern char name[128];
+extern char *id_str;
+extern char *filename;
+extern int numerror;
+
+struct error_code {
+    unsigned number;
+    char *name;
+    char *string;
+    struct error_code *next, **tail;
+};
+
+extern struct error_code *codes;
+
+#define APPEND(L, V) 				\
+do {						\
+    if((L) == NULL) {				\
+	(L) = (V);				\
+	(L)->tail = &(V)->next;			\
+	(L)->next = NULL;			\
+    }else{					\
+	*(L)->tail = (V);			\
+	(L)->tail = &(V)->next;			\
+    }						\
+}while(0)
+
+#endif /* __COMPILE_ET_H__ */
diff --git a/crypto/heimdal/lib/com_err/error.c b/crypto/heimdal/lib/com_err/error.c
new file mode 100644
index 000000000000..d1220076d3da
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/error.c
@@ -0,0 +1,91 @@
+/*
+ * 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. 
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+RCSID("$Id: error.c,v 1.14 1999/12/02 16:58:38 joda Exp $");
+#endif
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <com_right.h>
+
+const char *
+com_right(struct et_list *list, long code)
+{
+    struct et_list *p;
+    for (p = list; p; p = p->next) {
+	if (code >= p->table->base && code < p->table->base + p->table->n_msgs)
+	    return p->table->msgs[code - p->table->base];
+    }
+    return NULL;
+}
+
+struct foobar {
+    struct et_list etl;
+    struct error_table et;
+};
+
+void
+initialize_error_table_r(struct et_list **list, 
+			 const char **messages, 
+			 int num_errors,
+			 long base)
+{
+    struct et_list *et;
+    struct foobar *f;
+    for (et = *list; et; et = et->next)
+        if (et->table->msgs == messages)
+            return;
+    f = malloc(sizeof(*f));
+    if (f == NULL)
+        return;
+    et = &f->etl;
+    et->table = &f->et;
+    et->table->msgs = messages;
+    et->table->n_msgs = num_errors;
+    et->table->base = base;
+    et->next = *list;
+    *list = et;
+}
+			
+
+void
+free_error_table(struct et_list *et)
+{
+    while(et){
+	struct et_list *p = et;
+	et = et->next;
+	free(p);
+    }
+}
diff --git a/crypto/heimdal/lib/com_err/lex.h b/crypto/heimdal/lib/com_err/lex.h
new file mode 100644
index 000000000000..9912bf4f0943
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/lex.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 1997 - 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. 
+ */
+
+/* $Id: lex.h,v 1.1 2000/06/22 00:42:52 assar Exp $ */
+
+void error_message (const char *, ...)
+__attribute__ ((format (printf, 1, 2)));
+
+int yylex(void);
diff --git a/crypto/heimdal/lib/com_err/lex.l b/crypto/heimdal/lib/com_err/lex.l
new file mode 100644
index 000000000000..e98db6f86579
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/lex.l
@@ -0,0 +1,126 @@
+%{
+/*
+ * 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. 
+ */
+
+/*
+ * This is to handle the definition of this symbol in some AIX
+ * headers, which will conflict with the definition that lex will
+ * generate for it.  It's only a problem for AIX lex.
+ */
+
+#undef ECHO
+
+#include "compile_et.h"
+#include "parse.h"
+#include "lex.h"
+
+RCSID("$Id: lex.l,v 1.6 2000/06/22 00:42:52 assar Exp $");
+
+static unsigned lineno = 1;
+static int getstring(void);
+
+#define YY_NO_UNPUT
+
+#undef ECHO
+
+%}
+
+
+%%
+et			{ return ET; }
+error_table		{ return ET; }
+ec			{ return EC; }
+error_code		{ return EC; }
+prefix			{ return PREFIX; }
+index			{ return INDEX; }
+id			{ return ID; }
+end			{ return END; }
+[0-9]+			{ yylval.number = atoi(yytext); return NUMBER; }
+#[^\n]*			;
+[ \t]			;
+\n			{ lineno++; }
+\"			{ return getstring(); }
+[a-zA-Z0-9_]+		{ yylval.string = strdup(yytext); return STRING; }
+.			{ return *yytext; }
+%%
+
+#ifndef yywrap /* XXX */
+int
+yywrap () 
+{
+     return 1;
+}
+#endif
+
+static int
+getstring(void)
+{
+    char x[128];
+    int i = 0;
+    int c;
+    int quote = 0;
+    while((c = input()) != EOF){
+	if(quote) {
+	    x[i++] = c;
+	    quote = 0;
+	    continue;
+	}
+	if(c == '\n'){
+	    error_message("unterminated string");
+	    lineno++;
+	    break;
+	}
+	if(c == '\\'){
+	    quote++;
+	    continue;
+	}
+	if(c == '\"')
+	    break;
+	x[i++] = c;
+    }
+    x[i] = '\0';
+    yylval.string = strdup(x);
+    return STRING;
+}
+
+void
+error_message (const char *format, ...)
+{
+     va_list args;
+
+     va_start (args, format);
+     fprintf (stderr, "%s:%d:", filename, lineno);
+     vfprintf (stderr, format, args);
+     va_end (args);
+     numerror++;
+}
diff --git a/crypto/heimdal/lib/com_err/parse.y b/crypto/heimdal/lib/com_err/parse.y
new file mode 100644
index 000000000000..82e99ffb809b
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/parse.y
@@ -0,0 +1,167 @@
+%{
+/*
+ * 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. 
+ */
+
+#include "compile_et.h"
+#include "lex.h"
+
+RCSID("$Id: parse.y,v 1.11 2000/06/22 00:42:52 assar Exp $");
+
+void yyerror (char *s);
+static long name2number(const char *str);
+
+extern char *yytext;
+
+/* This is for bison */
+
+#if !defined(alloca) && !defined(HAVE_ALLOCA)
+#define alloca(x) malloc(x)
+#endif
+
+%}
+
+%union {
+  char *string;
+  int number;
+}
+
+%token ET INDEX PREFIX EC ID END
+%token <string> STRING
+%token <number> NUMBER
+
+%%
+
+file		: /* */ 
+		| header statements
+		;
+
+header		: id et
+		| et
+		;
+
+id		: ID STRING
+		{
+		    id_str = $2;
+		}
+		;
+
+et		: ET STRING
+		{
+		    base = name2number($2);
+		    strncpy(name, $2, sizeof(name));
+		    name[sizeof(name) - 1] = '\0';
+		    free($2);
+		}
+		| ET STRING STRING
+		{
+		    base = name2number($2);
+		    strncpy(name, $3, sizeof(name));
+		    name[sizeof(name) - 1] = '\0';
+		    free($2);
+		    free($3);
+		}
+		;
+
+statements	: statement
+		| statements statement
+		;
+
+statement	: INDEX NUMBER 
+		{
+			number = $2;
+		}
+		| PREFIX STRING
+		{
+		    prefix = realloc(prefix, strlen($2) + 2);
+		    strcpy(prefix, $2);
+		    strcat(prefix, "_");
+		    free($2);
+		}
+		| PREFIX
+		{
+		    prefix = realloc(prefix, 1);
+		    *prefix = '\0';
+		}
+		| EC STRING ',' STRING
+		{
+		    struct error_code *ec = malloc(sizeof(*ec));
+
+		    ec->next = NULL;
+		    ec->number = number;
+		    if(prefix && *prefix != '\0') {
+			asprintf (&ec->name, "%s%s", prefix, $2);
+			free($2);
+		    } else
+			ec->name = $2;
+		    ec->string = $4;
+		    APPEND(codes, ec);
+		    number++;
+		}
+		| END
+		{
+			YYACCEPT;
+		}
+		;
+
+%%
+
+static long
+name2number(const char *str)
+{
+    const char *p;
+    long base = 0;
+    const char *x = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
+	"abcdefghijklmnopqrstuvwxyz0123456789_";
+    if(strlen(str) > 4) {
+	yyerror("table name too long");
+	return 0;
+    }
+    for(p = str; *p; p++){
+	char *q = strchr(x, *p);
+	if(q == NULL) {
+	    yyerror("invalid character in table name");
+	    return 0;
+	}
+	base = (base << 6) + (q - x) + 1;
+    }
+    base <<= 8;
+    if(base > 0x7fffffff)
+	base = -(0xffffffff - base + 1);
+    return base;
+}
+
+void
+yyerror (char *s)
+{
+     error_message ("%s\n", s);
+}
diff --git a/crypto/heimdal/lib/com_err/roken_rename.h b/crypto/heimdal/lib/com_err/roken_rename.h
new file mode 100644
index 000000000000..173c9a7d5ae9
--- /dev/null
+++ b/crypto/heimdal/lib/com_err/roken_rename.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+/* $Id: roken_rename.h,v 1.3 1999/12/02 16:58:38 joda Exp $ */
+
+#ifndef __roken_rename_h__
+#define __roken_rename_h__
+
+#endif /* __roken_rename_h__ */
diff --git a/crypto/heimdal/lib/gssapi/address_to_krb5addr.c b/crypto/heimdal/lib/gssapi/address_to_krb5addr.c
new file mode 100644
index 000000000000..1d8c1b6a5c34
--- /dev/null
+++ b/crypto/heimdal/lib/gssapi/address_to_krb5addr.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include "gssapi_locl.h"
+
+#include <roken.h>
+
+krb5_error_code
+gss_address_to_krb5addr(OM_uint32 gss_addr_type,
+                        gss_buffer_desc *gss_addr,
+                        int16_t port,
+                        krb5_address *address)
+{
+   int addr_type;
+   struct sockaddr sa;
+   int sa_size = sizeof(sa);
+   krb5_error_code problem;
+   
+   if (gss_addr == NULL)
+      return GSS_S_FAILURE; 
+   
+   switch (gss_addr_type) {
+#ifdef HAVE_IPV6
+      case GSS_C_AF_INET6: addr_type = AF_INET6;
+                           break;
+#endif /* HAVE_IPV6 */
+                           
+      case GSS_C_AF_INET:  addr_type = AF_INET;
+                           break;
+      default:
+                           return GSS_S_FAILURE;
+   }
+                      
+   problem = krb5_h_addr2sockaddr (addr_type,
+                                   gss_addr->value, 
+                                   &sa, 
+                                   &sa_size, 
+                                   port);
+   if (problem)
+      return GSS_S_FAILURE;
+
+   problem = krb5_sockaddr2address (&sa, address);
+
+   return problem;  
+}
diff --git a/crypto/heimdal/lib/gssapi/copy_ccache.c b/crypto/heimdal/lib/gssapi/copy_ccache.c
new file mode 100644
index 000000000000..f91acab4c397
--- /dev/null
+++ b/crypto/heimdal/lib/gssapi/copy_ccache.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 2000 - 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 "gssapi_locl.h"
+
+RCSID("$Id: copy_ccache.c,v 1.1 2001/01/30 00:35:47 assar Exp $");
+
+OM_uint32
+gss_krb5_copy_ccache(OM_uint32 *minor,
+		     gss_cred_id_t cred,
+		     krb5_ccache out)
+{
+    krb5_error_code kret;
+
+    if (cred->ccache == NULL) {
+	*minor = EINVAL;
+	return GSS_S_FAILURE;
+    }
+
+    kret = krb5_cc_copy_cache(gssapi_krb5_context, cred->ccache, out);
+    if (kret) {
+	*minor = kret;
+	return GSS_S_FAILURE;
+    }
+    return GSS_S_COMPLETE;
+}
diff --git a/crypto/heimdal/lib/hdb/db3.c b/crypto/heimdal/lib/hdb/db3.c
new file mode 100644
index 000000000000..a682071a6077
--- /dev/null
+++ b/crypto/heimdal/lib/hdb/db3.c
@@ -0,0 +1,310 @@
+/*
+ * 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 "hdb_locl.h"
+
+RCSID("$Id: db3.c,v 1.6 2001/01/30 01:24:00 assar Exp $");
+
+#if defined(HAVE_DB_H) && DB_VERSION_MAJOR == 3
+static krb5_error_code
+DB_close(krb5_context context, HDB *db)
+{
+    DB *d = (DB*)db->db;
+    DBC *dbcp = (DBC*)db->dbc;
+
+    dbcp->c_close(dbcp);
+    db->dbc = 0;
+    d->close(d, 0);
+    return 0;
+}
+
+static krb5_error_code
+DB_destroy(krb5_context context, HDB *db)
+{
+    krb5_error_code ret;
+
+    ret = hdb_clear_master_key (context, db);
+    free(db->name);
+    free(db);
+    return ret;
+}
+
+static krb5_error_code
+DB_lock(krb5_context context, HDB *db, int operation)
+{
+    DB *d = (DB*)db->db;
+    int fd;
+    if ((*d->fd)(d, &fd))
+	return HDB_ERR_CANT_LOCK_DB;
+    return hdb_lock(fd, operation);
+}
+
+static krb5_error_code
+DB_unlock(krb5_context context, HDB *db)
+{
+    DB *d = (DB*)db->db;
+    int fd;
+    if ((*d->fd)(d, &fd))
+	return HDB_ERR_CANT_LOCK_DB;
+    return hdb_unlock(fd);
+}
+
+
+static krb5_error_code
+DB_seq(krb5_context context, HDB *db,
+       unsigned flags, hdb_entry *entry, int flag)
+{
+    DB *d = (DB*)db->db;
+    DBT key, value;
+    DBC *dbcp = db->dbc;
+    krb5_data key_data, data;
+    int code;
+
+    memset(&key, 0, sizeof(DBT));
+    memset(&value, 0, sizeof(DBT));
+    if (db->lock(context, db, HDB_RLOCK))
+	return HDB_ERR_DB_INUSE;
+    code = dbcp->c_get(dbcp, &key, &value, flag);
+    db->unlock(context, db); /* XXX check value */
+    if (code == DB_NOTFOUND)
+	return HDB_ERR_NOENTRY;
+    if (code)
+	return code;
+
+    key_data.data = key.data;
+    key_data.length = key.size;
+    data.data = value.data;
+    data.length = value.size;
+    if (hdb_value2entry(context, &data, entry))
+	return DB_seq(context, db, flags, entry, DB_NEXT);
+    if (db->master_key_set && (flags & HDB_F_DECRYPT)) {
+	code = hdb_unseal_keys (context, db, entry);
+	if (code)
+	    hdb_free_entry (context, entry);
+    }
+    if (entry->principal == NULL) {
+	entry->principal = malloc(sizeof(*entry->principal));
+	if (entry->principal == NULL) {
+	    code = ENOMEM;
+	    hdb_free_entry (context, entry);
+	} else {
+	    hdb_key2principal(context, &key_data, entry->principal);
+	}
+    }
+    return 0;
+}
+
+
+static krb5_error_code
+DB_firstkey(krb5_context context, HDB *db, unsigned flags, hdb_entry *entry)
+{
+    return DB_seq(context, db, flags, entry, DB_FIRST);
+}
+
+
+static krb5_error_code
+DB_nextkey(krb5_context context, HDB *db, unsigned flags, hdb_entry *entry)
+{
+    return DB_seq(context, db, flags, entry, DB_NEXT);
+}
+
+static krb5_error_code
+DB_rename(krb5_context context, HDB *db, const char *new_name)
+{
+    int ret;
+    char *old, *new;
+
+    asprintf(&old, "%s.db", db->name);
+    asprintf(&new, "%s.db", new_name);
+    ret = rename(old, new);
+    free(old);
+    free(new);
+    if(ret)
+	return errno;
+    
+    free(db->name);
+    db->name = strdup(new_name);
+    return 0;
+}
+
+static krb5_error_code
+DB__get(krb5_context context, HDB *db, krb5_data key, krb5_data *reply)
+{
+    DB *d = (DB*)db->db;
+    DBT k, v;
+    int code;
+
+    memset(&k, 0, sizeof(DBT));
+    memset(&v, 0, sizeof(DBT));
+    k.data = key.data;
+    k.size = key.length;
+    k.flags = 0;
+    if ((code = db->lock(context, db, HDB_RLOCK)))
+	return code;
+    code = d->get(d, NULL, &k, &v, 0);
+    db->unlock(context, db);
+    if(code == DB_NOTFOUND)
+	return HDB_ERR_NOENTRY;
+    if(code)
+	return code;
+
+    krb5_data_copy(reply, v.data, v.size);
+    return 0;
+}
+
+static krb5_error_code
+DB__put(krb5_context context, HDB *db, int replace, 
+	krb5_data key, krb5_data value)
+{
+    DB *d = (DB*)db->db;
+    DBT k, v;
+    int code;
+
+    memset(&k, 0, sizeof(DBT));
+    memset(&v, 0, sizeof(DBT));
+    k.data = key.data;
+    k.size = key.length;
+    k.flags = 0;
+    v.data = value.data;
+    v.size = value.length;
+    v.flags = 0;
+    if ((code = db->lock(context, db, HDB_WLOCK)))
+	return code;
+    code = d->put(d, NULL, &k, &v, replace ? 0 : DB_NOOVERWRITE);
+    db->unlock(context, db);
+    if(code == DB_KEYEXIST)
+	return HDB_ERR_EXISTS;
+    if(code)
+	return errno;
+    return 0;
+}
+
+static krb5_error_code
+DB__del(krb5_context context, HDB *db, krb5_data key)
+{
+    DB *d = (DB*)db->db;
+    DBT k;
+    krb5_error_code code;
+    memset(&k, 0, sizeof(DBT));
+    k.data = key.data;
+    k.size = key.length;
+    k.flags = 0;
+    code = db->lock(context, db, HDB_WLOCK);
+    if(code)
+	return code;
+    code = d->del(d, NULL, &k, 0);
+    db->unlock(context, db);
+    if(code == DB_NOTFOUND)
+	return HDB_ERR_NOENTRY;
+    if(code)
+	return code;
+    return 0;
+}
+
+static krb5_error_code
+DB_open(krb5_context context, HDB *db, int flags, mode_t mode)
+{
+    char *fn;
+    krb5_error_code ret;
+    DB *d;
+    int myflags = 0;
+
+    if (flags & O_CREAT)
+      myflags |= DB_CREATE;
+
+    if (flags & O_EXCL)
+      myflags |= DB_EXCL;
+
+    if (flags & O_RDONLY)
+      myflags |= DB_RDONLY;
+
+    if (flags & O_TRUNC)
+      myflags |= DB_TRUNCATE;
+
+    asprintf(&fn, "%s.db", db->name);
+    if (fn == NULL)
+	return ENOMEM;
+    db_create(&d, NULL, 0);
+    db->db = d;
+    if ((ret = d->open(db->db, fn, NULL, DB_BTREE, myflags, mode))) {
+      if(ret == ENOENT)
+	/* try to open without .db extension */
+	if (d->open(db->db, db->name, NULL, DB_BTREE, myflags, mode)) {
+	  free(fn);
+	  return ret;
+	}
+    }
+    free(fn);
+
+    ret = d->cursor(d, NULL, (DBC **)&db->dbc, 0);
+    if (ret)
+        return ret;
+
+    if((flags & O_ACCMODE) == O_RDONLY)
+	ret = hdb_check_db_format(context, db);
+    else
+	ret = hdb_init_db(context, db);
+    if(ret == HDB_ERR_NOENTRY)
+	return 0;
+    return ret;
+}
+
+krb5_error_code
+hdb_db_create(krb5_context context, HDB **db, 
+	      const char *filename)
+{
+    *db = malloc(sizeof(**db));
+    if (*db == NULL)
+	return ENOMEM;
+
+    (*db)->db = NULL;
+    (*db)->name = strdup(filename);
+    (*db)->master_key_set = 0;
+    (*db)->openp = 0;
+    (*db)->open  = DB_open;
+    (*db)->close = DB_close;
+    (*db)->fetch = _hdb_fetch;
+    (*db)->store = _hdb_store;
+    (*db)->remove = _hdb_remove;
+    (*db)->firstkey = DB_firstkey;
+    (*db)->nextkey= DB_nextkey;
+    (*db)->lock = DB_lock;
+    (*db)->unlock = DB_unlock;
+    (*db)->rename = DB_rename;
+    (*db)->_get = DB__get;
+    (*db)->_put = DB__put;
+    (*db)->_del = DB__del;
+    (*db)->destroy = DB_destroy;
+    return 0;
+}
+#endif
diff --git a/crypto/heimdal/lib/hdb/hdb-ldap.c b/crypto/heimdal/lib/hdb/hdb-ldap.c
new file mode 100644
index 000000000000..6d264b428153
--- /dev/null
+++ b/crypto/heimdal/lib/hdb/hdb-ldap.c
@@ -0,0 +1,1344 @@
+/*
+ * Copyright (c) 1999 - 2001, PADL Software Pty Ltd.
+ * 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 PADL Software  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 PADL SOFTWARE 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 PADL SOFTWARE 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 "hdb_locl.h"
+
+RCSID("$Id: hdb-ldap.c,v 1.7 2001/01/30 16:59:08 assar Exp $");
+
+#ifdef OPENLDAP
+
+#include <ldap.h>
+#include <lber.h>
+#include <ctype.h>
+#include <sys/un.h>
+
+static krb5_error_code LDAP__connect(krb5_context context, HDB * db);
+
+static krb5_error_code
+LDAP_message2entry(krb5_context context, HDB * db, LDAPMessage * msg,
+		   hdb_entry * ent);
+
+static char *krb5kdcentry_attrs[] =
+    { "krb5PrincipalName", "cn", "krb5PrincipalRealm",
+    "krb5KeyVersionNumber", "krb5Key",
+    "krb5ValidStart", "krb5ValidEnd", "krb5PasswordEnd",
+    "krb5MaxLife", "krb5MaxRenew", "krb5KDCFlags", "krb5EncryptionType",
+    "modifiersName", "modifyTimestamp", "creatorsName", "createTimestamp",
+    NULL
+};
+
+static char *krb5principal_attrs[] =
+    { "krb5PrincipalName", "cn", "krb5PrincipalRealm",
+    "modifiersName", "modifyTimestamp", "creatorsName", "createTimestamp",
+    NULL
+};
+
+/* based on samba: source/passdb/ldap.c */
+static krb5_error_code
+LDAP_addmod_len(LDAPMod *** modlist, int modop, const char *attribute,
+		unsigned char *value, size_t len)
+{
+    LDAPMod **mods = *modlist;
+    int i, j;
+
+    if (mods == NULL) {
+	mods = (LDAPMod **) calloc(1, sizeof(LDAPMod *));
+	if (mods == NULL) {
+	    return ENOMEM;
+	}
+	mods[0] = NULL;
+    }
+
+    for (i = 0; mods[i] != NULL; ++i) {
+	if ((mods[i]->mod_op & (~LDAP_MOD_BVALUES)) == modop
+	    && (!strcasecmp(mods[i]->mod_type, attribute))) {
+	    break;
+	}
+    }
+
+    if (mods[i] == NULL) {
+	mods = (LDAPMod **) realloc(mods, (i + 2) * sizeof(LDAPMod *));
+	if (mods == NULL) {
+	    return ENOMEM;
+	}
+	mods[i] = (LDAPMod *) malloc(sizeof(LDAPMod));
+	if (mods[i] == NULL) {
+	    return ENOMEM;
+	}
+	mods[i]->mod_op = modop | LDAP_MOD_BVALUES;
+	mods[i]->mod_bvalues = NULL;
+	mods[i]->mod_type = strdup(attribute);
+	if (mods[i]->mod_type == NULL) {
+	    return ENOMEM;
+	}
+	mods[i + 1] = NULL;
+    }
+
+    if (value != NULL) {
+	j = 0;
+	if (mods[i]->mod_bvalues != NULL) {
+	    for (; mods[i]->mod_bvalues[j] != NULL; j++);
+	}
+	mods[i]->mod_bvalues =
+	    (struct berval **) realloc(mods[i]->mod_bvalues,
+				       (j + 2) * sizeof(struct berval *));
+	if (mods[i]->mod_bvalues == NULL) {
+	    return ENOMEM;
+	}
+	/* Caller allocates memory on our behalf, unlike LDAP_addmod. */
+	mods[i]->mod_bvalues[j] =
+	    (struct berval *) malloc(sizeof(struct berval));
+	if (mods[i]->mod_bvalues[j] == NULL) {
+	    return ENOMEM;
+	}
+	mods[i]->mod_bvalues[j]->bv_val = value;
+	mods[i]->mod_bvalues[j]->bv_len = len;
+	mods[i]->mod_bvalues[j + 1] = NULL;
+    }
+    *modlist = mods;
+    return 0;
+}
+
+static krb5_error_code
+LDAP_addmod(LDAPMod *** modlist, int modop, const char *attribute,
+	    const char *value)
+{
+    LDAPMod **mods = *modlist;
+    int i, j;
+
+    if (mods == NULL) {
+	mods = (LDAPMod **) calloc(1, sizeof(LDAPMod *));
+	if (mods == NULL) {
+	    return ENOMEM;
+	}
+	mods[0] = NULL;
+    }
+
+    for (i = 0; mods[i] != NULL; ++i) {
+	if (mods[i]->mod_op == modop
+	    && (!strcasecmp(mods[i]->mod_type, attribute))) {
+	    break;
+	}
+    }
+
+    if (mods[i] == NULL) {
+	mods = (LDAPMod **) realloc(mods, (i + 2) * sizeof(LDAPMod *));
+	if (mods == NULL) {
+	    return ENOMEM;
+	}
+	mods[i] = (LDAPMod *) malloc(sizeof(LDAPMod));
+	if (mods[i] == NULL) {
+	    return ENOMEM;
+	}
+	mods[i]->mod_op = modop;
+	mods[i]->mod_values = NULL;
+	mods[i]->mod_type = strdup(attribute);
+	if (mods[i]->mod_type == NULL) {
+	    return ENOMEM;
+	}
+	mods[i + 1] = NULL;
+    }
+
+    if (value != NULL) {
+	j = 0;
+	if (mods[i]->mod_values != NULL) {
+	    for (; mods[i]->mod_values[j] != NULL; j++);
+	}
+	mods[i]->mod_values = (char **) realloc(mods[i]->mod_values,
+						(j + 2) * sizeof(char *));
+	if (mods[i]->mod_values == NULL) {
+	    return ENOMEM;
+	}
+	mods[i]->mod_values[j] = strdup(value);
+	if (mods[i]->mod_values[j] == NULL) {
+	    return ENOMEM;
+	}
+	mods[i]->mod_values[j + 1] = NULL;
+    }
+    *modlist = mods;
+    return 0;
+}
+
+static krb5_error_code
+LDAP_addmod_generalized_time(LDAPMod *** mods, int modop,
+			     const char *attribute, KerberosTime * time)
+{
+    char buf[22];
+    struct tm *tm;
+
+    /* XXX not threadsafe */
+    tm = gmtime(time);
+    strftime(buf, sizeof(buf), "%Y%m%d%H%M%SZ", tm);
+
+    return LDAP_addmod(mods, modop, attribute, buf);
+}
+
+static krb5_error_code
+LDAP_get_string_value(HDB * db, LDAPMessage * entry,
+		      const char *attribute, char **ptr)
+{
+    char **vals;
+    int ret;
+
+    vals = ldap_get_values((LDAP *) db->db, entry, (char *) attribute);
+    if (vals == NULL) {
+	return HDB_ERR_NOENTRY;
+    }
+    *ptr = strdup(vals[0]);
+    if (*ptr == NULL) {
+	ret = ENOMEM;
+    } else {
+	ret = 0;
+    }
+
+    ldap_value_free(vals);
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP_get_integer_value(HDB * db, LDAPMessage * entry,
+		       const char *attribute, int *ptr)
+{
+    char **vals;
+
+    vals = ldap_get_values((LDAP *) db->db, entry, (char *) attribute);
+    if (vals == NULL) {
+	return HDB_ERR_NOENTRY;
+    }
+    *ptr = atoi(vals[0]);
+    ldap_value_free(vals);
+    return 0;
+}
+
+static krb5_error_code
+LDAP_get_generalized_time_value(HDB * db, LDAPMessage * entry,
+				const char *attribute, KerberosTime * kt)
+{
+    char *tmp, *gentime;
+    struct tm tm;
+    int ret;
+
+    *kt = 0;
+
+    ret = LDAP_get_string_value(db, entry, attribute, &gentime);
+    if (ret != 0) {
+	return ret;
+    }
+
+    tmp = strptime(gentime, "%Y%m%d%H%M%SZ", &tm);
+    if (tmp == NULL) {
+	free(gentime);
+	return HDB_ERR_NOENTRY;
+    }
+
+    free(gentime);
+
+    *kt = timegm(&tm);
+
+    return 0;
+}
+
+static krb5_error_code
+LDAP_entry2mods(krb5_context context, HDB * db, hdb_entry * ent,
+		LDAPMessage * msg, LDAPMod *** pmods)
+{
+    krb5_error_code ret;
+    krb5_boolean is_new_entry;
+    int rc, i;
+    char *tmp = NULL;
+    LDAPMod **mods = NULL;
+    hdb_entry orig;
+    unsigned long oflags, nflags;
+
+    if (msg != NULL) {
+	ret = LDAP_message2entry(context, db, msg, &orig);
+	if (ret != 0) {
+	    goto out;
+	}
+	is_new_entry = FALSE;
+    } else {
+	/* to make it perfectly obvious we're depending on
+	 * orig being intiialized to zero */
+	memset(&orig, 0, sizeof(orig));
+	is_new_entry = TRUE;
+    }
+
+    if (is_new_entry) {
+	ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass", "top");
+	if (ret != 0) {
+	    goto out;
+	}
+	/* person is the structural object class */
+	ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass", "person");
+	if (ret != 0) {
+	    goto out;
+	}
+	ret =
+	    LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass",
+			"krb5Principal");
+	if (ret != 0) {
+	    goto out;
+	}
+	ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "objectClass",
+			  "krb5KDCEntry");
+	if (ret != 0) {
+	    goto out;
+	}
+    }
+
+    if (is_new_entry ||
+	krb5_principal_compare(context, ent->principal, orig.principal) ==
+	FALSE) {
+	ret = krb5_unparse_name(context, ent->principal, &tmp);
+	if (ret != 0) {
+	    goto out;
+	}
+	ret =
+	    LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5PrincipalName", tmp);
+	if (ret != 0) {
+	    free(tmp);
+	    goto out;
+	}
+	free(tmp);
+    }
+
+    if (ent->kvno != orig.kvno) {
+	rc = asprintf(&tmp, "%d", ent->kvno);
+	if (rc < 0) {
+	    ret = ENOMEM;
+	    goto out;
+	}
+	ret =
+	    LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5KeyVersionNumber",
+			tmp);
+	free(tmp);
+	if (ret != 0) {
+	    goto out;
+	}
+    }
+
+    if (ent->valid_start) {
+	if (orig.valid_end == NULL
+	    || (*(ent->valid_start) != *(orig.valid_start))) {
+	    ret =
+		LDAP_addmod_generalized_time(&mods, LDAP_MOD_REPLACE,
+					     "krb5ValidStart",
+					     ent->valid_start);
+	    if (ret != 0) {
+		goto out;
+	    }
+	}
+    }
+
+    if (ent->valid_end) {
+	if (orig.valid_end == NULL
+	    || (*(ent->valid_end) != *(orig.valid_end))) {
+	    ret =
+		LDAP_addmod_generalized_time(&mods, LDAP_MOD_REPLACE,
+					     "krb5ValidEnd",
+					     ent->valid_end);
+	    if (ret != 0) {
+		goto out;
+	    }
+	}
+    }
+
+    if (ent->pw_end) {
+	if (orig.pw_end == NULL || (*(ent->pw_end) != *(orig.pw_end))) {
+	    ret =
+		LDAP_addmod_generalized_time(&mods, LDAP_MOD_REPLACE,
+					     "krb5PasswordEnd",
+					     ent->pw_end);
+	    if (ret != 0) {
+		goto out;
+	    }
+	}
+    }
+
+    if (ent->max_life) {
+	if (orig.max_life == NULL
+	    || (*(ent->max_life) != *(orig.max_life))) {
+	    rc = asprintf(&tmp, "%d", *(ent->max_life));
+	    if (rc < 0) {
+		ret = ENOMEM;
+		goto out;
+	    }
+	    ret = LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5MaxLife", tmp);
+	    free(tmp);
+	    if (ret != 0) {
+		goto out;
+	    }
+	}
+    }
+
+    if (ent->max_renew) {
+	if (orig.max_renew == NULL
+	    || (*(ent->max_renew) != *(orig.max_renew))) {
+	    rc = asprintf(&tmp, "%d", *(ent->max_renew));
+	    if (rc < 0) {
+		ret = ENOMEM;
+		goto out;
+	    }
+	    ret =
+		LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5MaxRenew", tmp);
+	    free(tmp);
+	    if (ret != 0) {
+		goto out;
+	    }
+	}
+    }
+
+    memset(&oflags, 0, sizeof(oflags));
+    memcpy(&oflags, &orig.flags, sizeof(HDBFlags));
+    memset(&nflags, 0, sizeof(nflags));
+    memcpy(&nflags, &ent->flags, sizeof(HDBFlags));
+
+    if (memcmp(&oflags, &nflags, sizeof(HDBFlags))) {
+	rc = asprintf(&tmp, "%lu", nflags);
+	if (rc < 0) {
+	    ret = ENOMEM;
+	    goto out;
+	}
+	ret = LDAP_addmod(&mods, LDAP_MOD_REPLACE, "krb5KDCFlags", tmp);
+	free(tmp);
+	if (ret != 0) {
+	    goto out;
+	}
+    }
+
+    if (is_new_entry == FALSE && orig.keys.len > 0) {
+	/* for the moment, clobber and replace keys. */
+	ret = LDAP_addmod(&mods, LDAP_MOD_DELETE, "krb5Key", NULL);
+	if (ret != 0) {
+	    goto out;
+	}
+    }
+
+    for (i = 0; i < ent->keys.len; i++) {
+	unsigned char *buf;
+	size_t len;
+	Key new;
+
+	ret = copy_Key(&ent->keys.val[i], &new);
+	if (ret != 0) {
+	    goto out;
+	}
+
+	len = length_Key(&new);
+	buf = malloc(len);
+	if (buf == NULL) {
+	    ret = ENOMEM;
+	    free_Key(&new);
+	    goto out;
+	}
+
+	ret = encode_Key(buf + len - 1, len, &new, &len);
+	if (ret != 0) {
+	    free(buf);
+	    free_Key(&new);
+	    goto out;
+	}
+	free_Key(&new);
+
+	/* addmod_len _owns_ the key, doesn't need to copy it */
+	ret = LDAP_addmod_len(&mods, LDAP_MOD_ADD, "krb5Key", buf, len);
+	if (ret != 0) {
+	    goto out;
+	}
+    }
+
+    if (ent->etypes) {
+	/* clobber and replace encryption types. */
+	if (is_new_entry == FALSE) {
+	    ret =
+		LDAP_addmod(&mods, LDAP_MOD_DELETE, "krb5EncryptionType",
+			    NULL);
+	}
+	for (i = 0; i < ent->etypes->len; i++) {
+	    rc = asprintf(&tmp, "%d", ent->etypes->val[i]);
+	    if (rc < 0) {
+		ret = ENOMEM;
+		goto out;
+	    }
+	    free(tmp);
+	    ret =
+		LDAP_addmod(&mods, LDAP_MOD_ADD, "krb5EncryptionType",
+			    tmp);
+	    if (ret != 0) {
+		goto out;
+	    }
+	}
+    }
+
+    /* for clarity */
+    ret = 0;
+
+  out:
+
+    if (ret == 0) {
+	*pmods = mods;
+    } else if (mods != NULL) {
+	ldap_mods_free(mods, 1);
+	*pmods = NULL;
+    }
+
+    if (msg != NULL) {
+	hdb_free_entry(context, &orig);
+    }
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP_dn2principal(krb5_context context, HDB * db, const char *dn,
+		  krb5_principal * principal)
+{
+    krb5_error_code ret;
+    int rc;
+    char **values;
+    LDAPMessage *res = NULL, *e;
+
+    rc = 1;
+    (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, &rc);
+    rc = ldap_search_s((LDAP *) db->db, db->name, LDAP_SCOPE_BASE,
+		       "(objectclass=krb5Principal)", krb5principal_attrs,
+		       0, &res);
+
+    if (rc != LDAP_SUCCESS) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    e = ldap_first_entry((LDAP *) db->db, res);
+    if (e == NULL) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    values = ldap_get_values((LDAP *) db->db, e, "krb5PrincipalName");
+    if (values == NULL) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    ret = krb5_parse_name(context, values[0], principal);
+    ldap_value_free(values);
+
+  out:
+    if (res != NULL) {
+	ldap_msgfree(res);
+    }
+    return ret;
+}
+
+static krb5_error_code
+LDAP__lookup_princ(krb5_context context, HDB * db, const char *princname,
+		   LDAPMessage ** msg)
+{
+    krb5_error_code ret;
+    int rc;
+    char *filter = NULL;
+
+    (void) LDAP__connect(context, db);
+
+    rc =
+	asprintf(&filter,
+		 "(&(objectclass=krb5KDCEntry)(krb5PrincipalName=%s))",
+		 princname);
+    if (rc < 0) {
+	ret = ENOMEM;
+	goto out;
+    }
+
+    rc = 1;
+    (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, (void *) &rc);
+
+    rc = ldap_search_s((LDAP *) db->db, db->name, LDAP_SCOPE_ONELEVEL, filter, 
+		       krb5kdcentry_attrs, 0, msg);
+    if (rc != LDAP_SUCCESS) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    ret = 0;
+
+  out:
+    if (filter != NULL) {
+	free(filter);
+    }
+    return ret;
+}
+
+static krb5_error_code
+LDAP_principal2message(krb5_context context, HDB * db,
+		       krb5_principal princ, LDAPMessage ** msg)
+{
+    char *princname = NULL;
+    krb5_error_code ret;
+
+    ret = krb5_unparse_name(context, princ, &princname);
+    if (ret != 0) {
+	return ret;
+    }
+
+    ret = LDAP__lookup_princ(context, db, princname, msg);
+    free(princname);
+
+    return ret;
+}
+
+/*
+ * Construct an hdb_entry from a directory entry.
+ */
+static krb5_error_code
+LDAP_message2entry(krb5_context context, HDB * db, LDAPMessage * msg,
+		   hdb_entry * ent)
+{
+    char *unparsed_name = NULL, *dn = NULL;
+    int ret;
+    unsigned long tmp;
+    struct berval **keys;
+    char **values;
+
+    memset(ent, 0, sizeof(*ent));
+    memset(&ent->flags, 0, sizeof(HDBFlags));
+
+    ret =
+	LDAP_get_string_value(db, msg, "krb5PrincipalName",
+			      &unparsed_name);
+    if (ret != 0) {
+	return ret;
+    }
+
+    ret = krb5_parse_name(context, unparsed_name, &ent->principal);
+    if (ret != 0) {
+	goto out;
+    }
+
+    ret =
+	LDAP_get_integer_value(db, msg, "krb5KeyVersionNumber",
+			       &ent->kvno);
+    if (ret != 0) {
+	ent->kvno = 0;
+    }
+
+    keys = ldap_get_values_len((LDAP *) db->db, msg, "krb5Key");
+    if (keys != NULL) {
+	int i;
+	size_t l;
+
+	ent->keys.len = ldap_count_values_len(keys);
+	ent->keys.val = (Key *) calloc(ent->keys.len, sizeof(Key));
+	for (i = 0; i < ent->keys.len; i++) {
+	    decode_Key((unsigned char *) keys[i]->bv_val,
+		       (size_t) keys[i]->bv_len, &ent->keys.val[i], &l);
+	}
+	ber_bvecfree(keys);
+    } else {
+#if 1
+	/*
+	 * This violates the ASN1 but it allows a principal to
+	 * be related to a general directory entry without creating
+	 * the keys. Hopefully it's OK.
+	 */
+	ent->keys.len = 0;
+	ent->keys.val = NULL;
+#else
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+#endif
+    }
+
+    ret =
+	LDAP_get_generalized_time_value(db, msg, "createTimestamp",
+					&ent->created_by.time);
+    if (ret != 0) {
+	ent->created_by.time = time(NULL);
+    }
+
+    ent->created_by.principal = NULL;
+
+    ret = LDAP_get_string_value(db, msg, "creatorsName", &dn);
+    if (ret == 0) {
+	if (LDAP_dn2principal(context, db, dn, &ent->created_by.principal)
+	    != 0) {
+	    ent->created_by.principal = NULL;
+	}
+	free(dn);
+    }
+
+    ent->modified_by = (Event *) malloc(sizeof(Event));
+    if (ent->modified_by == NULL) {
+	ret = ENOMEM;
+	goto out;
+    }
+    ret =
+	LDAP_get_generalized_time_value(db, msg, "modifyTimestamp",
+					&ent->modified_by->time);
+    if (ret == 0) {
+	ret = LDAP_get_string_value(db, msg, "modifiersName", &dn);
+	if (LDAP_dn2principal
+	    (context, db, dn, &ent->modified_by->principal) != 0) {
+	    ent->modified_by->principal = NULL;
+	}
+	free(dn);
+    } else {
+	free(ent->modified_by);
+	ent->modified_by = NULL;
+    }
+
+    if ((ent->valid_start = (KerberosTime *) malloc(sizeof(KerberosTime)))
+	== NULL) {
+	ret = ENOMEM;
+	goto out;
+    }
+    ret =
+	LDAP_get_generalized_time_value(db, msg, "krb5ValidStart",
+					ent->valid_start);
+    if (ret != 0) {
+	/* OPTIONAL */
+	free(ent->valid_start);
+	ent->valid_start = NULL;
+    }
+
+    if ((ent->valid_end = (KerberosTime *) malloc(sizeof(KerberosTime))) ==
+	NULL) {ret = ENOMEM;
+	goto out;
+    }
+    ret =
+	LDAP_get_generalized_time_value(db, msg, "krb5ValidEnd",
+					ent->valid_end);
+    if (ret != 0) {
+	/* OPTIONAL */
+	free(ent->valid_end);
+	ent->valid_end = NULL;
+    }
+
+    if ((ent->pw_end = (KerberosTime *) malloc(sizeof(KerberosTime))) ==
+	NULL) {ret = ENOMEM;
+	goto out;
+    }
+    ret =
+	LDAP_get_generalized_time_value(db, msg, "krb5PasswordEnd",
+					ent->pw_end);
+    if (ret != 0) {
+	/* OPTIONAL */
+	free(ent->pw_end);
+	ent->pw_end = NULL;
+    }
+
+    ent->max_life = (int *) malloc(sizeof(int));
+    if (ent->max_life == NULL) {
+	ret = ENOMEM;
+	goto out;
+    }
+    ret = LDAP_get_integer_value(db, msg, "krb5MaxLife", ent->max_life);
+    if (ret != 0) {
+	free(ent->max_life);
+	ent->max_life = NULL;
+    }
+
+    ent->max_renew = (int *) malloc(sizeof(int));
+    if (ent->max_renew == NULL) {
+	ret = ENOMEM;
+	goto out;
+    }
+    ret = LDAP_get_integer_value(db, msg, "krb5MaxRenew", ent->max_renew);
+    if (ret != 0) {
+	free(ent->max_renew);
+	ent->max_renew = NULL;
+    }
+
+    values = ldap_get_values((LDAP *) db->db, msg, "krb5KDCFlags");
+    if (values != NULL) {
+	tmp = strtoul(values[0], (char **) NULL, 10);
+	if (tmp == ULONG_MAX && errno == ERANGE) {
+	    ret = ERANGE;
+	    goto out;
+	}
+    } else {
+	tmp = 0;
+    }
+    memcpy(&ent->flags, &tmp, sizeof(HDBFlags));
+
+    values = ldap_get_values((LDAP *) db->db, msg, "krb5EncryptionType");
+    if (values != NULL) {
+	int i;
+
+	ent->etypes = malloc(sizeof(*(ent->etypes)));
+	if (ent->etypes == NULL) {
+	    ret = ENOMEM;
+	    goto out;
+	}
+	ent->etypes->len = ldap_count_values(values);
+	ent->etypes->val = calloc(ent->etypes->len, sizeof(int));
+	for (i = 0; i < ent->etypes->len; i++) {
+	    ent->etypes->val[i] = atoi(values[i]);
+	}
+	ldap_value_free(values);
+    }
+
+    ret = 0;
+
+  out:
+    if (unparsed_name != NULL) {
+	free(unparsed_name);
+    }
+
+    if (ret != 0) {
+	/* I don't think this frees ent itself. */
+	hdb_free_entry(context, ent);
+    }
+
+    return ret;
+}
+
+static krb5_error_code LDAP_close(krb5_context context, HDB * db)
+{
+    LDAP *ld = (LDAP *) db->db;
+
+    ldap_unbind(ld);
+    db->db = NULL;
+    return 0;
+}
+
+static krb5_error_code
+LDAP_lock(krb5_context context, HDB * db, int operation)
+{
+    return 0;
+}
+
+static krb5_error_code LDAP_unlock(krb5_context context, HDB * db)
+{
+    return 0;
+}
+
+static krb5_error_code
+LDAP_seq(krb5_context context, HDB * db, unsigned flags, hdb_entry * entry)
+{
+    int msgid, rc, parserc;
+    krb5_error_code ret;
+    LDAPMessage *e;
+
+    msgid = db->openp;		/* BOGUS OVERLOADING */
+    if (msgid < 0) {
+	return HDB_ERR_NOENTRY;
+    }
+
+    do {
+	rc = ldap_result((LDAP *) db->db, msgid, LDAP_MSG_ONE, NULL, &e);
+	switch (rc) {
+	case LDAP_RES_SEARCH_ENTRY:
+	    /* We have an entry. Parse it. */
+	    ret = LDAP_message2entry(context, db, e, entry);
+	    ldap_msgfree(e);
+	    break;
+	case LDAP_RES_SEARCH_RESULT:
+	    /* We're probably at the end of the results. If not, abandon. */
+	    parserc =
+		ldap_parse_result((LDAP *) db->db, e, NULL, NULL, NULL,
+				  NULL, NULL, 1);
+	    if (parserc != LDAP_SUCCESS
+		&& parserc != LDAP_MORE_RESULTS_TO_RETURN) {
+		ldap_abandon((LDAP *) db->db, msgid);
+	    }
+	    ret = HDB_ERR_NOENTRY;
+	    db->openp = -1;
+	    break;
+	case 0:
+	case -1:
+	default:
+	    /* Some unspecified error (timeout?). Abandon. */
+	    ldap_msgfree(e);
+	    ldap_abandon((LDAP *) db->db, msgid);
+	    ret = HDB_ERR_NOENTRY;
+	    db->openp = -1;
+	    break;
+	}
+    } while (rc == LDAP_RES_SEARCH_REFERENCE);
+
+    if (ret == 0) {
+	if (db->master_key_set && (flags & HDB_F_DECRYPT)) {
+	    ret = hdb_unseal_keys(context, db, entry);
+	    if (ret)
+		hdb_free_entry(context,entry);
+	}
+    }
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP_firstkey(krb5_context context, HDB * db, unsigned flags,
+	      hdb_entry * entry)
+{
+    int msgid;
+
+    (void) LDAP__connect(context, db);
+
+    msgid = LDAP_NO_LIMIT;
+    (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, &msgid);
+
+    msgid = ldap_search((LDAP *) db->db, db->name,
+			LDAP_SCOPE_ONELEVEL, "(objectclass=krb5KDCEntry)",
+			krb5kdcentry_attrs, 0);
+    if (msgid < 0) {
+	return HDB_ERR_NOENTRY;
+    }
+
+    db->openp = msgid;
+
+    return LDAP_seq(context, db, flags, entry);
+}
+
+static krb5_error_code
+LDAP_nextkey(krb5_context context, HDB * db, unsigned flags,
+	     hdb_entry * entry)
+{
+    return LDAP_seq(context, db, flags, entry);
+}
+
+static krb5_error_code
+LDAP_rename(krb5_context context, HDB * db, const char *new_name)
+{
+    return HDB_ERR_DB_INUSE;
+}
+
+static krb5_boolean LDAP__is_user_namingcontext(const char *ctx,
+						char *const *subschema)
+{
+    char *const *p;
+
+    if (!strcasecmp(ctx, "CN=MONITOR")
+	|| !strcasecmp(ctx, "CN=CONFIG")) {
+	return FALSE;
+    }
+
+    if (subschema != NULL) {
+	for (p = subschema; *p != NULL; p++) {
+	    if (!strcasecmp(ctx, *p)) {
+		return FALSE;
+	    }
+	}
+    }
+
+    return TRUE;
+}
+
+static krb5_error_code LDAP__connect(krb5_context context, HDB * db)
+{
+    int rc;
+    krb5_error_code ret;
+    char *attrs[] = { "namingContexts", "subschemaSubentry", NULL };
+    LDAPMessage *res = NULL, *e;
+
+    if (db->db != NULL) {
+	/* connection has been opened. ping server. */
+	struct sockaddr_un addr;
+	socklen_t len;
+	int sd;
+
+	if (ldap_get_option((LDAP *) db->db, LDAP_OPT_DESC, &sd) == 0 &&
+	    getpeername(sd, (struct sockaddr *) &addr, &len) < 0) {
+	    /* the other end has died. reopen. */
+	    LDAP_close(context, db);
+	}
+    }
+
+    if (db->db != NULL) {
+	/* server is UP */
+	return 0;
+    }
+
+    rc = ldap_initialize((LDAP **) & db->db, "ldapi:///");
+    if (rc != LDAP_SUCCESS) {
+	return HDB_ERR_NOENTRY;
+    }
+
+    rc = LDAP_VERSION3;
+    (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_PROTOCOL_VERSION, &rc);
+
+    /* XXX set db->name to the search base */
+    rc = ldap_search_s((LDAP *) db->db, "", LDAP_SCOPE_BASE,
+		       "(objectclass=*)", attrs, 0, &res);
+    if (rc != LDAP_SUCCESS) {
+	ret = HDB_ERR_BADVERSION;
+	goto out;
+    }
+
+    e = ldap_first_entry((LDAP *) db->db, res);
+    if (e == NULL) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    if (db->name == NULL) {
+	char **contexts = NULL, **schema_contexts, **p;
+
+	contexts = ldap_get_values((LDAP *) db->db, e, "namingContexts");
+	if (contexts == NULL) {
+	    ret = HDB_ERR_NOENTRY;
+	    goto out;
+	}
+
+	schema_contexts =
+	    ldap_get_values((LDAP *) db->db, e, "subschemaSubentry");
+
+	if (db->name != NULL) {
+	    free(db->name);
+	    db->name = NULL;
+	}
+
+	for (p = contexts; *p != NULL; p++) {
+	    if (LDAP__is_user_namingcontext(*p, schema_contexts)) {
+		break;
+	    }
+	}
+
+	db->name = strdup(*p);
+	if (db->name == NULL) {
+	    ldap_value_free(contexts);
+	    ret = ENOMEM;
+	    goto out;
+	}
+
+	ldap_value_free(contexts);
+	if (schema_contexts != NULL) {
+	    ldap_value_free(schema_contexts);
+	}
+    }
+
+    ret = 0;
+
+  out:
+
+    if (res != NULL) {
+	ldap_msgfree(res);
+    }
+
+    if (ret != 0) {
+	if (db->db != NULL) {
+	    ldap_unbind((LDAP *) db->db);
+	    db->db = NULL;
+	}
+    }
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP_open(krb5_context context, HDB * db, int flags, mode_t mode)
+{
+    krb5_error_code ret;
+
+    /* Not the right place for this. */
+#ifdef HAVE_SIGACTION
+    {
+	struct sigaction sa;
+
+	sa.sa_flags = 0;
+	sa.sa_handler = SIG_IGN;
+	sigemptyset(&sa.sa_mask);
+
+	sigaction(SIGPIPE, &sa, NULL);
+    }
+#else
+    signal(SIGPIPE, SIG_IGN);
+#endif
+
+    if (db->name != NULL) {
+	free(db->name);
+	db->name = NULL;
+    }
+
+    ret = LDAP__connect(context, db);
+    if (ret != 0) {
+	return ret;
+    }
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP_fetch(krb5_context context, HDB * db, unsigned flags,
+	   hdb_entry * entry)
+{
+    LDAPMessage *msg, *e;
+    krb5_error_code ret;
+
+    ret = LDAP_principal2message(context, db, entry->principal, &msg);
+    if (ret != 0) {
+	return ret;
+    }
+
+    e = ldap_first_entry((LDAP *) db->db, msg);
+    if (e == NULL) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    ret = LDAP_message2entry(context, db, e, entry);
+    if (ret == 0) {
+	if (db->master_key_set && (flags & HDB_F_DECRYPT)) {
+	    ret = hdb_unseal_keys(context, db, entry);
+	    if (ret)
+		hdb_free_entry(context,entry);
+	}
+    }
+
+  out:
+    ldap_msgfree(msg);
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP_store(krb5_context context, HDB * db, unsigned flags,
+	   hdb_entry * entry)
+{
+    LDAPMod **mods = NULL;
+    krb5_error_code ret;
+    LDAPMessage *msg = NULL, *e = NULL;
+    char *dn = NULL, *name = NULL;
+
+    ret = krb5_unparse_name(context, entry->principal, &name);
+    if (ret != 0) {
+	goto out;
+    }
+
+    ret = LDAP__lookup_princ(context, db, name, &msg);
+    if (ret == 0) {
+	e = ldap_first_entry((LDAP *) db->db, msg);
+    }
+
+    ret = hdb_seal_keys(context, db, entry);
+    if (ret)
+	goto out;
+
+    /* turn new entry into LDAPMod array */
+    ret = LDAP_entry2mods(context, db, entry, e, &mods);
+    if (ret != 0) {
+	goto out;
+    }
+
+    if (e == NULL) {
+	/* Doesn't exist yet. */
+	char *p;
+
+	e = NULL;
+
+	/* normalize the naming attribute */
+	for (p = name; *p != '\0'; p++) {
+	    *p = (char) tolower((int) *p);
+	}
+
+	/*
+	 * We could do getpwnam() on the local component of
+	 * the principal to find cn/sn but that's probably
+	 * bad thing to do from inside a KDC. Better leave
+	 * it to management tools.
+	 */
+	ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "cn", name);
+	if (ret < 0) {
+	    goto out;
+	}
+
+	ret = LDAP_addmod(&mods, LDAP_MOD_ADD, "sn", name);
+	if (ret < 0) {
+	    goto out;
+	}
+
+	ret = asprintf(&dn, "cn=%s,%s", name, db->name);
+	if (ret < 0) {
+	    ret = ENOMEM;
+	    goto out;
+	}
+    } else if (flags & HDB_F_REPLACE) {
+	/* Entry exists, and we're allowed to replace it. */
+	dn = ldap_get_dn((LDAP *) db->db, e);
+    } else {
+	/* Entry exists, but we're not allowed to replace it. Bail. */
+	ret = HDB_ERR_EXISTS;
+	goto out;
+    }
+
+    /* write entry into directory */
+    if (e == NULL) {
+	/* didn't exist before */
+	ret = ldap_add_s((LDAP *) db->db, dn, mods);
+    } else {
+	/* already existed, send deltas only */
+	ret = ldap_modify_s((LDAP *) db->db, dn, mods);
+    }
+
+    if (ret == LDAP_SUCCESS) {
+	ret = 0;
+    } else {
+	ret = HDB_ERR_CANT_LOCK_DB;
+    }
+
+  out:
+    /* free stuff */
+    if (dn != NULL) {
+	free(dn);
+    }
+
+    if (msg != NULL) {
+	ldap_msgfree(msg);
+    }
+
+    if (mods != NULL) {
+	ldap_mods_free(mods, 1);
+    }
+
+    if (name != NULL) {
+	free(name);
+    }
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP_remove(krb5_context context, HDB * db, hdb_entry * entry)
+{
+    krb5_error_code ret;
+    LDAPMessage *msg, *e;
+    char *dn = NULL;
+
+    ret = LDAP_principal2message(context, db, entry->principal, &msg);
+    if (ret != 0) {
+	goto out;
+    }
+
+    e = ldap_first_entry((LDAP *) db->db, msg);
+    if (e == NULL) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    dn = ldap_get_dn((LDAP *) db->db, e);
+    if (dn == NULL) {
+	ret = HDB_ERR_NOENTRY;
+	goto out;
+    }
+
+    ret = LDAP_NO_LIMIT;
+    (void) ldap_set_option((LDAP *) db->db, LDAP_OPT_SIZELIMIT, &ret);
+
+    ret = ldap_delete_s((LDAP *) db->db, dn);
+    if (ret == LDAP_SUCCESS) {
+	ret = 0;
+    } else {
+	ret = HDB_ERR_CANT_LOCK_DB;
+    }
+
+  out:
+    if (dn != NULL) {
+	free(dn);
+    }
+
+    if (msg != NULL) {
+	ldap_msgfree(msg);
+    }
+
+    return ret;
+}
+
+static krb5_error_code
+LDAP__get(krb5_context context, HDB * db, krb5_data key, krb5_data * reply)
+{
+    fprintf(stderr, "LDAP__get not implemented\n");
+    abort();
+    return 0;
+}
+
+static krb5_error_code
+LDAP__put(krb5_context context, HDB * db, int replace,
+	  krb5_data key, krb5_data value)
+{
+    fprintf(stderr, "LDAP__put not implemented\n");
+    abort();
+    return 0;
+}
+
+static krb5_error_code
+LDAP__del(krb5_context context, HDB * db, krb5_data key)
+{
+    fprintf(stderr, "LDAP__del not implemented\n");
+    abort();
+    return 0;
+}
+
+static krb5_error_code LDAP_destroy(krb5_context context, HDB * db)
+{
+    krb5_error_code ret;
+
+    ret = hdb_clear_master_key(context, db);
+    free(db->name);
+    free(db);
+
+    return ret;
+}
+
+krb5_error_code
+hdb_ldap_create(krb5_context context, HDB ** db, const char *filename)
+{
+    *db = malloc(sizeof(**db));
+    if (*db == NULL)
+	return ENOMEM;
+
+    (*db)->db = NULL;
+/*    (*db)->name = strdup(filename); */
+    (*db)->name = NULL;
+    (*db)->master_key_set = 0;
+    (*db)->openp = 0;
+    (*db)->open = LDAP_open;
+    (*db)->close = LDAP_close;
+    (*db)->fetch = LDAP_fetch;
+    (*db)->store = LDAP_store;
+    (*db)->remove = LDAP_remove;
+    (*db)->firstkey = LDAP_firstkey;
+    (*db)->nextkey = LDAP_nextkey;
+    (*db)->lock = LDAP_lock;
+    (*db)->unlock = LDAP_unlock;
+    (*db)->rename = LDAP_rename;
+    /* can we ditch these? */
+    (*db)->_get = LDAP__get;
+    (*db)->_put = LDAP__put;
+    (*db)->_del = LDAP__del;
+    (*db)->destroy = LDAP_destroy;
+
+    return 0;
+}
+
+#endif				/* OPENLDAP */
diff --git a/crypto/heimdal/lib/hdb/mkey.c b/crypto/heimdal/lib/hdb/mkey.c
new file mode 100644
index 000000000000..2c853334f398
--- /dev/null
+++ b/crypto/heimdal/lib/hdb/mkey.c
@@ -0,0 +1,475 @@
+/*
+ * Copyright (c) 2000 - 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 "hdb_locl.h"
+#ifndef O_BINARY
+#define O_BINARY 0
+#endif
+
+RCSID("$Id: mkey.c,v 1.8 2001/01/30 01:20:57 assar Exp $");
+
+struct hdb_master_key_data {
+    krb5_keytab_entry keytab;
+    krb5_crypto crypto;
+    struct hdb_master_key_data *next;
+};
+
+void
+hdb_free_master_key(krb5_context context, hdb_master_key mkey)
+{
+    struct hdb_master_key_data *ptr;
+    while(mkey) {
+	krb5_kt_free_entry(context, &mkey->keytab);
+	krb5_crypto_destroy(context, mkey->crypto);
+	ptr = mkey;
+	mkey = mkey->next;
+	free(ptr);
+    }
+}
+
+krb5_error_code
+hdb_process_master_key(krb5_context context,
+		       int kvno, krb5_keyblock *key, krb5_enctype etype,
+		       hdb_master_key *mkey)
+{
+    krb5_error_code ret;
+    *mkey = calloc(1, sizeof(**mkey));
+    if(*mkey == NULL)
+	return ENOMEM;
+    (*mkey)->keytab.vno = kvno;
+    ret = krb5_parse_name(context, "K/M", &(*mkey)->keytab.principal);
+    ret = krb5_copy_keyblock_contents(context, key, &(*mkey)->keytab.keyblock);
+    if(ret) {
+	free(*mkey);
+	*mkey = NULL;
+	return ret;
+    }
+    if(etype != 0)
+	(*mkey)->keytab.keyblock.keytype = etype;
+    (*mkey)->keytab.timestamp = time(NULL);
+    ret = krb5_crypto_init(context, key, etype, &(*mkey)->crypto);
+    if(ret) {
+	krb5_free_keyblock_contents(context, &(*mkey)->keytab.keyblock);
+	free(*mkey);
+	*mkey = NULL;
+    }
+    return ret;
+}
+
+krb5_error_code
+hdb_add_master_key(krb5_context context, krb5_keyblock *key,
+		   hdb_master_key *inout)
+{
+    int vno = 0;
+    hdb_master_key p;
+    krb5_error_code ret;
+
+    for(p = *inout; p; p = p->next)
+	vno = max(vno, p->keytab.vno);
+    vno++;
+    ret = hdb_process_master_key(context, vno, key, 0, &p);
+    if(ret)
+	return ret;
+    p->next = *inout;
+    *inout = p;
+    return 0;
+}
+
+static krb5_error_code
+read_master_keytab(krb5_context context, const char *filename, 
+		   hdb_master_key *mkey)
+{
+    krb5_error_code ret;
+    krb5_keytab id;
+    krb5_kt_cursor cursor;
+    krb5_keytab_entry entry;
+    hdb_master_key p;
+    
+    ret = krb5_kt_resolve(context, filename, &id);
+    if(ret)
+	return ret;
+
+    ret = krb5_kt_start_seq_get(context, id, &cursor);
+    if(ret)
+	goto out;
+    *mkey = NULL;
+    while(krb5_kt_next_entry(context, id, &entry, &cursor) == 0) {
+	p = calloc(1, sizeof(*p));
+	p->keytab = entry;
+	ret = krb5_crypto_init(context, &p->keytab.keyblock, 0, &p->crypto);
+	p->next = *mkey;
+	*mkey = p;
+    }
+    krb5_kt_end_seq_get(context, id, &cursor);
+  out:
+    krb5_kt_close(context, id);
+    return ret;
+}
+
+/* read a MIT master keyfile */
+static krb5_error_code
+read_master_mit(krb5_context context, const char *filename, 
+		hdb_master_key *mkey)
+{
+    int fd;
+    krb5_error_code ret;
+    krb5_storage *sp;
+    u_int16_t enctype;
+    krb5_keyblock key;
+	       
+    fd = open(filename, O_RDONLY | O_BINARY);
+    if(fd < 0)
+	return errno;
+    sp = krb5_storage_from_fd(fd);
+    if(sp == NULL) {
+	close(fd);
+	return errno;
+    }
+    krb5_storage_set_flags(sp, KRB5_STORAGE_HOST_BYTEORDER);
+#if 0
+    /* could possibly use ret_keyblock here, but do it with more
+       checks for now */
+    ret = krb5_ret_keyblock(sp, &key);
+#else
+    ret = krb5_ret_int16(sp, &enctype);
+    if((htons(enctype) & 0xff00) == 0x3000) {
+	ret = HEIM_ERR_BAD_MKEY;
+	goto out;
+    }
+    key.keytype = enctype;
+    ret = krb5_ret_data(sp, &key.keyvalue);
+    if(ret)
+	goto out;
+#endif
+    ret = hdb_process_master_key(context, 0, &key, 0, mkey);
+    krb5_free_keyblock_contents(context, &key);
+  out:
+    krb5_storage_free(sp);
+    close(fd);
+    return ret;
+}
+
+/* read an old master key file */
+static krb5_error_code
+read_master_encryptionkey(krb5_context context, const char *filename, 
+			  hdb_master_key *mkey)
+{
+    int fd;
+    krb5_keyblock key;
+    krb5_error_code ret;
+    unsigned char buf[256];
+    ssize_t len;
+	       
+    fd = open(filename, O_RDONLY | O_BINARY);
+    if(fd < 0)
+	return errno;
+    
+    len = read(fd, buf, sizeof(buf));
+    close(fd);
+    if(len < 0)
+	return errno;
+
+    ret = decode_EncryptionKey(buf, len, &key, &len);
+    memset(buf, 0, sizeof(buf));
+    if(ret)
+	return ret;
+
+    /* Originally, the keytype was just that, and later it got changed
+       to des-cbc-md5, but we always used des in cfb64 mode. This
+       should cover all cases, but will break if someone has hacked
+       this code to really use des-cbc-md5 -- but then that's not my
+       problem. */
+    if(key.keytype == KEYTYPE_DES || key.keytype == ETYPE_DES_CBC_MD5)
+	key.keytype = ETYPE_DES_CFB64_NONE;
+    
+    ret = hdb_process_master_key(context, 0, &key, 0, mkey);
+    krb5_free_keyblock_contents(context, &key);
+    return ret;
+}
+
+/* read a krb4 /.k style file */
+static krb5_error_code
+read_master_krb4(krb5_context context, const char *filename, 
+		 hdb_master_key *mkey)
+{
+    int fd;
+    krb5_keyblock key;
+    krb5_error_code ret;
+    unsigned char buf[256];
+    ssize_t len;
+	       
+    fd = open(filename, O_RDONLY | O_BINARY);
+    if(fd < 0)
+	return errno;
+    
+    len = read(fd, buf, sizeof(buf));
+    close(fd);
+    if(len < 0)
+	return errno;
+
+    memset(&key, 0, sizeof(key));
+    key.keytype = ETYPE_DES_PCBC_NONE;
+    ret = krb5_data_copy(&key.keyvalue, buf, len);
+    memset(buf, 0, sizeof(buf));
+    if(ret) 
+	return ret;
+
+    ret = hdb_process_master_key(context, 0, &key, 0, mkey);
+    krb5_free_keyblock_contents(context, &key);
+    return ret;
+}
+
+krb5_error_code
+hdb_read_master_key(krb5_context context, const char *filename, 
+		    hdb_master_key *mkey)
+{
+    FILE *f;
+    unsigned char buf[16];
+    krb5_error_code ret;
+
+    off_t len;
+
+    *mkey = NULL;
+
+    if(filename == NULL)
+	filename = HDB_DB_DIR "/m-key";
+
+    f = fopen(filename, "r");
+    if(f == NULL)
+	return errno;
+    
+    if(fread(buf, 1, 2, f) != 2) {
+	fclose(f);
+	return HEIM_ERR_EOF;
+    }
+    
+    fseek(f, 0, SEEK_END);
+    len = ftell(f);
+
+    if(fclose(f) != 0)
+	return errno;
+    
+    if(len < 0)
+	return errno;
+    
+    if(len == 8) {
+	ret = read_master_krb4(context, filename, mkey);
+    } else if(buf[0] == 0x30 && len <= 127 && buf[1] == len - 2) {
+	ret = read_master_encryptionkey(context, filename, mkey);
+    } else if(buf[0] == 5 && buf[1] >= 1 && buf[1] <= 2) {
+	ret = read_master_keytab(context, filename, mkey);
+    } else {
+	ret = read_master_mit(context, filename, mkey);
+    }
+    return ret;
+}
+
+krb5_error_code
+hdb_write_master_key(krb5_context context, const char *filename, 
+		     hdb_master_key mkey)
+{
+    krb5_error_code ret;
+    hdb_master_key p;
+    krb5_keytab kt;
+
+    if(filename == NULL)
+	filename = HDB_DB_DIR "/m-key";
+
+    ret = krb5_kt_resolve(context, filename, &kt);
+    if(ret)
+	return ret;
+
+    for(p = mkey; p; p = p->next) {
+	ret = krb5_kt_add_entry(context, kt, &p->keytab);
+    }
+
+    krb5_kt_close(context, kt);
+
+    return ret;
+}
+
+static hdb_master_key
+find_master_key(Key *key, hdb_master_key mkey)
+{
+    hdb_master_key ret = NULL;
+    while(mkey) {
+	if(ret == NULL && mkey->keytab.vno == 0)
+	    ret = mkey;
+	if(key->mkvno == NULL) {
+	    if(ret == NULL || mkey->keytab.vno > ret->keytab.vno)
+		ret = mkey;
+	} else if(mkey->keytab.vno == *key->mkvno)
+	    return mkey;
+	mkey = mkey->next;
+    }
+    return ret;
+}
+
+krb5_error_code
+hdb_unseal_keys_mkey(krb5_context context, hdb_entry *ent, hdb_master_key mkey)
+{
+    int i;
+    krb5_error_code ret;
+    krb5_data res;
+    Key *k;
+
+    for(i = 0; i < ent->keys.len; i++){
+	hdb_master_key key;
+
+	k = &ent->keys.val[i];
+	if(k->mkvno == NULL)
+	    continue;
+
+	key = find_master_key(&ent->keys.val[i], mkey);
+
+	if (key == NULL)
+	    return HDB_ERR_NO_MKEY;
+
+	ret = krb5_decrypt(context, key->crypto, HDB_KU_MKEY,
+			   k->key.keyvalue.data,
+			   k->key.keyvalue.length,
+			   &res);
+	if (ret)
+	    return ret;
+
+	memset(k->key.keyvalue.data, 0, k->key.keyvalue.length);
+	free(k->key.keyvalue.data);
+	k->key.keyvalue = res;
+	free(k->mkvno);
+	k->mkvno = NULL;
+    }
+    return 0;
+}
+
+krb5_error_code
+hdb_unseal_keys(krb5_context context, HDB *db, hdb_entry *ent)
+{
+    if (db->master_key_set == 0)
+	return 0;
+    return hdb_unseal_keys_mkey(context, ent, db->master_key);
+}
+
+krb5_error_code
+hdb_seal_keys_mkey(krb5_context context, hdb_entry *ent, hdb_master_key mkey)
+{
+    int i;
+    krb5_error_code ret;
+    krb5_data res;
+    for(i = 0; i < ent->keys.len; i++){
+	Key *k = &ent->keys.val[i];
+	hdb_master_key key;
+
+	if(k->mkvno != NULL)
+	    continue;
+
+	key = find_master_key(k, mkey);
+
+	if (key == NULL)
+	    return HDB_ERR_NO_MKEY;
+
+	ret = krb5_encrypt(context, key->crypto, HDB_KU_MKEY,
+			   k->key.keyvalue.data,
+			   k->key.keyvalue.length,
+			   &res);
+	if (ret)
+	    return ret;
+
+	memset(k->key.keyvalue.data, 0, k->key.keyvalue.length);
+	free(k->key.keyvalue.data);
+	k->key.keyvalue = res;
+
+	k->mkvno = malloc(sizeof(*k->mkvno));
+	if (k->mkvno == NULL)
+	    return ENOMEM;
+	*k->mkvno = key->keytab.vno;
+    }
+    return 0;
+}
+
+krb5_error_code
+hdb_seal_keys(krb5_context context, HDB *db, hdb_entry *ent)
+{
+    if (db->master_key_set == 0)
+	return 0;
+    
+    return hdb_seal_keys_mkey(context, ent, db->master_key);
+}
+
+krb5_error_code
+hdb_set_master_key (krb5_context context,
+		    HDB *db,
+		    krb5_keyblock *key)
+{
+    krb5_error_code ret;
+    hdb_master_key mkey;
+
+    ret = hdb_process_master_key(context, 0, key, 0, &mkey);
+    if (ret)
+	return ret;
+    db->master_key = mkey;
+#if 0 /* XXX - why? */
+    des_set_random_generator_seed(key.keyvalue.data);
+#endif
+    db->master_key_set = 1;
+    return 0;
+}
+
+krb5_error_code
+hdb_set_master_keyfile (krb5_context context,
+			HDB *db,
+			const char *keyfile)
+{
+    hdb_master_key key;
+    krb5_error_code ret;
+
+    ret = hdb_read_master_key(context, keyfile, &key);
+    if (ret) {
+	if (ret != ENOENT)
+	    return ret;
+	return 0;
+    }
+    db->master_key = key;
+    db->master_key_set = 1;
+    return ret;
+}
+
+krb5_error_code
+hdb_clear_master_key (krb5_context context,
+		      HDB *db)
+{
+    if (db->master_key_set) {
+	hdb_free_master_key(context, db->master_key);
+	db->master_key_set = 0;
+    }
+    return 0;
+}
diff --git a/crypto/heimdal/lib/kadm5/bump_pw_expire.c b/crypto/heimdal/lib/kadm5/bump_pw_expire.c
new file mode 100644
index 000000000000..a185c20daff2
--- /dev/null
+++ b/crypto/heimdal/lib/kadm5/bump_pw_expire.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include "kadm5_locl.h"
+
+RCSID("$Id: bump_pw_expire.c,v 1.1 2000/07/24 03:47:54 assar Exp $");
+
+/*
+ * extend password_expiration if it's defined
+ */
+
+kadm5_ret_t
+_kadm5_bump_pw_expire(kadm5_server_context *context,
+		      hdb_entry *ent)
+{
+    if (ent->pw_end != NULL) {
+	time_t life;
+
+	life = krb5_config_get_time_default(context->context,
+					    NULL,
+					    365 * 24 * 60 * 60,
+					    "kadmin",
+					    "password_lifetime",
+					    NULL);
+
+	*(ent->pw_end) = time(NULL) + life;
+    }
+    return 0;
+}
diff --git a/crypto/heimdal/lib/kadm5/kadm5-private.h b/crypto/heimdal/lib/kadm5/kadm5-private.h
new file mode 100644
index 000000000000..4e74a2be1442
--- /dev/null
+++ b/crypto/heimdal/lib/kadm5/kadm5-private.h
@@ -0,0 +1,245 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+/* $Id: kadm5-private.h,v 1.3 2000/07/24 04:31:17 assar Exp $ */
+
+#ifndef __kadm5_privatex_h__
+#define __kadm5_privatex_h__
+
+kadm5_ret_t _kadm5_privs_to_string (u_int32_t, char*, size_t);
+
+kadm5_ret_t _kadm5_string_to_privs (const char*, u_int32_t*);
+
+HDB *_kadm5_s_get_db (void *);
+
+kadm5_ret_t
+_kadm5_acl_check_permission __P((
+	kadm5_server_context *context,
+	unsigned op,
+	krb5_const_principal princ));
+
+kadm5_ret_t
+_kadm5_acl_init __P((kadm5_server_context *context));
+
+kadm5_ret_t
+_kadm5_c_init_context __P((
+	kadm5_client_context **ctx,
+	kadm5_config_params *params,
+	krb5_context context));
+
+kadm5_ret_t
+_kadm5_client_recv __P((
+	kadm5_client_context *context,
+	krb5_data *reply));
+
+kadm5_ret_t
+_kadm5_client_send __P((
+	kadm5_client_context *context,
+	krb5_storage *sp));
+
+kadm5_ret_t
+_kadm5_connect __P((void*));
+
+kadm5_ret_t
+_kadm5_error_code __P((kadm5_ret_t code));
+
+kadm5_ret_t
+_kadm5_s_init_context __P((
+	kadm5_server_context **ctx,
+	kadm5_config_params *params,
+	krb5_context context));
+
+kadm5_ret_t
+_kadm5_set_keys __P((
+	kadm5_server_context *context,
+	hdb_entry *ent,
+	const char *password));
+
+kadm5_ret_t
+_kadm5_set_keys2 __P((
+	kadm5_server_context *context,
+	hdb_entry *ent, 
+	int16_t n_key_data, 
+	krb5_key_data *key_data));
+
+kadm5_ret_t
+_kadm5_set_keys3 __P((
+	kadm5_server_context *context,
+	hdb_entry *ent, 
+	int n_keys,
+	krb5_keyblock *keyblocks));
+
+kadm5_ret_t
+_kadm5_set_keys_randomly __P((kadm5_server_context *context,
+			      hdb_entry *ent,
+			      krb5_keyblock **new_keys,
+			      int *n_keys));
+
+kadm5_ret_t
+_kadm5_set_modifier __P((
+	kadm5_server_context *context,
+	hdb_entry *ent));
+
+kadm5_ret_t
+_kadm5_bump_pw_expire __P((kadm5_server_context *context,
+			   hdb_entry *ent));
+
+kadm5_ret_t
+_kadm5_setup_entry __P((
+	kadm5_server_context *context,
+	hdb_entry *ent,
+	u_int32_t mask,
+	kadm5_principal_ent_t princ,
+	u_int32_t princ_mask,
+	kadm5_principal_ent_t def,
+	u_int32_t def_mask));
+
+kadm5_ret_t
+kadm5_log_get_version_fd (int fd, u_int32_t *ver);
+
+kadm5_ret_t
+kadm5_log_get_version (kadm5_server_context *context, u_int32_t *ver);
+
+kadm5_ret_t
+kadm5_log_set_version (kadm5_server_context *context, u_int32_t vno);
+
+kadm5_ret_t
+kadm5_log_init (kadm5_server_context *context);
+
+kadm5_ret_t
+kadm5_log_reinit (kadm5_server_context *context);
+
+kadm5_ret_t
+kadm5_log_create (kadm5_server_context *context,
+		  hdb_entry *ent);
+
+kadm5_ret_t
+kadm5_log_delete (kadm5_server_context *context,
+		  krb5_principal princ);
+
+kadm5_ret_t
+kadm5_log_rename (kadm5_server_context *context,
+		  krb5_principal source,
+		  hdb_entry *ent);
+
+kadm5_ret_t
+kadm5_log_modify (kadm5_server_context *context,
+		  hdb_entry *ent,
+		  u_int32_t mask);
+
+kadm5_ret_t
+kadm5_log_nop (kadm5_server_context *context);
+
+kadm5_ret_t
+kadm5_log_end (kadm5_server_context *context);
+
+kadm5_ret_t
+kadm5_log_foreach (kadm5_server_context *context,
+		   void (*func)(kadm5_server_context *server_context,
+				u_int32_t ver,
+				time_t timestamp,
+				enum kadm_ops op,
+				u_int32_t len,
+				krb5_storage *sp));
+
+kadm5_ret_t
+kadm5_log_replay_create (kadm5_server_context *context,
+			 u_int32_t ver,
+			 u_int32_t len,
+			 krb5_storage *sp);
+
+kadm5_ret_t
+kadm5_log_replay_delete (kadm5_server_context *context,
+			 u_int32_t ver,
+			 u_int32_t len,
+			 krb5_storage *sp);
+
+kadm5_ret_t
+kadm5_log_replay_rename (kadm5_server_context *context,
+			 u_int32_t ver,
+			 u_int32_t len,
+			 krb5_storage *sp);
+
+kadm5_ret_t
+kadm5_log_replay_modify (kadm5_server_context *context,
+			 u_int32_t ver,
+			 u_int32_t len,
+			 krb5_storage *sp);
+
+kadm5_ret_t
+kadm5_log_replay_nop (kadm5_server_context *context,
+		      u_int32_t ver,
+		      u_int32_t len,
+		      krb5_storage *sp);
+
+kadm5_ret_t
+kadm5_log_replay (kadm5_server_context *context,
+		  enum kadm_ops op,
+		  u_int32_t ver,
+		  u_int32_t len,
+		  krb5_storage *sp);
+
+krb5_storage *
+kadm5_log_goto_end (int fd);
+
+kadm5_ret_t
+kadm5_log_previous (krb5_storage *sp,
+		    u_int32_t *ver,
+		    time_t *timestamp,
+		    enum kadm_ops *op,
+		    u_int32_t *len);
+
+kadm5_ret_t
+kadm5_log_truncate (kadm5_server_context *server_context);
+
+kadm5_ret_t
+_kadm5_marshal_params __P((krb5_context context, 
+			   kadm5_config_params *params, 
+			   krb5_data *out));
+
+kadm5_ret_t
+_kadm5_unmarshal_params __P((krb5_context context,
+			     krb5_data *in,
+			     kadm5_config_params *params));
+
+void
+_kadm5_free_keys (kadm5_server_context *context,
+		  int len, Key *keys);
+
+void
+_kadm5_init_keys (Key *keys, int len);
+
+int
+_kadm5_cmp_keys(Key *keys1, int len1, Key *keys2, int len2);
+
+#endif /* __kadm5_privatex_h__ */
diff --git a/crypto/heimdal/lib/kadm5/kadm5-protos.h b/crypto/heimdal/lib/kadm5/kadm5-protos.h
new file mode 100644
index 000000000000..070492bb4a57
--- /dev/null
+++ b/crypto/heimdal/lib/kadm5/kadm5-protos.h
@@ -0,0 +1,516 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+/* $Id: kadm5-protos.h,v 1.2 2000/07/22 05:52:01 assar Exp $ */
+
+#ifndef __kadm5_protos_h__
+#define __kadm5_protos_h__
+
+kadm5_ret_t
+kadm5_c_chpass_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	char *password));
+
+kadm5_ret_t
+kadm5_c_chpass_principal_with_key __P((
+	void *server_handle,
+	krb5_principal princ,
+	int n_key_data,
+	krb5_key_data *key_data));
+
+kadm5_ret_t
+kadm5_c_create_principal __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask,
+	char *password));
+
+kadm5_ret_t
+kadm5_c_delete_principal __P((
+	void *server_handle,
+	krb5_principal princ));
+
+kadm5_ret_t
+kadm5_c_destroy __P((void *server_handle));
+
+kadm5_ret_t
+kadm5_c_flush __P((void *server_handle));
+
+kadm5_ret_t
+kadm5_c_get_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	kadm5_principal_ent_t out,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_c_get_principals __P((
+	void *server_handle,
+	const char *exp,
+	char ***princs,
+	int *count));
+
+kadm5_ret_t
+kadm5_c_get_privs __P((
+	void *server_handle,
+	u_int32_t *privs));
+
+kadm5_ret_t
+kadm5_c_init_with_creds __P((
+	const char *client_name,
+	krb5_ccache ccache,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_c_init_with_creds_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	krb5_ccache ccache,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_c_init_with_password __P((
+	const char *client_name,
+	const char *password,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_c_init_with_password_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	const char *password,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_c_init_with_skey __P((
+	const char *client_name,
+	const char *keytab,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_c_init_with_skey_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	const char *keytab,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_c_modify_principal __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_c_randkey_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	krb5_keyblock **new_keys,
+	int *n_keys));
+
+kadm5_ret_t
+kadm5_c_rename_principal __P((
+	void *server_handle,
+	krb5_principal source,
+	krb5_principal target));
+
+kadm5_ret_t
+kadm5_chpass_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	char *password));
+
+kadm5_ret_t
+kadm5_chpass_principal_with_key __P((
+	void *server_handle,
+	krb5_principal princ,
+	int n_key_data,
+	krb5_key_data *key_data));
+
+kadm5_ret_t
+kadm5_create_principal __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask,
+	char *password));
+
+kadm5_ret_t
+kadm5_delete_principal __P((
+	void *server_handle,
+	krb5_principal princ));
+
+kadm5_ret_t
+kadm5_destroy __P((void *server_handle));
+
+kadm5_ret_t
+kadm5_flush __P((void *server_handle));
+
+void
+kadm5_free_key_data __P((
+	void *server_handle,
+	int16_t *n_key_data,
+	krb5_key_data *key_data));
+
+void
+kadm5_free_name_list __P((
+	void *server_handle,
+	char **names,
+	int *count));
+
+void
+kadm5_free_principal_ent __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ));
+
+kadm5_ret_t
+kadm5_get_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	kadm5_principal_ent_t out,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_get_principals __P((
+	void *server_handle,
+	const char *exp,
+	char ***princs,
+	int *count));
+
+kadm5_ret_t
+kadm5_get_privs __P((
+	void *server_handle,
+	u_int32_t *privs));
+
+kadm5_ret_t
+kadm5_init_with_creds __P((
+	const char *client_name,
+	krb5_ccache ccache,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_init_with_creds_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	krb5_ccache ccache,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_init_with_password __P((
+	const char *client_name,
+	const char *password,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_init_with_password_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	const char *password,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_init_with_skey __P((
+	const char *client_name,
+	const char *keytab,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_init_with_skey_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	const char *keytab,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_modify_principal __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_randkey_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	krb5_keyblock **new_keys,
+	int *n_keys));
+
+kadm5_ret_t
+kadm5_rename_principal __P((
+	void *server_handle,
+	krb5_principal source,
+	krb5_principal target));
+
+kadm5_ret_t
+kadm5_ret_key_data __P((
+	krb5_storage *sp,
+	krb5_key_data *key));
+
+kadm5_ret_t
+kadm5_ret_principal_ent __P((
+	krb5_storage *sp,
+	kadm5_principal_ent_t princ));
+
+kadm5_ret_t
+kadm5_ret_principal_ent_mask __P((
+	krb5_storage *sp,
+	kadm5_principal_ent_t princ,
+	u_int32_t *mask));
+
+kadm5_ret_t
+kadm5_ret_tl_data __P((
+	krb5_storage *sp,
+	krb5_tl_data *tl));
+
+kadm5_ret_t
+kadm5_s_chpass_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	char *password));
+
+kadm5_ret_t
+kadm5_s_chpass_principal_cond __P((
+	void *server_handle,
+	krb5_principal princ,
+	char *password));
+
+kadm5_ret_t
+kadm5_s_chpass_principal_with_key __P((
+	void *server_handle,
+	krb5_principal princ,
+	int n_key_data,
+	krb5_key_data *key_data));
+
+kadm5_ret_t
+kadm5_s_create_principal __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask,
+	char *password));
+
+kadm5_ret_t
+kadm5_s_create_principal_with_key __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_s_delete_principal __P((
+	void *server_handle,
+	krb5_principal princ));
+
+kadm5_ret_t
+kadm5_s_destroy __P((void *server_handle));
+
+kadm5_ret_t
+kadm5_s_flush __P((void *server_handle));
+
+kadm5_ret_t
+kadm5_s_get_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	kadm5_principal_ent_t out,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_s_get_principals __P((
+	void *server_handle,
+	const char *exp,
+	char ***princs,
+	int *count));
+
+kadm5_ret_t
+kadm5_s_get_privs __P((
+	void *server_handle,
+	u_int32_t *privs));
+
+kadm5_ret_t
+kadm5_s_init_with_creds __P((
+	const char *client_name,
+	krb5_ccache ccache,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_s_init_with_creds_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	krb5_ccache ccache,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_s_init_with_password __P((
+	const char *client_name,
+	const char *password,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_s_init_with_password_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	const char *password,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_s_init_with_skey __P((
+	const char *client_name,
+	const char *keytab,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_s_init_with_skey_ctx __P((
+	krb5_context context,
+	const char *client_name,
+	const char *keytab,
+	const char *service_name,
+	kadm5_config_params *realm_params,
+	unsigned long struct_version,
+	unsigned long api_version,
+	void **server_handle));
+
+kadm5_ret_t
+kadm5_s_modify_principal __P((
+	void *server_handle,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_s_randkey_principal __P((
+	void *server_handle,
+	krb5_principal princ,
+	krb5_keyblock **new_keys,
+	int *n_keys));
+
+kadm5_ret_t
+kadm5_s_rename_principal __P((
+	void *server_handle,
+	krb5_principal source,
+	krb5_principal target));
+
+kadm5_ret_t
+kadm5_store_key_data __P((
+	krb5_storage *sp,
+	krb5_key_data *key));
+
+kadm5_ret_t
+kadm5_store_principal_ent __P((
+	krb5_storage *sp,
+	kadm5_principal_ent_t princ));
+
+kadm5_ret_t
+kadm5_store_principal_ent_mask __P((
+	krb5_storage *sp,
+	kadm5_principal_ent_t princ,
+	u_int32_t mask));
+
+kadm5_ret_t
+kadm5_store_tl_data __P((
+	krb5_storage *sp,
+	krb5_tl_data *tl));
+
+void
+kadm5_setup_passwd_quality_check(krb5_context context,
+				 const char *check_library,
+				 const char *check_function);
+
+const char *
+kadm5_check_password_quality (krb5_context context,
+			      krb5_principal principal,
+			      krb5_data *pwd_data);
+
+#endif /* __kadm5_protos_h__ */
diff --git a/crypto/heimdal/lib/kadm5/keys.c b/crypto/heimdal/lib/kadm5/keys.c
new file mode 100644
index 000000000000..3ae21abb4761
--- /dev/null
+++ b/crypto/heimdal/lib/kadm5/keys.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 1997 - 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. 
+ */
+
+#include "kadm5_locl.h"
+
+RCSID("$Id: keys.c,v 1.1 2000/07/22 05:53:02 assar Exp $");
+
+/*
+ * free all the memory used by (len, keys)
+ */
+
+void
+_kadm5_free_keys (kadm5_server_context *context,
+		  int len, Key *keys)
+{
+    int i;
+
+    for (i = 0; i < len; ++i) {
+	free (keys[i].mkvno);
+	keys[i].mkvno = NULL;
+	if (keys[i].salt != NULL) {
+	    free_Salt(keys[i].salt);
+	    free(keys[i].salt);
+	    keys[i].salt = NULL;
+	}
+	krb5_free_keyblock_contents(context->context, &keys[i].key);
+    }
+    free (keys);
+}
+
+/*
+ * null-ify `len', `keys'
+ */
+
+void
+_kadm5_init_keys (Key *keys, int len)
+{
+    int i;
+
+    for (i = 0; i < len; ++i) {
+	keys[i].mkvno               = NULL;
+	keys[i].salt                = NULL;
+	keys[i].key.keyvalue.length = 0;
+	keys[i].key.keyvalue.data   = NULL;
+    }
+}
+
+/*
+ * return 0 iff `keys1, len1' and `keys2, len2' are identical
+ */
+
+int
+_kadm5_cmp_keys(Key *keys1, int len1, Key *keys2, int len2)
+{
+    int i;
+
+    if (len1 != len2)
+	return 1;
+
+    for (i = 0; i < len1; ++i) {
+	if ((keys1[i].salt != NULL && keys2[i].salt == NULL)
+	    || (keys1[i].salt == NULL && keys2[i].salt != NULL))
+	    return 1;
+	if (keys1[i].salt != NULL) {
+	    if (keys1[i].salt->type != keys2[i].salt->type)
+		return 1;
+	    if (keys1[i].salt->salt.length != keys2[i].salt->salt.length)
+		return 1;
+	    if (memcmp (keys1[i].salt->salt.data, keys2[i].salt->salt.data,
+			keys1[i].salt->salt.length) != 0)
+		return 1;
+	}
+	if (keys1[i].key.keytype != keys2[i].key.keytype)
+	    return 1;
+	if (keys1[i].key.keyvalue.length != keys2[i].key.keyvalue.length)
+	    return 1;
+	if (memcmp (keys1[i].key.keyvalue.data, keys2[i].key.keyvalue.data,
+		    keys1[i].key.keyvalue.length) != 0)
+	    return 1;
+    }
+    return 0;
+}
diff --git a/crypto/heimdal/lib/kadm5/truncate_log.c b/crypto/heimdal/lib/kadm5/truncate_log.c
new file mode 100644
index 000000000000..215fdd7d3cb3
--- /dev/null
+++ b/crypto/heimdal/lib/kadm5/truncate_log.c
@@ -0,0 +1,88 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include "iprop.h"
+
+RCSID("$Id: truncate_log.c,v 1.1 2000/07/24 04:27:06 assar Exp $");
+
+static char *realm;
+static int version_flag;
+static int help_flag;
+
+static struct getargs args[] = {
+    { "realm", 'r', arg_string, &realm },
+    { "version", 0, arg_flag, &version_flag },
+    { "help", 0, arg_flag, &help_flag }
+};
+
+static int num_args = sizeof(args) / sizeof(args[0]);
+
+int
+main(int argc, char **argv)
+{
+    krb5_context context;
+    krb5_error_code ret;
+    void *kadm_handle;
+    kadm5_server_context *server_context;
+    kadm5_config_params conf;
+
+    krb5_program_setup(&context, argc, argv, args, num_args, NULL);
+    
+    if(help_flag)
+	krb5_std_usage(0, args, num_args);
+    if(version_flag) {
+	print_version(NULL);
+	exit(0);
+    }
+
+    memset(&conf, 0, sizeof(conf));
+    if(realm) {
+	conf.mask |= KADM5_CONFIG_REALM;
+	conf.realm = realm;
+    }
+
+    ret = kadm5_init_with_password_ctx (context,
+					KADM5_ADMIN_SERVICE,
+					NULL,
+					KADM5_ADMIN_SERVICE,
+					&conf, 0, 0, 
+					&kadm_handle);
+    if (ret)
+	krb5_err (context, 1, ret, "kadm5_init_with_password_ctx");
+
+    server_context = (kadm5_server_context *)kadm_handle;
+
+    ret = kadm5_log_truncate (server_context);
+	krb5_err (context, 1, ret, "kadm5_log_truncate");
+    return 0;
+}
diff --git a/crypto/heimdal/lib/krb5/acl.c b/crypto/heimdal/lib/krb5/acl.c
new file mode 100644
index 000000000000..0106251ff580
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/acl.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (c) 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.
+ */
+
+#include "krb5_locl.h"
+#include <fnmatch.h>
+
+RCSID("$Id: acl.c,v 1.1 2000/06/12 11:17:52 joda Exp $");
+
+struct acl_field {
+    enum { acl_string, acl_fnmatch, acl_retval } type;
+    union {
+	const char *cstr;
+	char **retv;
+    } u;
+    struct acl_field *next, **last;
+};
+
+static void
+acl_free_list(struct acl_field *acl)
+{
+    struct acl_field *next;
+    while(acl != NULL) {
+	next = acl->next;
+	free(acl);
+	acl = next;
+    }
+}
+
+static krb5_error_code
+acl_parse_format(krb5_context context,
+		 struct acl_field **acl_ret,
+		 const char *format,
+		 va_list ap)
+{
+    const char *p;
+    struct acl_field *acl = NULL, *tmp;
+
+    for(p = format; *p != '\0'; p++) {
+	tmp = malloc(sizeof(*tmp));
+	if(tmp == NULL) {
+	    acl_free_list(acl);
+	    return ENOMEM;
+	}
+	if(*p == 's') {
+	    tmp->type = acl_string;
+	    tmp->u.cstr = va_arg(ap, const char*);
+	} else if(*p == 'f') {
+	    tmp->type = acl_fnmatch;
+	    tmp->u.cstr = va_arg(ap, const char*);
+	} else if(*p == 'r') {
+	    tmp->type = acl_retval;
+	    tmp->u.retv = va_arg(ap, char **);
+	}
+	tmp->next = NULL;
+	if(acl == NULL)
+	    acl = tmp;
+	else
+	    *acl->last = tmp;
+	acl->last = &tmp->next;
+    }
+    *acl_ret = acl;
+    return 0;
+}
+
+static krb5_boolean
+acl_match_field(krb5_context context,
+		const char *string,
+		struct acl_field *field)
+{
+    if(field->type == acl_string) {
+	return !strcmp(string, field->u.cstr);
+    } else if(field->type == acl_fnmatch) {
+	return !fnmatch(string, field->u.cstr, 0);
+    } else if(field->type == acl_retval) {
+	*field->u.retv = strdup(string);
+	return TRUE;
+    }
+    return FALSE;
+}
+
+static krb5_boolean
+acl_match_acl(krb5_context context,
+	      struct acl_field *acl,
+	      const char *string)
+{
+    char buf[256];
+    for(;strsep_copy(&string, " \t", buf, sizeof(buf)) != -1; 
+	acl = acl->next) {
+	if(buf[0] == '\0')
+	    continue; /* skip ws */
+	if(!acl_match_field(context, buf, acl)) {
+	    return FALSE;
+	}
+    }
+    return TRUE;
+}
+
+
+krb5_error_code
+krb5_acl_match_string(krb5_context context,
+		      const char *acl_string,
+		      const char *format,
+		      ...)
+{
+    krb5_error_code ret;
+    struct acl_field *acl;
+
+    va_list ap;
+    va_start(ap, format);
+    ret = acl_parse_format(context, &acl, format, ap);
+    va_end(ap);
+    if(ret)
+	return ret;
+
+    ret = acl_match_acl(context, acl, acl_string);
+
+    acl_free_list(acl);
+    return ret ? 0 : EACCES;
+}
+	       
+krb5_error_code
+krb5_acl_match_file(krb5_context context,
+		    const char *file,
+		    const char *format,
+		    ...)
+{
+    krb5_error_code ret;
+    struct acl_field *acl;
+    char buf[256];
+    va_list ap;
+    FILE *f;
+
+    f = fopen(file, "r");
+    if(f == NULL)
+	return errno;
+
+    va_start(ap, format);
+    ret = acl_parse_format(context, &acl, format, ap);
+    va_end(ap);
+    if(ret) {
+	fclose(f);
+	return ret;
+    }
+
+    ret = EACCES; /* XXX */
+    while(fgets(buf, sizeof(buf), f)) {
+	if(buf[0] == '#')
+	    continue;
+	if(acl_match_acl(context, acl, buf)) {
+	    ret = 0;
+	    goto out;
+	}
+    }
+
+  out:
+    fclose(f);
+    acl_free_list(acl);
+    return ret;
+}
diff --git a/crypto/heimdal/lib/krb5/appdefault.c b/crypto/heimdal/lib/krb5/appdefault.c
new file mode 100644
index 000000000000..081dec0d72a8
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/appdefault.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2000, 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: appdefault.c,v 1.3 2001/01/10 00:19:58 assar Exp $");
+
+void
+krb5_appdefault_boolean(krb5_context context, const char *appname, 
+			krb5_realm realm, const char *option,
+			krb5_boolean def_val, krb5_boolean *ret_val)
+{
+    
+    if(appname == NULL)
+	appname = __progname;
+    def_val = krb5_config_get_bool_default(context, NULL, def_val, 
+					   "appdefaults", 
+					   option, 
+					   NULL);
+    if(realm != NULL)
+	def_val = krb5_config_get_bool_default(context, NULL, def_val,
+					       "appdefaults", 
+					       realm, 
+					       option, 
+					       NULL);
+    if(appname != NULL) {
+	def_val = krb5_config_get_bool_default(context, NULL, def_val, 
+					       "appdefaults", 
+					       appname, 
+					       option, 
+					       NULL);
+	if(realm != NULL)
+	    def_val = krb5_config_get_bool_default(context, NULL, def_val,
+						   "appdefaults", 
+						   appname, 
+						   realm, 
+						   option, 
+						   NULL);
+    }
+    *ret_val = def_val;
+}
+
+void
+krb5_appdefault_string(krb5_context context, const char *appname, 
+		       krb5_realm realm, const char *option,
+		       const char *def_val, char **ret_val)
+{
+    if(appname == NULL)
+	appname = __progname;
+    def_val = krb5_config_get_string_default(context, NULL, def_val, 
+					     "appdefaults", 
+					     option, 
+					     NULL);
+    if(realm != NULL)
+	def_val = krb5_config_get_string_default(context, NULL, def_val,
+						 "appdefaults", 
+						 realm, 
+						 option, 
+						 NULL);
+    if(appname != NULL) {
+	def_val = krb5_config_get_string_default(context, NULL, def_val, 
+						 "appdefaults", 
+						 appname, 
+						 option, 
+						 NULL);
+	if(realm != NULL)
+	    def_val = krb5_config_get_string_default(context, NULL, def_val,
+						     "appdefaults", 
+						     appname, 
+						     realm, 
+						     option, 
+						     NULL);
+    }
+    if(def_val != NULL)
+	*ret_val = strdup(def_val);
+    else
+	*ret_val = NULL;
+}
+
+void
+krb5_appdefault_time(krb5_context context, const char *appname,
+		     krb5_realm realm, const char *option,
+		     time_t def_val, time_t *ret_val)
+{
+    time_t t;
+    char tstr[32];
+    char *val;
+    snprintf(tstr, sizeof(tstr), "%ld", (long)def_val);
+    krb5_appdefault_string(context, appname, realm, option, tstr, &val);
+    t = parse_time (val, NULL);
+    free(val);
+    *ret_val = t;
+}
diff --git a/crypto/heimdal/lib/krb5/eai_to_heim_errno.c b/crypto/heimdal/lib/krb5/eai_to_heim_errno.c
new file mode 100644
index 000000000000..b9272ddd6fd5
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/eai_to_heim_errno.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright (c) 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. 
+ */
+
+#include <krb5_locl.h>
+
+RCSID("$Id: eai_to_heim_errno.c,v 1.1 2000/07/08 13:03:36 joda Exp $");
+
+krb5_error_code
+krb5_eai_to_heim_errno(int eai_errno)
+{
+    switch(eai_errno) {
+    case EAI_NOERROR:
+	return 0;
+    case EAI_ADDRFAMILY:
+	return HEIM_EAI_ADDRFAMILY;
+    case EAI_AGAIN:
+	return HEIM_EAI_AGAIN;
+    case EAI_BADFLAGS:
+	return HEIM_EAI_BADFLAGS;
+    case EAI_FAIL:
+	return HEIM_EAI_FAIL;
+    case EAI_FAMILY:
+	return HEIM_EAI_FAMILY;
+    case EAI_MEMORY:
+	return HEIM_EAI_MEMORY;
+    case EAI_NODATA:
+	return HEIM_EAI_NODATA;
+    case EAI_NONAME:
+	return HEIM_EAI_NONAME;
+    case EAI_SERVICE:
+	return HEIM_EAI_SERVICE;
+    case EAI_SOCKTYPE:
+	return HEIM_EAI_SOCKTYPE;
+    case EAI_SYSTEM:
+	return errno;
+    default:
+	return HEIM_EAI_UNKNOWN; /* XXX */
+    }
+}
diff --git a/crypto/heimdal/lib/krb5/kerberos.8 b/crypto/heimdal/lib/krb5/kerberos.8
new file mode 100644
index 000000000000..1b2ec91e05cc
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/kerberos.8
@@ -0,0 +1,73 @@
+.\" $Id: kerberos.8,v 1.1 2000/09/01 15:52:24 joda Exp $
+.\"
+.Dd September 1, 2000
+.Dt KERBEROS 8
+.Os HEIMDAL
+.Sh NAME
+.Nm kerberos
+.Nd introduction to the Kerberos system
+.Sh DESCRIPTION
+Kerberos is a network authentication system. It's purpose is to
+securely authenticate users and services in an insecure network
+environment. 
+.Pp
+This is done with a Kerberos server acting as a trusted third party,
+keeping a database with secret keys for all users and services
+(collectively called
+.Em principals ) .
+.Pp
+Each principal belongs to exactly one 
+.Em realm ,
+which is the administrative domain in Kerberos. A realm usually
+corresponds to an organisation, and the realm should normally be
+derived from that organisation's domain name. A realm is served by one
+or more Kerberos servers.
+.Pp
+The authentication process involves exchange of
+.Sq tickets
+and 
+.Sq authenticators 
+which together prove the principal's identity.
+.Pp
+When you login to the Kerberos system, either through the normal
+system login or with the
+.Xr kinit 1
+program, you acquire a 
+.Em ticket granting ticket
+which allows you to get new tickets for other services, such as
+.Ic telnet
+or
+.Ic ftp ,
+without giving your password.
+.Pp
+For more information on how Kerberos works, and other general Kerberos
+questions see the Kerberos FAQ at
+.Ad http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html .
+
+For setup instructions see the Heimdal Texinfo manual.
+.Sh SEE ALSO
+.Xr ftp 1
+.Xr kdestroy 1 ,
+.Xr kinit 1 ,
+.Xr klist 1 ,
+.Xr kpasswd 1 ,
+.Xr telnet 1
+.Sh HISTORY
+The Kerberos authentication system was developed in the late 1980's as
+part of the Athena Project at the Massachusetts Institute of
+Technology. Versions one through three never reached outside MIT, but
+version 4 was (and still is) quite popular, especially in the academic
+community, but is also used in commercial products like the AFS
+filesystem.
+.Pp
+The problems with version 4 are that it has many limitations, the code
+was not too well written (since it had been developed over a long
+time), and it has a number of known security problems. To resolve many
+of these issues work on version five started, and resulted in IETF
+RFC1510 in 1993. Since then much work has been put into the further
+development, and a new RFC will hopefully appear soon.
+.Pp
+This manual manual page is part of the
+.Nm Heimdal
+Kerberos 5 distribution, which has been in development at the Royal
+Institute of Technology in Stockholm, Sweden, since about 1997.
diff --git a/crypto/heimdal/lib/krb5/krb5_appdefault.3 b/crypto/heimdal/lib/krb5/krb5_appdefault.3
new file mode 100644
index 000000000000..3ce6fc9432bd
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/krb5_appdefault.3
@@ -0,0 +1,57 @@
+.\" Copyright (c) 2000 Kungliga Tekniska Högskolan
+.\" $Id: krb5_appdefault.3,v 1.3 2001/01/05 16:29:42 joda Exp $
+.Dd July 25, 2000
+.Dt KRB5_APPDEFAULT 3
+.Os HEIMDAL
+.Sh NAME
+.Nm krb5_appdefault_boolean ,
+.Nm krb5_appdefault_string ,
+.Nm krb5_appdefault_time
+.Nd Get application configuration value
+
+.Sh SYNOPSIS
+.Fd #include <krb5.h>
+
+.Ft void
+.Fn krb5_appdefault_boolean "krb5_context context" "const char *appname" "krb5_realm realm" "const char *option" "krb5_boolean def_val" "krb5_boolean *ret_val"
+.Ft void
+.Fn krb5_appdefault_string "krb5_context context" "const char *appname" "krb5_realm realm" "const char *option" "const char *def_val" "char **ret_val"
+.Ft void
+.Fn krb5_appdefault_time "krb5_context context" "const char *appname" "krb5_realm realm" "const char *option" "time_t def_val" "time_t *ret_val"
+
+.Sh DESCRIPTION
+
+These functions get application application defaults from the 
+.Dv appdefaults
+section of the
+.Xr krb5.conf 5 
+configuration file. These defaults can be specified per application,
+and/or per realm.
+
+These values will be looked for in 
+.Xr krb5.conf 5 ,
+in order of descending importance.
+.Bd -literal -offset indent
+[appdefaults]
+	appname = {
+		realm = {
+			option = value
+		}
+	}
+	appname = {
+		option = value
+	}
+	realm = {
+		option = value
+	}
+	option = value
+.Ed
+
+If the realm is omitted it will not be used for resolving values.  If
+no value can be found,
+.Fa def_val
+is returned instead.
+
+.Sh SEE ALSO
+.Xr krb5_config 3 ,
+.Xr krb5.conf 5
diff --git a/crypto/heimdal/lib/krb5/krb5_auth_context.3 b/crypto/heimdal/lib/krb5/krb5_auth_context.3
new file mode 100644
index 000000000000..42a96ecac2dc
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/krb5_auth_context.3
@@ -0,0 +1,284 @@
+.\" Copyright (c) 2001 Kungliga Tekniska Högskolan
+.\" $Id: krb5_auth_context.3,v 1.1 2001/01/28 19:47:33 assar Exp $
+.Dd Jan 21, 2001
+.Dt KRB5_AUTH_CONTEXT 3
+.Os HEIMDAL
+.Sh NAME
+.Nm krb5_auth_context ,
+.Nm krb5_auth_con_init ,
+.Nm krb5_auth_con_free ,
+.Nm krb5_auth_con_setflags ,
+.Nm krb5_auth_con_getflags ,
+.Nm krb5_auth_con_setaddrs ,
+.Nm krb5_auth_con_setaddrs_from_fd ,
+.Nm krb5_auth_con_getaddrs ,
+.Nm krb5_auth_con_genaddrs ,
+.Nm krb5_auth_con_getkey ,
+.Nm krb5_auth_con_setkey ,
+.Nm krb5_auth_con_getuserkey ,
+.Nm krb5_auth_con_setuserkey ,
+.Nm krb5_auth_con_getlocalsubkey ,
+.Nm krb5_auth_con_setlocalsubkey ,
+.Nm krb5_auth_con_getremotesubkey ,
+.Nm krb5_auth_con_setremotesubkey ,
+.Nm krb5_auth_setcksumtype ,
+.Nm krb5_auth_getcksumtype ,
+.Nm krb5_auth_setkeytype ,
+.Nm krb5_auth_getkeytype ,
+.Nm krb5_auth_getlocalseqnumber ,
+.Nm krb5_auth_setlocalseqnumber ,
+.Nm krb5_auth_getremoteseqnumber ,
+.Nm krb5_auth_setremoteseqnumber ,
+.Nm krb5_auth_getauthenticator ,
+.Nm krb5_auth_con_getrcache ,
+.Nm krb5_auth_con_setrcache ,
+.Nm krb5_auth_con_initivector ,
+.Nm krb5_auth_con_setivector
+.Nd manage authetication on connection level.
+.Sh SYNOPSIS
+.Fd #include <krb5.h>
+.Ft krb5_error_code
+.Fo krb5_auth_con_init
+.Fa "krb5_context context"
+.Fa "krb5_auth_context *auth_context"
+.Fc
+.Ft void
+.Fo krb5_auth_con_free
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_setflags
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "int32_t flags"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_getflags
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "int32_t *flags"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_setaddrs
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "krb5_address *local_addr"
+.Fa "krb5_address *remote_addr"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_getaddrs
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "krb5_address **local_addr"
+.Fa "krb5_address **remote_addr"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_genaddrs
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "int fd"
+.Fa "int flags"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_setaddrs_from_fd
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "void *p_fd"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_getkey
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "krb5_keyblock **keyblock"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_getlocalsubkey
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "krb5_keyblock **keyblock"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_getremotesubkey
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fa "krb5_keyblock **keyblock"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_initivector
+.Fa "krb5_context context"
+.Fa "krb5_auth_context auth_context"
+.Fc
+.Ft krb5_error_code
+.Fo krb5_auth_con_setivector
+.Fa "krb5_context context"
+.Fa "krb5_auth_context *auth_context"
+.Fa "krb5_pointer ivector"
+.Fc
+.Sh DESCRIPTION
+The
+.Nm krb5_auth_context
+structure holds all context related to an authenticated connection, in
+a similar way to 
+.Nm krb5_context
+that holds the context for the thread or process.  
+.Nm krb5_auth_context
+is used by various functions that are directly related to
+authentication between the server/client. Example of data that this
+structure contains are varius flags, addresses of client and server,
+port numbers, keyblocks (and subkeys), sequence numbers, replay cache,
+and checksum-type.
+.Pp
+.Fn krb5_auth_con_init
+allocates and initilizes the
+.Nm krb5_auth_context
+structure. Default values can be changed with
+.Fn krb5_auth_con_setcksumtype
+and
+.Fn krb5_auth_con_setflags .
+The
+.Nm auth_context
+structure must be freed by 
+.Fn krb5_auth_con_free .
+.Pp
+.Fn krb5_auth_con_getflags
+and
+.Fn krb5_auth_con_setflags
+gets and modifies the flags for a 
+.Nm krb5_auth_context
+structure. Possible flags to set are:
+.Bl -tag -width Ds
+.It Dv KRB5_AUTH_CONTEXT_DO_TIME
+check timestamp on incoming packets. 
+.\".It Dv KRB5_AUTH_CONTEXT_RET_TIME
+.It Dv KRB5_AUTH_CONTEXT_DO_SEQUENCE
+Generate and check sequence-number on each packet.
+.\".It Dv KRB5_AUTH_CONTEXT_RET_SEQUENCE
+.\".It Dv KRB5_AUTH_CONTEXT_PERMIT_ALL
+.El
+.Pp
+.Fn krb5_auth_con_setaddrs ,
+.Fn krb5_auth_con_setaddrs_from_fd
+and
+.Fn krb5_auth_con_getaddrs
+gets and sets the addresses that are checked when a packet is received.
+It is mandatory to set an address for the remote
+host. If the local address is not set, it iss deduced from the underlaying
+operating system.
+.Fn krb5_auth_con_getaddrs
+will call
+.Fn krb5_free_address
+on any address that is passed in
+.Fa local_addr
+or
+.Fa remote_addr .
+.Fn krb5_auth_con_setaddr
+allows passing in a
+.Dv NULL
+pointer as
+.Fa local_addr
+and
+.Fa remote_addr ,
+in that case it will just not set that address.
+.Pp
+.Fn krb5_auth_con_setaddrs_from_fd
+fetches the addresses from a file descriptor.
+.Pp
+.Fn krb5_auth_con_genaddrs
+fetches the address information from the given file descriptor
+.Fa fd 
+depending on the bitmap argument
+.Fa flags .
+.Pp
+Possible values on
+.Fa flags
+are:
+.Bl -tag -width Ds
+.It Va KRB5_AUTH_CONTEXT_GENERATE_LOCAL_ADDR
+fetches the local address from
+.Fa fd .
+.It Va KRB5_AUTH_CONTEXT_GENERATE_REMOTE_ADDR
+fetches the remote address from
+.Fa fd .
+.El
+.Pp
+.Fn krb5_auth_con_setkey ,
+.Fn krb5_auth_con_setuserkey
+and
+.Fn krb5_auth_con_getkey
+gets and sets the key used for this auth context. The keyblock returned by
+.Fn krb5_auth_con_getkey
+should be freed with
+.Fn krb5_free_keyblock .
+The keyblock send into
+.Fn krb5_auth_con_setkey
+is copied into the
+.Nm krb5_auth_context ,
+and thus no special handling is needed.
+.Dv NULL
+is not a valid keyblock to
+.Fn krb5_auth_con_setkey .
+.Pp
+.Fn krb5_auth_con_setuserkey 
+is only useful when doing user to user authentication.
+.Fn krb5_auth_con_setkey
+is equivalent to
+.Fn krb5_auth_con_setuserkey .
+.Pp
+.Fn krb5_auth_con_getlocalsubkey ,
+.Fn krb5_auth_con_setlocalsubkey ,
+.Fn krb5_auth_con_getremotesubkey
+and
+.Fn krb5_auth_con_setremotesubkey
+gets and sets the keyblock for the local and remote subkey. The keyblock returned by 
+.Fn krb5_auth_con_getlocalsubkey
+and
+.Fn krb5_auth_con_getremotesubkey
+must be freed with
+.Fn krb5_free_keyblock .
+.Pp
+.Fn krb5_auth_setcksumtype
+and
+.Fn krb5_auth_getcksumtype
+sets and gets the checksum type that should be used for this
+connection.
+.Pp
+.Fn krb5_auth_getremoteseqnumber
+.Fn krb5_auth_setremoteseqnumber ,
+.Fn krb5_auth_getlocalseqnumber
+and
+.Fn krb5_auth_setlocalseqnumber
+gets and sets the sequence-number for the local and remote
+sequence-number counter.
+.Pp
+.Fn krb5_auth_setkeytype
+and
+.Fn krb5_auth_getkeytype
+gets and gets the keytype of the keyblock in
+.Nm krb5_auth_context .
+.Pp
+.Fn krb5_auth_getauthenticator
+Retrieves the authenticator that was used during mutual
+authentication. The 
+.Dv authenticator
+returned should be freed by calling
+.Fn krb5_free_authenticator .
+.Pp
+.Fn krb5_auth_con_getrcache
+and
+.Fn krb5_auth_con_setrcache
+gets and sets the replay-cache.
+.Pp
+.Fn krb5_auth_con_initivector
+allocates memory for and zeros the initial vector in the
+.Fa auth_context
+keyblock.
+.Pp
+.Fn krb5_auth_con_setivector
+sets the i_vector portion of 
+.Fa auth_context
+to
+.Fa ivector .
+.Sh SEE ALSO
+.Xr krb5_context 3 ,
+.Xr kerberos 8
diff --git a/crypto/heimdal/lib/krb5/krb5_config.3 b/crypto/heimdal/lib/krb5/krb5_config.3
new file mode 100644
index 000000000000..b5a74db93b79
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/krb5_config.3
@@ -0,0 +1,71 @@
+.\" Copyright (c) 2000 Kungliga Tekniska Högskolan
+.\" $Id: krb5_config.3,v 1.1 2000/07/25 10:22:46 joda Exp $
+.Dd July 25, 2000
+.Dt KRB5_CONFIG 3
+.Os HEIMDAL
+.Sh NAME
+.Nm krb5_config_get_bool_default ,
+.Nm krb5_config_get_int_default ,
+.Nm krb5_config_get_string_default ,
+.Nm krb5_config_get_time_default
+.Nd Get configuration value
+
+.Sh SYNOPSIS
+.Fd #include <krb5.h>
+
+.Ft krb5_boolean
+.Fn krb5_config_get_bool_default "krb5_context context" "krb5_config_section *c" "krb5_boolean def_value" "..."
+.Ft int
+.Fn krb5_config_get_int_default "krb5_context context" "krb5_config_section *c" "int def_value" "..."
+.Ft const char*
+.Fn krb5_config_get_string_default "krb5_context context" "krb5_config_section *c" "const char *def_value" "..."
+.Ft int
+.Fn krb5_config_get_time_default "krb5_context context" "krb5_config_section *c" "int def_value" "..."
+
+.Sh DESCRIPTION
+
+These functions get values from the 
+.Xr krb5.conf 5 
+configuration file, or another configuration database specified by the
+.Fa c
+parameter.
+
+The variable arguments should be a list of strings naming each
+subsection to look for. For example:
+
+.Bd -literal -offset indent
+krb5_config_get_bool_default(context, NULL, FALSE, "libdefaults", "log_utc", NULL)
+.Ed
+
+gets the boolean value for the
+.Dv log_utc
+option, defaulting to
+.Dv FALSE .
+
+.Fn krb5_config_get_bool_default
+will convert the option value to a boolean value, where
+.Sq yes , 
+.Sq true ,
+and any non-zero number means
+.Dv TRUE ,
+and any other value 
+.Dv FALSE .
+
+.Fn krb5_config_get_int_default
+will convert the value to an integer.
+
+.Fn krb5_config_get_time_default
+will convert the value to a period of time (not a time stamp) in
+seconds, so the string
+.Sq 2 weeks
+will be converted to
+1209600 (2 * 7 * 24 * 60 * 60).
+
+.Sh BUGS
+
+Other than for the string case, there's no way to tell whether there
+was a value specified or not.
+
+.Sh SEE ALSO
+.Xr krb5_appdefault 3 ,
+.Xr krb5.conf 5
diff --git a/crypto/heimdal/lib/krb5/krb5_context.3 b/crypto/heimdal/lib/krb5/krb5_context.3
new file mode 100644
index 000000000000..83a768d1a6b4
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/krb5_context.3
@@ -0,0 +1,20 @@
+.\" Copyright (c) 2001 Kungliga Tekniska Högskolan
+.\" $Id: krb5_context.3,v 1.1 2001/01/28 21:39:29 assar Exp $
+.Dd Jan 21, 2001
+.Dt KRB5_CONTEXT 3
+.Os HEIMDAL
+.Sh NAME
+.Nm krb5_context
+.Sh DESCRIPTION
+The
+.Nm
+structure is designed to hold all per thread state. All global
+variables that are context specific are stored in this struture,
+including default encryption types, credential-cache (ticket file), and
+default realms.
+.Pp
+The internals of the structure should never be accessed directly,
+functions exist for extracting information.
+.Sh SEE ALSO
+.Xr krb5_init_context 3 ,
+.Xr kerberos 8
diff --git a/crypto/heimdal/lib/krb5/krb5_init_context.3 b/crypto/heimdal/lib/krb5/krb5_init_context.3
new file mode 100644
index 000000000000..7e27ec238ba3
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/krb5_init_context.3
@@ -0,0 +1,38 @@
+.\" Copyright (c) 2001 Kungliga Tekniska Högskolan
+.\" $Id: krb5_init_context.3,v 1.1 2001/01/28 21:39:29 assar Exp $
+.Dd Jan 21, 2001
+.Dt KRB5_CONTEXT 3
+.Os HEIMDAL
+.Sh NAME
+.Nm krb5_init_context ,
+.Nm krb5_free_context
+.Sh SYNOPSIS
+.Fd #include <krb5.h>
+.Ft krb5_error_code
+.Fn krb5_init_context "krb5_context *context"
+.Ft void
+.Fn krb5_free_context "krb5_context *context"
+.Sh DESCRIPTION
+The
+.Fn krb5_init_context
+function initializes the
+.Fa context
+structure and reads the configration file
+.Pa /etc/krb5.conf .
+.Pp
+The structure should be freed by calling
+.Fn krb5_free_context
+when it is no longer being used.
+.Sh RETURN VALUES
+.Fn krb5_init_context
+returns 0 to indicate success.
+Otherwise an errno code is returned.
+Failure means either that something bad happened during initialization
+(typically
+.Bq ENOMEM )
+or that Kerberos should not be used
+.Bq ENXIO .
+.Sh SEE ALSO
+.Xr krb5_context 3 ,
+.Xr errno 2 ,
+.Xr kerberos 8
diff --git a/crypto/heimdal/lib/krb5/test_get_addrs.c b/crypto/heimdal/lib/krb5/test_get_addrs.c
new file mode 100644
index 000000000000..96a8f89bf570
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/test_get_addrs.c
@@ -0,0 +1,78 @@
+/*
+ * Copyright (c) 2000 - 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 KTH 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 KTH AND ITS 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 KTH OR ITS 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"
+#include <err.h>
+
+RCSID("$Id: test_get_addrs.c,v 1.3 2001/01/25 12:45:15 assar Exp $");
+
+/* print all addresses that we find */
+
+static void
+print_addresses (krb5_context context, const krb5_addresses *addrs)
+{
+    int i;
+    char buf[256];
+    size_t len;
+    
+    for (i = 0; i < addrs->len; ++i) {
+	krb5_print_address (&addrs->val[i], buf, sizeof(buf), &len);
+	printf ("%s\n", buf);
+    }
+}
+
+int
+main(int argc, char **argv)
+{
+    krb5_context context;
+    krb5_error_code ret;
+    krb5_addresses addrs;
+
+    ret = krb5_init_context(&context);
+    if (ret)
+	errx (1, "krb5_init_context failed: %d", ret);
+
+    ret = krb5_get_all_client_addrs (context, &addrs);
+    if (ret)
+	krb5_err (context, 1, ret, "krb5_get_all_client_addrs");
+    printf ("client addresses\n");
+    print_addresses (context, &addrs);
+    krb5_free_addresses (context, &addrs);
+
+    ret = krb5_get_all_server_addrs (context, &addrs);
+    if (ret)
+	krb5_err (context, 1, ret, "krb5_get_all_server_addrs");
+    printf ("server addresses\n");
+    print_addresses (context, &addrs);
+    krb5_free_addresses (context, &addrs);
+    return 0;
+}
diff --git a/crypto/heimdal/lib/krb5/verify_krb5_conf.8 b/crypto/heimdal/lib/krb5/verify_krb5_conf.8
new file mode 100644
index 000000000000..55cdc92fa005
--- /dev/null
+++ b/crypto/heimdal/lib/krb5/verify_krb5_conf.8
@@ -0,0 +1,33 @@
+.\" $Id: verify_krb5_conf.8,v 1.2 2000/03/04 14:07:50 assar Exp $
+.\"
+.Dd March  4, 2000
+.Dt VERIFY_KRB5_CONF 8
+.Os HEIMDAL
+.Sh NAME
+.Nm verify_krb5_conf
+.Nd
+does a crude test that
+.Pa krb5.conf
+does not contain any obvious syntax error
+.Sh SYNOPSIS
+.Nm
+.Ar [config-file]
+.Sh DESCRIPTION
+.Nm
+reads the configuration file
+.Pa krb5.conf ,
+or the file given on the command line,
+and parses it, thereby verifying that the syntax is not correctly wrong.
+Since that file is read by almost all Kerberos programs but most of
+them have no way of notifying the user that it could not be parsed,
+this program is useful.
+.Sh ENVIRONMENT
+.Ev KRB5_CONFIG
+points to the configuration file to read.
+.Sh FILES
+.Xr krb5.conf 5
+.Sh SEE ALSO
+.Xr krb5.conf 5
+.Sh BUGS
+It should know about what variables are actually used and warn about
+unknown ones.
diff --git a/crypto/heimdal/lib/roken/acconfig.h b/crypto/heimdal/lib/roken/acconfig.h
new file mode 100644
index 000000000000..5fbe685ce386
--- /dev/null
+++ b/crypto/heimdal/lib/roken/acconfig.h
@@ -0,0 +1,36 @@
+@BOTTOM@
+
+#ifdef BROKEN_REALLOC
+#define realloc(X, Y) isoc_realloc((X), (Y))
+#define isoc_realloc(X, Y) ((X) ? realloc((X), (Y)) : malloc(Y))
+#endif
+
+#ifdef VOID_RETSIGTYPE
+#define SIGRETURN(x) return
+#else
+#define SIGRETURN(x) return (RETSIGTYPE)(x)
+#endif
+
+#define RCSID(msg) \
+static /**/const char *const rcsid[] = { (const char *)rcsid, "\100(#)" msg }
+
+#undef PROTOTYPES
+
+/* Maximum values on all known systems */
+#define MaxHostNameLen (64+4)
+#define MaxPathLen (1024+4)
+
+/*
+ * Define NDBM if you are using the 4.3 ndbm library (which is part of
+ * libc).  If not defined, 4.2 dbm will be assumed.
+ */
+#if defined(HAVE_DBM_FIRSTKEY)
+#define NDBM
+#endif
+
+/*
+ * Defining this enables lots of useful (and used) extensions on
+ * glibc-based systems such as Linux
+ */
+
+#define _GNU_SOURCE
diff --git a/crypto/heimdal/lib/roken/acinclude.m4 b/crypto/heimdal/lib/roken/acinclude.m4
new file mode 100644
index 000000000000..1d0197c5ce37
--- /dev/null
+++ b/crypto/heimdal/lib/roken/acinclude.m4
@@ -0,0 +1,9 @@
+dnl $Id$
+dnl
+dnl Only put things that for some reason can't live in the `cf'
+dnl directory in this file.
+dnl
+
+dnl $xId: misc.m4,v 1.1 1997/12/14 15:59:04 joda Exp $
+dnl
+define(upcase,`echo $1 | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`)dnl
diff --git a/crypto/heimdal/lib/roken/config.h.in b/crypto/heimdal/lib/roken/config.h.in
new file mode 100644
index 000000000000..b3df98912148
--- /dev/null
+++ b/crypto/heimdal/lib/roken/config.h.in
@@ -0,0 +1 @@
+/*autoheader*/
diff --git a/crypto/heimdal/lib/roken/environment.c b/crypto/heimdal/lib/roken/environment.c
new file mode 100644
index 000000000000..62c732c5b47b
--- /dev/null
+++ b/crypto/heimdal/lib/roken/environment.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 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: environment.c,v 1.1 2000/06/21 02:05:03 assar Exp $");
+#endif
+
+#include <stdio.h>
+#include <string.h>
+#include "roken.h"
+
+/*
+ * return count of environment assignments from `file' and 
+ * list of malloced strings in `env'
+ */
+
+int
+read_environment(const char *file, char ***env)
+{
+    int i, k;
+    FILE *F;
+    char **l;
+    char buf[BUFSIZ], *p, *r;
+
+    if ((F = fopen(file, "r")) == NULL) {
+	return 0;
+    }
+
+    i = 0;
+    if (*env) {
+	l = *env;
+	while (*l != NULL) {
+	    i++;
+	    l++;
+	}
+    }
+    l = *env;
+    /* This is somewhat more relaxed on what it accepts then
+     * Wietses sysv_environ from K4 was...
+     */
+    while (fgets(buf, BUFSIZ, F) != NULL) {
+	if (buf[0] == '#')
+	    continue;
+
+	p = strchr(buf, '#');
+	if (p != NULL)
+	    *p = '\0';
+
+	p = buf;
+	while (*p == ' ' || *p == '\t' || *p == '\n') p++;
+	if (*p == '\0')
+	    continue;
+
+	k = strlen(p);
+	if (p[k-1] == '\n')
+	    p[k-1] = '\0';
+
+	/* Here one should check that is is a 'valid' env string... */
+	r = strchr(p, '=');
+	if (r == NULL)
+	    continue;
+
+	l = realloc(l, (i+1) * sizeof (char *));
+	l[i++] = strdup(p);
+    }
+    fclose(F);
+    l = realloc(l, (i+1) * sizeof (char *));
+    l[i] = NULL;
+    *env = l;
+    return i;
+}
diff --git a/crypto/heimdal/lib/roken/err.hin b/crypto/heimdal/lib/roken/err.hin
new file mode 100644
index 000000000000..1fa7774bd0fe
--- /dev/null
+++ b/crypto/heimdal/lib/roken/err.hin
@@ -0,0 +1,68 @@
+/*
+ * Copyright (c) 1995 - 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.
+ */
+
+/* $Id: err.hin,v 1.16 2000/12/11 04:40:59 assar 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 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/esetenv.c b/crypto/heimdal/lib/roken/esetenv.c
new file mode 100644
index 000000000000..cb357527c34b
--- /dev/null
+++ b/crypto/heimdal/lib/roken/esetenv.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (c) 2000, 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+RCSID("$Id: esetenv.c,v 1.3 2001/01/27 05:28:38 assar Exp $");
+#endif
+
+#include "roken.h"
+
+#include <err.h>
+
+void
+esetenv(const char *var, const char *val, int rewrite)
+{
+    if (setenv ((char *)var, (char *)val, rewrite))
+	errx (1, "failed setting environment variable %s", var);
+}
diff --git a/crypto/heimdal/lib/roken/fnmatch.hin b/crypto/heimdal/lib/roken/fnmatch.hin
new file mode 100644
index 000000000000..95c91d600b64
--- /dev/null
+++ b/crypto/heimdal/lib/roken/fnmatch.hin
@@ -0,0 +1,49 @@
+/*	$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/getifaddrs.c b/crypto/heimdal/lib/roken/getifaddrs.c
new file mode 100644
index 000000000000..e8e3e5467f09
--- /dev/null
+++ b/crypto/heimdal/lib/roken/getifaddrs.c
@@ -0,0 +1,271 @@
+/*
+ * Copyright (c) 2000 - 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+RCSID("$Id: getifaddrs.c,v 1.4 2001/01/28 23:02:46 assar Exp $");
+#endif
+#include "roken.h"
+
+#ifdef __osf__
+/* hate */
+struct rtentry;
+struct mbuf;
+#endif
+#ifdef HAVE_NET_IF_H
+#include <net/if.h>
+#endif
+
+#ifdef HAVE_SYS_SOCKIO_H
+#include <sys/sockio.h>
+#endif /* HAVE_SYS_SOCKIO_H */
+
+#ifdef HAVE_NETINET_IN6_VAR_H
+#include <netinet/in6_var.h>
+#endif /* HAVE_NETINET_IN6_VAR_H */
+
+#include <ifaddrs.h>
+
+static int
+getifaddrs2(struct ifaddrs **ifap, 
+	    int af, int siocgifconf, int siocgifflags,
+	    size_t ifreq_sz)
+{
+    int ret;
+    int fd;
+    size_t buf_size;
+    char *buf;
+    struct ifconf ifconf;
+    int num, j = 0;
+    char *p;
+    size_t sz;
+    struct sockaddr sa_zero;
+    struct ifreq *ifr;
+
+    struct ifaddrs *start,  **end = &start;
+
+    buf = NULL;
+
+    memset (&sa_zero, 0, sizeof(sa_zero));
+    fd = socket(af, SOCK_DGRAM, 0);
+    if (fd < 0)
+	return -1;
+
+    buf_size = 8192;
+    for (;;) {
+	buf = calloc(1, buf_size);
+	if (buf == NULL) {
+	    ret = ENOMEM;
+	    goto error_out;
+	}
+	ifconf.ifc_len = buf_size;
+	ifconf.ifc_buf = buf;
+
+	/*
+	 * Solaris returns EINVAL when the buffer is too small.
+	 */
+	if (ioctl (fd, siocgifconf, &ifconf) < 0 && errno != EINVAL) {
+	    ret = errno;
+	    goto error_out;
+	}
+	/*
+	 * Can the difference between a full and a overfull buf
+	 * be determined?
+	 */
+
+	if (ifconf.ifc_len < buf_size)
+	    break;
+	free (buf);
+	buf_size *= 2;
+    }
+
+    num = ifconf.ifc_len / ifreq_sz;
+    j = 0;
+    for (p = ifconf.ifc_buf;
+	 p < ifconf.ifc_buf + ifconf.ifc_len;
+	 p += sz) {
+	struct ifreq ifreq;
+	struct sockaddr *sa;
+	size_t salen;
+
+	ifr = (struct ifreq *)p;
+	sa  = &ifr->ifr_addr;
+
+	sz = ifreq_sz;
+	salen = sizeof(struct sockaddr);
+#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN
+	salen = sa->sa_len;
+	sz = max(sz, sizeof(ifr->ifr_name) + sa->sa_len);
+#endif
+#ifdef SA_LEN
+	salen = SA_LEN(sa);
+	sz = max(sz, sizeof(ifr->ifr_name) + SA_LEN(sa));
+#endif
+	memset (&ifreq, 0, sizeof(ifreq));
+	memcpy (ifreq.ifr_name, ifr->ifr_name, sizeof(ifr->ifr_name));
+
+	if (ioctl(fd, siocgifflags, &ifreq) < 0) {
+	    ret = errno;
+	    goto error_out;
+	}
+
+	*end = malloc(sizeof(**end));
+
+	(*end)->ifa_next = NULL;
+	(*end)->ifa_name = strdup(ifr->ifr_name);
+	(*end)->ifa_flags = ifreq.ifr_flags;
+	(*end)->ifa_addr = malloc(salen);
+	memcpy((*end)->ifa_addr, sa, salen);
+	(*end)->ifa_netmask = NULL;
+
+#if 0
+	/* fix these when we actually need them */
+	if(ifreq.ifr_flags & IFF_BROADCAST) {
+	    (*end)->ifa_broadaddr = malloc(sizeof(ifr->ifr_broadaddr));
+	    memcpy((*end)->ifa_broadaddr, &ifr->ifr_broadaddr, 
+		   sizeof(ifr->ifr_broadaddr));
+	} else if(ifreq.ifr_flags & IFF_POINTOPOINT) {
+	    (*end)->ifa_dstaddr = malloc(sizeof(ifr->ifr_dstaddr));
+	    memcpy((*end)->ifa_dstaddr, &ifr->ifr_dstaddr, 
+		   sizeof(ifr->ifr_dstaddr));
+	} else
+	    (*end)->ifa_dstaddr = NULL;
+#else
+	    (*end)->ifa_dstaddr = NULL;
+#endif
+
+	(*end)->ifa_data = NULL;
+
+	end = &(*end)->ifa_next;
+	
+    }
+    *ifap = start;
+    free(buf);
+    return 0;
+  error_out:
+    free(buf);
+    errno = ret;
+    return -1;
+}
+
+int
+getifaddrs(struct ifaddrs **ifap) 
+{
+    int ret = -1;
+    errno = ENXIO;
+#if defined(AF_INET6) && defined(SIOCGIF6CONF) && defined(SIOCGIF6FLAGS)
+    if (ret)
+	ret = getifaddrs2 (ifap, AF_INET6, SIOCGIF6CONF, SIOCGIF6FLAGS,
+			   sizeof(struct in6_ifreq));
+#endif
+#if defined(HAVE_IPV6) && defined(SIOCGIFCONF)
+    if (ret)
+	ret = getifaddrs2 (ifap, AF_INET6, SIOCGIFCONF, SIOCGIFFLAGS,
+			   sizeof(struct ifreq));
+#endif
+#if defined(AF_INET) && defined(SIOCGIFCONF) && defined(SIOCGIFFLAGS)
+    if (ret)
+	ret = getifaddrs2 (ifap, AF_INET, SIOCGIFCONF, SIOCGIFFLAGS,
+			   sizeof(struct ifreq));
+#endif
+    return ret;
+}
+
+void
+freeifaddrs(struct ifaddrs *ifp)
+{
+    struct ifaddrs *p, *q;
+    
+    for(p = ifp; p; ) {
+	free(p->ifa_name);
+	if(p->ifa_addr)
+	    free(p->ifa_addr);
+	if(p->ifa_dstaddr) 
+	    free(p->ifa_dstaddr);
+	if(p->ifa_netmask) 
+	    free(p->ifa_netmask);
+	if(p->ifa_data)
+	    free(p->ifa_data);
+	q = p;
+	p = p->ifa_next;
+	free(q);
+    }
+}
+
+#ifdef TEST
+
+void
+print_addr(const char *s, struct sockaddr *sa)
+{
+    int i;
+    printf("  %s=%d/", s, sa->sa_family);
+#ifdef HAVE_STRUCT_SOCKADDR_SA_LEN
+    for(i = 0; i < sa->sa_len - ((long)sa->sa_data - (long)&sa->sa_family); i++)
+	printf("%02x", ((unsigned char*)sa->sa_data)[i]);
+#else
+    for(i = 0; i < sizeof(sa->sa_data); i++) 
+	printf("%02x", ((unsigned char*)sa->sa_data)[i]);
+#endif
+    printf("\n");
+}
+
+void 
+print_ifaddrs(struct ifaddrs *x)
+{
+    struct ifaddrs *p;
+    
+    for(p = x; p; p = p->ifa_next) {
+	printf("%s\n", p->ifa_name);
+	printf("  flags=%x\n", p->ifa_flags);
+	if(p->ifa_addr)
+	    print_addr("addr", p->ifa_addr);
+	if(p->ifa_dstaddr) 
+	    print_addr("dstaddr", p->ifa_dstaddr);
+	if(p->ifa_netmask) 
+	    print_addr("netmask", p->ifa_netmask);
+	printf("  %p\n", p->ifa_data);
+    }
+}
+
+int
+main()
+{
+    struct ifaddrs *a = NULL, *b;
+    getifaddrs2(&a, AF_INET, SIOCGIFCONF, SIOCGIFFLAGS, sizeof(struct ifreq));
+    print_ifaddrs(a);
+    printf("---\n");
+    getifaddrs(&b);
+    print_ifaddrs(b);
+    return 0;
+}
+#endif
diff --git a/crypto/heimdal/lib/roken/glob.hin b/crypto/heimdal/lib/roken/glob.hin
new file mode 100644
index 000000000000..bece48a89cd7
--- /dev/null
+++ b/crypto/heimdal/lib/roken/glob.hin
@@ -0,0 +1,84 @@
+/*
+ * 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/ifaddrs.hin b/crypto/heimdal/lib/roken/ifaddrs.hin
new file mode 100644
index 000000000000..d2b9be8ccc6d
--- /dev/null
+++ b/crypto/heimdal/lib/roken/ifaddrs.hin
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 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.
+ */
+
+/* $Id: ifaddrs.hin,v 1.3 2000/12/11 00:01:13 assar Exp $ */
+
+#ifndef __ifaddrs_h__
+#define __ifaddrs_h__
+
+/*
+ * the interface is defined in terms of the fields below, and this is
+ * sometimes #define'd, so there seems to be no simple way of solving
+ * this and this seemed the best. */
+
+#undef ifa_dstaddr
+
+struct ifaddrs {
+    struct ifaddrs *ifa_next;
+    char *ifa_name;
+    unsigned int ifa_flags;
+    struct sockaddr *ifa_addr;
+    struct sockaddr *ifa_netmask;
+    struct sockaddr *ifa_dstaddr;
+    void *ifa_data;
+};
+
+#ifndef ifa_broadaddr
+#define ifa_broadaddr ifa_dstaddr
+#endif
+
+int getifaddrs(struct ifaddrs**);
+
+void freeifaddrs(struct ifaddrs*);
+
+#endif /* __ifaddrs_h__ */
diff --git a/crypto/heimdal/lib/roken/install-sh b/crypto/heimdal/lib/roken/install-sh
new file mode 100755
index 000000000000..e9de23842dcd
--- /dev/null
+++ b/crypto/heimdal/lib/roken/install-sh
@@ -0,0 +1,251 @@
+#!/bin/sh
+#
+# install - install a program, script, or datafile
+# This comes from X11R5 (mit/util/scripts/install.sh).
+#
+# Copyright 1991 by the Massachusetts Institute of Technology
+#
+# Permission to use, copy, modify, distribute, and sell this software and its
+# documentation for any purpose is hereby granted without fee, provided that
+# the above copyright notice appear in all copies and that both that
+# copyright notice and this permission notice appear in supporting
+# documentation, and that the name of M.I.T. not be used in advertising or
+# publicity pertaining to distribution of the software without specific,
+# written prior permission.  M.I.T. makes no representations about the
+# suitability of this software for any purpose.  It is provided "as is"
+# without express or implied warranty.
+#
+# Calling this script install-sh is preferred over install.sh, to prevent
+# `make' implicit rules from creating a file called install from it
+# when there is no Makefile.
+#
+# This script is compatible with the BSD install script, but was written
+# from scratch.  It can only install one file at a time, a restriction
+# shared with many OS's install programs.
+
+
+# set DOITPROG to echo to test this script
+
+# Don't use :- since 4.3BSD and earlier shells don't like it.
+doit="${DOITPROG-}"
+
+
+# put in absolute paths if you don't have them in your path; or use env. vars.
+
+mvprog="${MVPROG-mv}"
+cpprog="${CPPROG-cp}"
+chmodprog="${CHMODPROG-chmod}"
+chownprog="${CHOWNPROG-chown}"
+chgrpprog="${CHGRPPROG-chgrp}"
+stripprog="${STRIPPROG-strip}"
+rmprog="${RMPROG-rm}"
+mkdirprog="${MKDIRPROG-mkdir}"
+
+transformbasename=""
+transform_arg=""
+instcmd="$mvprog"
+chmodcmd="$chmodprog 0755"
+chowncmd=""
+chgrpcmd=""
+stripcmd=""
+rmcmd="$rmprog -f"
+mvcmd="$mvprog"
+src=""
+dst=""
+dir_arg=""
+
+while [ x"$1" != x ]; do
+    case $1 in
+	-c) instcmd="$cpprog"
+	    shift
+	    continue;;
+
+	-d) dir_arg=true
+	    shift
+	    continue;;
+
+	-m) chmodcmd="$chmodprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-o) chowncmd="$chownprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-g) chgrpcmd="$chgrpprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-s) stripcmd="$stripprog"
+	    shift
+	    continue;;
+
+	-t=*) transformarg=`echo $1 | sed 's/-t=//'`
+	    shift
+	    continue;;
+
+	-b=*) transformbasename=`echo $1 | sed 's/-b=//'`
+	    shift
+	    continue;;
+
+	*)  if [ x"$src" = x ]
+	    then
+		src=$1
+	    else
+		# this colon is to work around a 386BSD /bin/sh bug
+		:
+		dst=$1
+	    fi
+	    shift
+	    continue;;
+    esac
+done
+
+if [ x"$src" = x ]
+then
+	echo "install:	no input file specified"
+	exit 1
+else
+	true
+fi
+
+if [ x"$dir_arg" != x ]; then
+	dst=$src
+	src=""
+	
+	if [ -d $dst ]; then
+		instcmd=:
+		chmodcmd=""
+	else
+		instcmd=mkdir
+	fi
+else
+
+# Waiting for this to be detected by the "$instcmd $src $dsttmp" command
+# might cause directories to be created, which would be especially bad 
+# if $src (and thus $dsttmp) contains '*'.
+
+	if [ -f $src -o -d $src ]
+	then
+		true
+	else
+		echo "install:  $src does not exist"
+		exit 1
+	fi
+	
+	if [ x"$dst" = x ]
+	then
+		echo "install:	no destination specified"
+		exit 1
+	else
+		true
+	fi
+
+# If destination is a directory, append the input filename; if your system
+# does not like double slashes in filenames, you may need to add some logic
+
+	if [ -d $dst ]
+	then
+		dst="$dst"/`basename $src`
+	else
+		true
+	fi
+fi
+
+## this sed command emulates the dirname command
+dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'`
+
+# Make sure that the destination directory exists.
+#  this part is taken from Noah Friedman's mkinstalldirs script
+
+# Skip lots of stat calls in the usual case.
+if [ ! -d "$dstdir" ]; then
+defaultIFS='	
+'
+IFS="${IFS-${defaultIFS}}"
+
+oIFS="${IFS}"
+# Some sh's can't handle IFS=/ for some reason.
+IFS='%'
+set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'`
+IFS="${oIFS}"
+
+pathcomp=''
+
+while [ $# -ne 0 ] ; do
+	pathcomp="${pathcomp}${1}"
+	shift
+
+	if [ ! -d "${pathcomp}" ] ;
+        then
+		$mkdirprog "${pathcomp}"
+	else
+		true
+	fi
+
+	pathcomp="${pathcomp}/"
+done
+fi
+
+if [ x"$dir_arg" != x ]
+then
+	$doit $instcmd $dst &&
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi
+else
+
+# If we're going to rename the final executable, determine the name now.
+
+	if [ x"$transformarg" = x ] 
+	then
+		dstfile=`basename $dst`
+	else
+		dstfile=`basename $dst $transformbasename | 
+			sed $transformarg`$transformbasename
+	fi
+
+# don't allow the sed command to completely eliminate the filename
+
+	if [ x"$dstfile" = x ] 
+	then
+		dstfile=`basename $dst`
+	else
+		true
+	fi
+
+# Make a temp file name in the proper directory.
+
+	dsttmp=$dstdir/#inst.$$#
+
+# Move or copy the file name to the temp name
+
+	$doit $instcmd $src $dsttmp &&
+
+	trap "rm -f ${dsttmp}" 0 &&
+
+# and set any options; do chmod last to preserve setuid bits
+
+# If any of these fail, we abort the whole thing.  If we want to
+# ignore errors from any of these, just make sure not to ignore
+# errors from the above "$doit $instcmd $src $dsttmp" command.
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else true;fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else true;fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else true;fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else true;fi &&
+
+# Now rename the file to the real destination.
+
+	$doit $rmcmd -f $dstdir/$dstfile &&
+	$doit $mvcmd $dsttmp $dstdir/$dstfile 
+
+fi &&
+
+
+exit 0
diff --git a/crypto/heimdal/lib/roken/missing b/crypto/heimdal/lib/roken/missing
new file mode 100755
index 000000000000..7789652e877f
--- /dev/null
+++ b/crypto/heimdal/lib/roken/missing
@@ -0,0 +1,190 @@
+#! /bin/sh
+# Common stub for a few missing GNU programs while installing.
+# Copyright (C) 1996, 1997 Free Software Foundation, Inc.
+# Franc,ois Pinard <pinard@iro.umontreal.ca>, 1996.
+
+# 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.
+
+if test $# -eq 0; then
+  echo 1>&2 "Try \`$0 --help' for more information"
+  exit 1
+fi
+
+case "$1" in
+
+  -h|--h|--he|--hel|--help)
+    echo "\
+$0 [OPTION]... PROGRAM [ARGUMENT]...
+
+Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an
+error status if there is no known handling for PROGRAM.
+
+Options:
+  -h, --help      display this help and exit
+  -v, --version   output version information and exit
+
+Supported PROGRAM values:
+  aclocal      touch file \`aclocal.m4'
+  autoconf     touch file \`configure'
+  autoheader   touch file \`config.h.in'
+  automake     touch all \`Makefile.in' files
+  bison        create \`y.tab.[ch]', if possible, from existing .[ch]
+  flex         create \`lex.yy.c', if possible, from existing .c
+  lex          create \`lex.yy.c', if possible, from existing .c
+  makeinfo     touch the output file
+  yacc         create \`y.tab.[ch]', if possible, from existing .[ch]"
+    ;;
+
+  -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
+    echo "missing - GNU libit 0.0"
+    ;;
+
+  -*)
+    echo 1>&2 "$0: Unknown \`$1' option"
+    echo 1>&2 "Try \`$0 --help' for more information"
+    exit 1
+    ;;
+
+  aclocal)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`acinclude.m4' or \`configure.in'.  You might want
+         to install the \`Automake' and \`Perl' packages.  Grab them from
+         any GNU archive site."
+    touch aclocal.m4
+    ;;
+
+  autoconf)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`configure.in'.  You might want to install the
+         \`Autoconf' and \`GNU m4' packages.  Grab them from any GNU
+         archive site."
+    touch configure
+    ;;
+
+  autoheader)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`acconfig.h' or \`configure.in'.  You might want
+         to install the \`Autoconf' and \`GNU m4' packages.  Grab them
+         from any GNU archive site."
+    files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' configure.in`
+    test -z "$files" && files="config.h"
+    touch_files=
+    for f in $files; do
+      case "$f" in
+      *:*) touch_files="$touch_files "`echo "$f" |
+				       sed -e 's/^[^:]*://' -e 's/:.*//'`;;
+      *) touch_files="$touch_files $f.in";;
+      esac
+    done
+    touch $touch_files
+    ;;
+
+  automake)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`Makefile.am', \`acinclude.m4' or \`configure.in'.
+         You might want to install the \`Automake' and \`Perl' packages.
+         Grab them from any GNU archive site."
+    find . -type f -name Makefile.am -print |
+	   sed 's/\.am$/.in/' |
+	   while read f; do touch "$f"; done
+    ;;
+
+  bison|yacc)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.y' file.  You may need the \`Bison' package
+         in order for those modifications to take effect.  You can get
+         \`Bison' from any GNU archive site."
+    rm -f y.tab.c y.tab.h
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.y)
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.c
+	    fi
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.h
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f y.tab.h ]; then
+	echo >y.tab.h
+    fi
+    if [ ! -f y.tab.c ]; then
+	echo 'main() { return 0; }' >y.tab.c
+    fi
+    ;;
+
+  lex|flex)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.l' file.  You may need the \`Flex' package
+         in order for those modifications to take effect.  You can get
+         \`Flex' from any GNU archive site."
+    rm -f lex.yy.c
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.l)
+	    SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" lex.yy.c
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f lex.yy.c ]; then
+	echo 'main() { return 0; }' >lex.yy.c
+    fi
+    ;;
+
+  makeinfo)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.texi' or \`.texinfo' file, or any other file
+         indirectly affecting the aspect of the manual.  The spurious
+         call might also be the consequence of using a buggy \`make' (AIX,
+         DU, IRIX).  You might want to install the \`Texinfo' package or
+         the \`GNU make' package.  Grab either from any GNU archive site."
+    file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
+    if test -z "$file"; then
+      file=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
+      file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $file`
+    fi
+    touch $file
+    ;;
+
+  *)
+    echo 1>&2 "\
+WARNING: \`$1' is needed, and you do not seem to have it handy on your
+         system.  You might have modified some files without having the
+         proper tools for further handling them.  Check the \`README' file,
+         it often tells you about the needed prerequirements for installing
+         this package.  You may also peek at any GNU archive site, in case
+         some other package would contain this missing \`$1' program."
+    exit 1
+    ;;
+esac
+
+exit 0
diff --git a/crypto/heimdal/lib/roken/mkinstalldirs b/crypto/heimdal/lib/roken/mkinstalldirs
new file mode 100755
index 000000000000..6b3b5fc5d4d3
--- /dev/null
+++ b/crypto/heimdal/lib/roken/mkinstalldirs
@@ -0,0 +1,40 @@
+#! /bin/sh
+# mkinstalldirs --- make directory hierarchy
+# Author: Noah Friedman <friedman@prep.ai.mit.edu>
+# Created: 1993-05-16
+# Public domain
+
+# $Id$
+
+errstatus=0
+
+for file
+do
+   set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
+   shift
+
+   pathcomp=
+   for d
+   do
+     pathcomp="$pathcomp$d"
+     case "$pathcomp" in
+       -* ) pathcomp=./$pathcomp ;;
+     esac
+
+     if test ! -d "$pathcomp"; then
+        echo "mkdir $pathcomp"
+
+        mkdir "$pathcomp" || lasterr=$?
+
+        if test ! -d "$pathcomp"; then
+  	  errstatus=$lasterr
+        fi
+     fi
+
+     pathcomp="$pathcomp/"
+   done
+done
+
+exit $errstatus
+
+# mkinstalldirs ends here
diff --git a/crypto/heimdal/lib/roken/rtbl.c b/crypto/heimdal/lib/roken/rtbl.c
new file mode 100644
index 000000000000..098b601f5107
--- /dev/null
+++ b/crypto/heimdal/lib/roken/rtbl.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (c) 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: rtbl.c,v 1.3 2000/07/20 14:42:31 assar Exp $");
+#endif
+#include "roken.h"
+#include "rtbl.h"
+
+struct column_entry {
+    char *data;
+};
+
+struct column_data {
+    char *header;
+    char *prefix;
+    int width;
+    unsigned flags;
+    size_t num_rows;
+    struct column_entry *rows;
+};
+
+struct rtbl_data {
+    char *column_prefix;
+    size_t num_columns;
+    struct column_data **columns;
+};
+
+rtbl_t
+rtbl_create (void)
+{
+    return calloc (1, sizeof (struct rtbl_data));
+}
+
+static struct column_data *
+rtbl_get_column (rtbl_t table, const char *column)
+{
+    int i;
+    for(i = 0; i < table->num_columns; i++)
+	if(strcmp(table->columns[i]->header, column) == 0)
+	    return table->columns[i];
+    return NULL;
+}
+
+void
+rtbl_destroy (rtbl_t table)
+{
+    int i, j;
+
+    for (i = 0; i < table->num_columns; i++) {
+	struct column_data *c = table->columns[i];
+
+	for (j = 0; j < c->num_rows; j++)
+	    free (c->rows[j].data);
+	free (c->header);
+	free (c->prefix);
+	free (c);
+    }
+    free (table->column_prefix);
+    free (table->columns);
+}
+
+int
+rtbl_add_column (rtbl_t table, const char *header, unsigned int flags)
+{
+    struct column_data *col, **tmp;
+
+    tmp = realloc (table->columns, (table->num_columns + 1) * sizeof (*tmp));
+    if (tmp == NULL)
+	return ENOMEM;
+    table->columns = tmp;
+    col = malloc (sizeof (*col));
+    if (col == NULL)
+	return ENOMEM;
+    col->header = strdup (header);
+    if (col->header == NULL) {
+	free (col);
+	return ENOMEM;
+    }
+    col->prefix   = NULL;
+    col->width    = 0;
+    col->flags    = flags;
+    col->num_rows = 0;
+    col->rows     = NULL;
+    table->columns[table->num_columns++] = col;
+    return 0;
+}
+
+static void
+column_compute_width (struct column_data *column)
+{
+    int i;
+
+    column->width = strlen (column->header);
+    for (i = 0; i < column->num_rows; i++)
+	column->width = max (column->width, strlen (column->rows[i].data));
+}
+
+int
+rtbl_set_prefix (rtbl_t table, const char *prefix)
+{
+    if (table->column_prefix)
+	free (table->column_prefix);
+    table->column_prefix = strdup (prefix);
+    if (table->column_prefix == NULL)
+	return ENOMEM;
+    return 0;
+}
+
+int
+rtbl_set_column_prefix (rtbl_t table, const char *column,
+			const char *prefix)
+{
+    struct column_data *c = rtbl_get_column (table, column);
+
+    if (c == NULL)
+	return -1;
+    if (c->prefix)
+	free (c->prefix);
+    c->prefix = strdup (prefix);
+    if (c->prefix == NULL)
+	return ENOMEM;
+    return 0;
+}
+
+
+static const char *
+get_column_prefix (rtbl_t table, struct column_data *c)
+{
+    if (c == NULL)
+	return "";
+    if (c->prefix)
+	return c->prefix;
+    if (table->column_prefix)
+	return table->column_prefix;
+    return "";
+}
+
+int
+rtbl_add_column_entry (rtbl_t table, const char *column, const char *data)
+{
+    struct column_entry row, *tmp;
+
+    struct column_data *c = rtbl_get_column (table, column);
+
+    if (c == NULL)
+	return -1;
+
+    row.data = strdup (data);
+    if (row.data == NULL)
+	return ENOMEM;
+    tmp = realloc (c->rows, (c->num_rows + 1) * sizeof (*tmp));
+    if (tmp == NULL) {
+	free (row.data);
+	return ENOMEM;
+    }
+    c->rows = tmp;
+    c->rows[c->num_rows++] = row;
+    return 0;
+}
+
+int
+rtbl_format (rtbl_t table, FILE * f)
+{
+    int i, j;
+
+    for (i = 0; i < table->num_columns; i++)
+	column_compute_width (table->columns[i]);
+    for (i = 0; i < table->num_columns; i++) {
+	struct column_data *c = table->columns[i];
+
+	fprintf (f, "%s", get_column_prefix (table, c));
+	fprintf (f, "%-*s", (int)c->width, c->header);
+    }
+    fprintf (f, "\n");
+
+    for (j = 0;; j++) {
+	int flag = 0;
+
+	for (i = 0; flag == 0 && i < table->num_columns; ++i) {
+	    struct column_data *c = table->columns[i];
+
+	    if (c->num_rows > j) {
+		++flag;
+		break;
+	    }
+	}
+	if (flag == 0)
+	    break;
+
+	for (i = 0; i < table->num_columns; i++) {
+	    int w;
+	    struct column_data *c = table->columns[i];
+
+	    w = c->width;
+
+	    if ((c->flags & RTBL_ALIGN_RIGHT) == 0)
+		w = -w;
+	    fprintf (f, "%s", get_column_prefix (table, c));
+	    if (c->num_rows <= j)
+		fprintf (f, "%*s", w, "");
+	    else
+		fprintf (f, "%*s", w, c->rows[j].data);
+	}
+	fprintf (f, "\n");
+    }
+    return 0;
+}
+
+#ifdef TEST
+int
+main (int argc, char **argv)
+{
+    rtbl_t table;
+    unsigned int a, b, c, d;
+
+    table = rtbl_create ();
+    rtbl_add_column (table, "Issued", 0, &a);
+    rtbl_add_column (table, "Expires", 0, &b);
+    rtbl_add_column (table, "Foo", RTBL_ALIGN_RIGHT, &d);
+    rtbl_add_column (table, "Principal", 0, &c);
+
+    rtbl_add_column_entry (table, a, "Jul  7 21:19:29");
+    rtbl_add_column_entry (table, b, "Jul  8 07:19:29");
+    rtbl_add_column_entry (table, d, "73");
+    rtbl_add_column_entry (table, d, "0");
+    rtbl_add_column_entry (table, d, "-2000");
+    rtbl_add_column_entry (table, c, "krbtgt/NADA.KTH.SE@NADA.KTH.SE");
+
+    rtbl_add_column_entry (table, a, "Jul  7 21:19:29");
+    rtbl_add_column_entry (table, b, "Jul  8 07:19:29");
+    rtbl_add_column_entry (table, c, "afs/pdc.kth.se@NADA.KTH.SE");
+
+    rtbl_add_column_entry (table, a, "Jul  7 21:19:29");
+    rtbl_add_column_entry (table, b, "Jul  8 07:19:29");
+    rtbl_add_column_entry (table, c, "afs@NADA.KTH.SE");
+
+    rtbl_set_prefix (table, "  ");
+    rtbl_set_column_prefix (table, a, "");
+
+    rtbl_format (table, stdout);
+
+    rtbl_destroy (table);
+
+}
+
+#endif
diff --git a/crypto/heimdal/lib/roken/rtbl.h b/crypto/heimdal/lib/roken/rtbl.h
new file mode 100644
index 000000000000..16496a7fd205
--- /dev/null
+++ b/crypto/heimdal/lib/roken/rtbl.h
@@ -0,0 +1,57 @@
+/*
+ * Copyright (c) 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.
+ */
+
+#ifndef __rtbl_h__
+#define __rtbl_h__
+
+struct rtbl_data;
+typedef struct rtbl_data *rtbl_t;
+
+#define RTBL_ALIGN_LEFT		0
+#define RTBL_ALIGN_RIGHT	1
+
+rtbl_t rtbl_create (void);
+
+void rtbl_destroy (rtbl_t);
+
+int rtbl_set_prefix (rtbl_t, const char*);
+
+int rtbl_set_column_prefix (rtbl_t, const char*, const char*);
+
+int rtbl_add_column (rtbl_t, const char*, unsigned int);
+
+int rtbl_add_column_entry (rtbl_t, const char*, const char*);
+
+int rtbl_format (rtbl_t, FILE*);
+
+#endif /* __rtbl_h__ */
diff --git a/crypto/heimdal/lib/roken/strsep_copy.c b/crypto/heimdal/lib/roken/strsep_copy.c
new file mode 100644
index 000000000000..f09702234c75
--- /dev/null
+++ b/crypto/heimdal/lib/roken/strsep_copy.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 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: strsep_copy.c,v 1.3 2000/06/29 03:13:36 assar Exp $");
+#endif
+
+#include <string.h>
+
+#include "roken.h"
+
+#ifndef HAVE_STRSEP_COPY
+
+/* strsep, but with const stringp, so return string in buf */
+
+ssize_t
+strsep_copy(const char **stringp, const char *delim, char *buf, size_t len)
+{
+    const char *save = *stringp;
+    size_t l;
+    if(save == NULL)
+	return -1;
+    *stringp = *stringp + strcspn(*stringp, delim);
+    l = min(len, *stringp - save);
+    memcpy(buf, save, l);
+    buf[l] = '\0';
+
+    l = *stringp - save;
+    if(**stringp == '\0')
+	*stringp = NULL;
+    else
+	(*stringp)++;
+    return l;
+}
+
+#endif
diff --git a/crypto/heimdal/lib/roken/timeval.c b/crypto/heimdal/lib/roken/timeval.c
new file mode 100644
index 000000000000..ea4dee861810
--- /dev/null
+++ b/crypto/heimdal/lib/roken/timeval.c
@@ -0,0 +1,84 @@
+/*
+ * Copyright (c) 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.
+ */
+
+/*
+ * Timeval stuff
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+RCSID("$Id: timeval.c,v 1.1 2000/03/03 09:02:42 assar Exp $");
+#endif
+
+#include "roken.h"
+
+/*
+ * Make `t1' consistent.
+ */
+
+void
+timevalfix(struct timeval *t1)
+{
+    if (t1->tv_usec < 0) {
+        t1->tv_sec--;
+        t1->tv_usec += 1000000;
+    }
+    if (t1->tv_usec >= 1000000) {
+        t1->tv_sec++;
+        t1->tv_usec -= 1000000;
+    }
+}
+ 
+/*
+ * t1 += t2
+ */
+
+void
+timevaladd(struct timeval *t1, const struct timeval *t2)
+{
+    t1->tv_sec  += t2->tv_sec;
+    t1->tv_usec += t2->tv_usec;
+    timevalfix(t1);
+}
+ 
+/*
+ * t1 -= t2
+ */
+
+void
+timevalsub(struct timeval *t1, const struct timeval *t2)
+{
+    t1->tv_sec  -= t2->tv_sec;
+    t1->tv_usec -= t2->tv_usec;
+    timevalfix(t1);
+}
diff --git a/crypto/heimdal/lib/roken/unvis.c b/crypto/heimdal/lib/roken/unvis.c
new file mode 100644
index 000000000000..363564c04966
--- /dev/null
+++ b/crypto/heimdal/lib/roken/unvis.c
@@ -0,0 +1,288 @@
+/*	$NetBSD: unvis.c,v 1.19 2000/01/22 22:19:13 mycroft Exp $	*/
+
+/*-
+ * Copyright (c) 1989, 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.
+ */
+
+#if 1
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+RCSID("$Id: unvis.c,v 1.2 2000/12/06 21:41:46 joda Exp $");
+#endif
+#include <roken.h>
+#ifndef _DIAGASSERT
+#define _DIAGASSERT(X)
+#endif
+#else
+#include <sys/cdefs.h>
+#if defined(LIBC_SCCS) && !defined(lint)
+#if 0
+static char sccsid[] = "@(#)unvis.c	8.1 (Berkeley) 6/4/93";
+#else
+__RCSID("$NetBSD: unvis.c,v 1.19 2000/01/22 22:19:13 mycroft Exp $");
+#endif
+#endif /* LIBC_SCCS and not lint */
+
+#define __LIBC12_SOURCE__
+
+#include "namespace.h"
+#endif
+#include <sys/types.h>
+
+#include <assert.h>
+#include <ctype.h>
+#include <stdio.h>
+#include <vis.h>
+
+#if 0
+#ifdef __weak_alias
+__weak_alias(strunvis,_strunvis)
+__weak_alias(unvis,_unvis)
+#endif
+
+__warn_references(unvis,
+    "warning: reference to compatibility unvis(); include <vis.h> for correct reference")
+#endif
+
+/*
+ * decode driven by state machine
+ */
+#define	S_GROUND	0	/* haven't seen escape char */
+#define	S_START		1	/* start decoding special sequence */
+#define	S_META		2	/* metachar started (M) */
+#define	S_META1		3	/* metachar more, regular char (-) */
+#define	S_CTRL		4	/* control char started (^) */
+#define	S_OCTAL2	5	/* octal digit 2 */
+#define	S_OCTAL3	6	/* octal digit 3 */
+
+#define	isoctal(c)	(((u_char)(c)) >= '0' && ((u_char)(c)) <= '7')
+
+/*
+ * unvis - decode characters previously encoded by vis
+ */
+#ifndef HAVE_UNVIS
+int
+unvis(char *cp, int c, int *astate, int flag)
+{
+
+	_DIAGASSERT(cp != NULL);
+	_DIAGASSERT(astate != NULL);
+
+	if (flag & UNVIS_END) {
+		if (*astate == S_OCTAL2 || *astate == S_OCTAL3) {
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		} 
+		return (*astate == S_GROUND ? UNVIS_NOCHAR : UNVIS_SYNBAD);
+	}
+
+	switch (*astate) {
+
+	case S_GROUND:
+		*cp = 0;
+		if (c == '\\') {
+			*astate = S_START;
+			return (0);
+		} 
+		*cp = c;
+		return (UNVIS_VALID);
+
+	case S_START:
+		switch(c) {
+		case '\\':
+			*cp = c;
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case '0': case '1': case '2': case '3':
+		case '4': case '5': case '6': case '7':
+			*cp = (c - '0');
+			*astate = S_OCTAL2;
+			return (0);
+		case 'M':
+			*cp = (char)0200;
+			*astate = S_META;
+			return (0);
+		case '^':
+			*astate = S_CTRL;
+			return (0);
+		case 'n':
+			*cp = '\n';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 'r':
+			*cp = '\r';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 'b':
+			*cp = '\b';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 'a':
+			*cp = '\007';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 'v':
+			*cp = '\v';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 't':
+			*cp = '\t';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 'f':
+			*cp = '\f';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 's':
+			*cp = ' ';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case 'E':
+			*cp = '\033';
+			*astate = S_GROUND;
+			return (UNVIS_VALID);
+		case '\n':
+			/*
+			 * hidden newline
+			 */
+			*astate = S_GROUND;
+			return (UNVIS_NOCHAR);
+		case '$':
+			/*
+			 * hidden marker
+			 */
+			*astate = S_GROUND;
+			return (UNVIS_NOCHAR);
+		}
+		*astate = S_GROUND;
+		return (UNVIS_SYNBAD);
+		 
+	case S_META:
+		if (c == '-')
+			*astate = S_META1;
+		else if (c == '^')
+			*astate = S_CTRL;
+		else {
+			*astate = S_GROUND;
+			return (UNVIS_SYNBAD);
+		}
+		return (0);
+		 
+	case S_META1:
+		*astate = S_GROUND;
+		*cp |= c;
+		return (UNVIS_VALID);
+		 
+	case S_CTRL:
+		if (c == '?')
+			*cp |= 0177;
+		else
+			*cp |= c & 037;
+		*astate = S_GROUND;
+		return (UNVIS_VALID);
+
+	case S_OCTAL2:	/* second possible octal digit */
+		if (isoctal(c)) {
+			/* 
+			 * yes - and maybe a third 
+			 */
+			*cp = (*cp << 3) + (c - '0');
+			*astate = S_OCTAL3;	
+			return (0);
+		} 
+		/* 
+		 * no - done with current sequence, push back passed char 
+		 */
+		*astate = S_GROUND;
+		return (UNVIS_VALIDPUSH);
+
+	case S_OCTAL3:	/* third possible octal digit */
+		*astate = S_GROUND;
+		if (isoctal(c)) {
+			*cp = (*cp << 3) + (c - '0');
+			return (UNVIS_VALID);
+		}
+		/*
+		 * we were done, push back passed char
+		 */
+		return (UNVIS_VALIDPUSH);
+			
+	default:	
+		/* 
+		 * decoder in unknown state - (probably uninitialized) 
+		 */
+		*astate = S_GROUND;
+		return (UNVIS_SYNBAD);
+	}
+}
+#endif
+
+/*
+ * strunvis - decode src into dst 
+ *
+ *	Number of chars decoded into dst is returned, -1 on error.
+ *	Dst is null terminated.
+ */
+
+#ifndef HAVE_STRUNVIS
+int
+strunvis(char *dst, const char *src)
+{
+	char c;
+	char *start = dst;
+	int state = 0;
+
+	_DIAGASSERT(src != NULL);
+	_DIAGASSERT(dst != NULL);
+
+	while ((c = *src++) != '\0') {
+	again:
+		switch (unvis(dst, c, &state, 0)) {
+		case UNVIS_VALID:
+			dst++;
+			break;
+		case UNVIS_VALIDPUSH:
+			dst++;
+			goto again;
+		case 0:
+		case UNVIS_NOCHAR:
+			break;
+		default:
+			return (-1);
+		}
+	}
+	if (unvis(dst, c, &state, UNVIS_END) == UNVIS_VALID)
+		dst++;
+	*dst = '\0';
+	return (dst - start);
+}
+#endif
diff --git a/crypto/heimdal/lib/roken/vis.c b/crypto/heimdal/lib/roken/vis.c
new file mode 100644
index 000000000000..82a6ba5d006e
--- /dev/null
+++ b/crypto/heimdal/lib/roken/vis.c
@@ -0,0 +1,301 @@
+/*	$NetBSD: vis.c,v 1.19 2000/01/22 22:42:45 mycroft Exp $	*/
+
+/*-
+ * Copyright (c) 1999 The NetBSD Foundation, Inc.
+ * Copyright (c) 1989, 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.
+ */
+
+
+#if 1
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+RCSID("$Id: vis.c,v 1.3 2000/12/10 23:10:48 assar Exp $");
+#endif
+#include <roken.h>
+#ifndef _DIAGASSERT
+#define _DIAGASSERT(X)
+#endif
+#else
+#include <sys/cdefs.h>
+#if !defined(lint)
+__RCSID("$NetBSD: vis.c,v 1.19 2000/01/22 22:42:45 mycroft Exp $");
+#endif /* not lint */
+#endif
+
+#if 0
+#include "namespace.h"
+#endif
+#include <sys/types.h>
+
+#include <assert.h>
+#include <ctype.h>
+#include <limits.h>
+#include <stdio.h>
+#include <string.h>
+#include <vis.h>
+
+#if 0
+#ifdef __weak_alias
+__weak_alias(strsvis,_strsvis)
+__weak_alias(strsvisx,_strsvisx)
+__weak_alias(strvis,_strvis)
+__weak_alias(strvisx,_strvisx)
+__weak_alias(svis,_svis)
+__weak_alias(vis,_vis)
+#endif
+#endif
+
+#undef BELL
+#if defined(__STDC__)
+#define BELL '\a'
+#else
+#define BELL '\007'
+#endif
+
+#define isoctal(c)	(((u_char)(c)) >= '0' && ((u_char)(c)) <= '7')
+#define iswhite(c)	(c == ' ' || c == '\t' || c == '\n')
+#define issafe(c)	(c == '\b' || c == BELL || c == '\r')
+
+#define MAXEXTRAS       5
+
+
+#define MAKEEXTRALIST(flag, extra)					      \
+do {									      \
+	char *pextra = extra;						      \
+	if (flag & VIS_SP) *pextra++ = ' ';				      \
+	if (flag & VIS_TAB) *pextra++ = '\t';				      \
+	if (flag & VIS_NL) *pextra++ = '\n';				      \
+	if ((flag & VIS_NOSLASH) == 0) *pextra++ = '\\';		      \
+	*pextra = '\0';							      \
+} while (/*CONSTCOND*/0)
+
+/*
+ * This is SVIS, the central macro of vis.
+ * dst:	      Pointer to the destination buffer
+ * c:	      Character to encode
+ * flag:      Flag word
+ * nextc:     The character following 'c'
+ * extra:     Pointer to the list of extra characters to be
+ *	      backslash-protected.
+ */
+#define SVIS(dst, c, flag, nextc, extra)				      \
+do {									      \
+	int isextra, isc;						      \
+	isextra = strchr(extra, c) != NULL;				      \
+	if (!isextra && isascii(c) && (isgraph(c) || iswhite(c) ||	      \
+	    ((flag & VIS_SAFE) && issafe(c)))) {			      \
+		*dst++ = c;						      \
+		break;							      \
+	}								      \
+	isc = 0;							      \
+	if (flag & VIS_CSTYLE) {					      \
+		switch (c) {						      \
+		case '\n':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 'n';		      \
+			break;						      \
+		case '\r':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 'r';		      \
+			break;						      \
+		case '\b':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 'b';		      \
+			break;						      \
+		case BELL:						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 'a';		      \
+			break;						      \
+		case '\v':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 'v';		      \
+			break;						      \
+		case '\t':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 't';		      \
+			break;						      \
+		case '\f':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 'f';		      \
+			break;						      \
+		case ' ':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = 's';		      \
+			break;						      \
+		case '\0':						      \
+			isc = 1; *dst++ = '\\'; *dst++ = '0';		      \
+			if (isoctal(nextc)) {				      \
+				*dst++ = '0';				      \
+				*dst++ = '0';				      \
+			}						      \
+		}							      \
+	}								      \
+	if (isc) break;							      \
+	if (isextra || ((c & 0177) == ' ') || (flag & VIS_OCTAL)) {	      \
+		*dst++ = '\\';						      \
+		*dst++ = (u_char)(((unsigned)(u_char)c >> 6) & 03) + '0';     \
+		*dst++ = (u_char)(((unsigned)(u_char)c >> 3) & 07) + '0';     \
+		*dst++ =			     (c	      & 07) + '0';    \
+	} else {							      \
+		if ((flag & VIS_NOSLASH) == 0) *dst++ = '\\';		      \
+		if (c & 0200) {						      \
+			c &= 0177; *dst++ = 'M';			      \
+		}							      \
+		if (iscntrl(c)) {					      \
+			*dst++ = '^';					      \
+			if (c == 0177)					      \
+				*dst++ = '?';				      \
+			else						      \
+				*dst++ = c + '@';			      \
+		} else {						      \
+			*dst++ = '-'; *dst++ = c;			      \
+		}							      \
+	}								      \
+} while (/*CONSTCOND*/0)
+
+
+/*
+ * svis - visually encode characters, also encoding the characters
+ * 	  pointed to by `extra'
+ */
+#ifndef HAVE_SVIS
+char *
+svis(char *dst, int c, int flag, int nextc, const char *extra)
+{
+	_DIAGASSERT(dst != NULL);
+	_DIAGASSERT(extra != NULL);
+
+	SVIS(dst, c, flag, nextc, extra);
+	*dst = '\0';
+	return(dst);
+}
+#endif
+
+
+/*
+ * strsvis, strsvisx - visually encode characters from src into dst
+ *
+ *	Extra is a pointer to a \0-terminated list of characters to
+ *	be encoded, too. These functions are useful e. g. to
+ *	encode strings in such a way so that they are not interpreted
+ *	by a shell.
+ *	
+ *	Dst must be 4 times the size of src to account for possible
+ *	expansion.  The length of dst, not including the trailing NULL,
+ *	is returned. 
+ *
+ *	Strsvisx encodes exactly len bytes from src into dst.
+ *	This is useful for encoding a block of data.
+ */
+#ifndef HAVE_STRSVIS
+int
+strsvis(char *dst, const char *src, int flag, const char *extra)
+{
+	char c;
+	char *start;
+
+	_DIAGASSERT(dst != NULL);
+	_DIAGASSERT(src != NULL);
+	_DIAGASSERT(extra != NULL);
+
+	for (start = dst; (c = *src++) != '\0'; /* empty */)
+	    SVIS(dst, c, flag, *src, extra);
+	*dst = '\0';
+	return (dst - start);
+}
+#endif
+
+
+#ifndef HAVE_STRVISX
+int
+strsvisx(char *dst, const char *src, size_t len, int flag, const char *extra)
+{
+	char c;
+	char *start;
+
+	_DIAGASSERT(dst != NULL);
+	_DIAGASSERT(src != NULL);
+	_DIAGASSERT(extra != NULL);
+
+	for (start = dst; len > 0; len--) {
+		c = *src++;
+		SVIS(dst, c, flag, len ? *src : '\0', extra);
+	}
+	*dst = '\0';
+	return (dst - start);
+}
+#endif
+
+
+/*
+ * vis - visually encode characters
+ */
+#ifndef HAVE_VIS
+char *
+vis(char *dst, int c, int flag, int nextc)
+{
+	char extra[MAXEXTRAS];
+
+	_DIAGASSERT(dst != NULL);
+
+	MAKEEXTRALIST(flag, extra);
+	SVIS(dst, c, flag, nextc, extra);
+	*dst = '\0';
+	return (dst);
+}
+#endif
+
+
+/*
+ * strvis, strvisx - visually encode characters from src into dst
+ *	
+ *	Dst must be 4 times the size of src to account for possible
+ *	expansion.  The length of dst, not including the trailing NULL,
+ *	is returned. 
+ *
+ *	Strvisx encodes exactly len bytes from src into dst.
+ *	This is useful for encoding a block of data.
+ */
+#ifndef HAVE_STRVIS
+int
+strvis(char *dst, const char *src, int flag)
+{
+	char extra[MAXEXTRAS];
+
+	MAKEEXTRALIST(flag, extra);
+	return (strsvis(dst, src, flag, extra));
+}
+#endif
+
+
+#ifndef HAVE_STRVISX
+int
+strvisx(char *dst, const char *src, size_t len, int flag)
+{
+	char extra[MAXEXTRAS];
+
+	MAKEEXTRALIST(flag, extra);
+	return (strsvisx(dst, src, len, flag, extra));
+}
+#endif
diff --git a/crypto/heimdal/lib/roken/vis.hin b/crypto/heimdal/lib/roken/vis.hin
new file mode 100644
index 000000000000..a9d09da95829
--- /dev/null
+++ b/crypto/heimdal/lib/roken/vis.hin
@@ -0,0 +1,86 @@
+/*	$NetBSD: vis.h,v 1.11 1999/11/25 16:55:50 wennmach Exp $	*/
+/*	$Id: vis.hin,v 1.1 2000/12/06 21:35:47 joda Exp $	*/
+
+/*-
+ * Copyright (c) 1990, 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.
+ *
+ *	@(#)vis.h	8.1 (Berkeley) 6/2/93
+ */
+
+#ifndef _VIS_H_
+#define	_VIS_H_
+
+/*
+ * to select alternate encoding format
+ */
+#define	VIS_OCTAL	0x01	/* use octal \ddd format */
+#define	VIS_CSTYLE	0x02	/* use \[nrft0..] where appropiate */
+
+/*
+ * to alter set of characters encoded (default is to encode all
+ * non-graphic except space, tab, and newline).
+ */
+#define	VIS_SP		0x04	/* also encode space */
+#define	VIS_TAB		0x08	/* also encode tab */
+#define	VIS_NL		0x10	/* also encode newline */
+#define	VIS_WHITE	(VIS_SP | VIS_TAB | VIS_NL)
+#define	VIS_SAFE	0x20	/* only encode "unsafe" characters */
+
+/*
+ * other
+ */
+#define	VIS_NOSLASH	0x40	/* inhibit printing '\' */
+
+/*
+ * unvis return codes
+ */
+#define	UNVIS_VALID	 1	/* character valid */
+#define	UNVIS_VALIDPUSH	 2	/* character valid, push back passed char */
+#define	UNVIS_NOCHAR	 3	/* valid sequence, no character produced */
+#define	UNVIS_SYNBAD	-1	/* unrecognized escape sequence */
+#define	UNVIS_ERROR	-2	/* decoder in unknown state (unrecoverable) */
+
+/*
+ * unvis flags
+ */
+#define	UNVIS_END	1	/* no more characters */
+
+char	*vis (char *, int, int, int);
+char	*svis (char *, int, int, int, const char *);
+int	strvis (char *, const char *, int);
+int	strsvis (char *, const char *, int, const char *);
+int	strvisx (char *, const char *, size_t, int);
+int	strsvisx (char *, const char *, size_t, int, const char *);
+int	strunvis (char *, const char *);
+int	unvis (char *, int, int *, int);
+
+#endif /* !_VIS_H_ */
diff --git a/crypto/heimdal/lib/roken/write_pid.c b/crypto/heimdal/lib/roken/write_pid.c
new file mode 100644
index 000000000000..7d4fa24626e7
--- /dev/null
+++ b/crypto/heimdal/lib/roken/write_pid.c
@@ -0,0 +1,95 @@
+/*
+ * Copyright (c) 1999 - 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: write_pid.c,v 1.4 2000/08/04 11:19:41 joda Exp $");
+#endif
+
+#include <stdio.h>
+#include <sys/types.h>
+#include <unistd.h>
+#include <roken.h>
+
+#include "roken.h"
+
+char *
+pid_file_write (const char *progname)
+{
+    FILE *fp;
+    char *ret;
+
+    asprintf (&ret, "%s%s.pid", _PATH_VARRUN, progname);
+    if (ret == NULL)
+	return NULL;
+    fp = fopen (ret, "w");
+    if (fp == NULL) {
+	free (ret);
+	return NULL;
+    }
+    fprintf (fp, "%u", (unsigned)getpid());
+    fclose (fp);
+    return ret;
+}
+
+void
+pid_file_delete (char **filename)
+{
+    if (*filename != NULL) {
+	unlink (*filename);
+	free (*filename);
+	*filename = NULL;
+    }
+}
+
+#ifndef HAVE_PIDFILE
+static char *pidfile_path;
+
+static void
+pidfile_cleanup(void)
+{
+    if(pidfile_path != NULL)
+	pid_file_delete(&pidfile_path);
+}
+
+void
+pidfile(const char *basename)
+{
+    if(pidfile_path != NULL)
+	return;
+    if(basename == NULL)
+	basename = __progname;
+    pidfile_path = pid_file_write(basename);
+    atexit(pidfile_cleanup);
+}
+#endif
diff --git a/crypto/heimdal/lib/vers/ChangeLog b/crypto/heimdal/lib/vers/ChangeLog
new file mode 100644
index 000000000000..459c94009ccd
--- /dev/null
+++ b/crypto/heimdal/lib/vers/ChangeLog
@@ -0,0 +1,13 @@
+2001-01-31  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.am: remove -static turning this into a convenience
+	library
+
+2000-11-15  Assar Westerlund  <assar@sics.se>
+
+	* Makefile.am: make the library static and don't install it
+
+2000-07-08  Assar Westerlund  <assar@sics.se>
+
+	* make-print-version.c (heimdal_version, krb4_version): const-ize,
+	based on thorpej@netbsd.org's change to NetBSD
diff --git a/crypto/heimdal/lib/vers/Makefile.am b/crypto/heimdal/lib/vers/Makefile.am
new file mode 100644
index 000000000000..87ef2467ad6e
--- /dev/null
+++ b/crypto/heimdal/lib/vers/Makefile.am
@@ -0,0 +1,28 @@
+# $Id: Makefile.am,v 1.3 2001/01/31 03:50:48 assar Exp $
+
+include $(top_srcdir)/Makefile.am.common
+
+CLEANFILES		= print_version.h
+
+noinst_LTLIBRARIES	= libvers.la
+
+build_HEADERZ		= vers.h
+
+noinst_PROGRAMS		= make-print-version
+
+if KRB4
+if KRB5
+## need to link with des here; otherwise, if krb4 is shared the link
+## will fail with unresolved references
+make_print_version_LDADD += $(LIB_krb4) -ldes
+endif
+endif
+
+libvers_la_SOURCES	= print_version.c
+
+print_version.lo: print_version.h
+
+print_version.h: make-print-version$(EXEEXT)
+	./make-print-version$(EXEEXT) print_version.h
+
+make-print-version.o: $(top_builddir)/include/version.h
diff --git a/crypto/heimdal/lib/vers/Makefile.in b/crypto/heimdal/lib/vers/Makefile.in
new file mode 100644
index 000000000000..8b8da036d8fd
--- /dev/null
+++ b/crypto/heimdal/lib/vers/Makefile.in
@@ -0,0 +1,574 @@
+# Makefile.in generated automatically by automake 1.4a from Makefile.am
+
+# Copyright (C) 1994, 1995-9, 2000 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.
+
+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
+
+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@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_FLAG =
+transform = @program_transform_name@
+
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+
+@SET_MAKE@
+host_alias = @host_alias@
+host_triplet = @host@
+AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
+AMDEP = @AMDEP@
+AMTAR = @AMTAR@
+AS = @AS@
+AWK = @AWK@
+CANONICAL_HOST = @CANONICAL_HOST@
+CATMAN = @CATMAN@
+CATMANEXT = @CATMANEXT@
+CC = @CC@
+CPP = @CPP@
+CXX = @CXX@
+CXXCPP = @CXXCPP@
+DBLIB = @DBLIB@
+DEPDIR = @DEPDIR@
+DIR_des = @DIR_des@
+DIR_roken = @DIR_roken@
+DLLTOOL = @DLLTOOL@
+EXEEXT = @EXEEXT@
+EXTRA_LIB45 = @EXTRA_LIB45@
+GROFF = @GROFF@
+INCLUDES_roken = @INCLUDES_roken@
+INCLUDE_ = @INCLUDE_@
+LEX = @LEX@
+LIBOBJS = @LIBOBJS@
+LIBTOOL = @LIBTOOL@
+LIB_ = @LIB_@
+LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
+LIB_des = @LIB_des@
+LIB_des_appl = @LIB_des_appl@
+LIB_kdb = @LIB_kdb@
+LIB_otp = @LIB_otp@
+LIB_roken = @LIB_roken@
+LIB_security = @LIB_security@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAKEINFO = @MAKEINFO@
+NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@
+NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@
+NROFF = @NROFF@
+OBJDUMP = @OBJDUMP@
+OBJEXT = @OBJEXT@
+PACKAGE = @PACKAGE@
+RANLIB = @RANLIB@
+STRIP = @STRIP@
+VERSION = @VERSION@
+VOID_RETSIGTYPE = @VOID_RETSIGTYPE@
+WFLAGS = @WFLAGS@
+WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
+WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
+YACC = @YACC@
+dpagaix_CFLAGS = @dpagaix_CFLAGS@
+dpagaix_LDADD = @dpagaix_LDADD@
+install_sh = @install_sh@
+
+# $Id: Makefile.am,v 1.3 2001/01/31 03:50:48 assar Exp $
+
+
+# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $
+
+
+# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $
+
+
+AUTOMAKE_OPTIONS = foreign no-dependencies
+
+SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x
+
+INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken)
+
+AM_CFLAGS =  $(WFLAGS)
+
+CP = cp
+
+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_pidfile = @LIB_pidfile@
+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@
+
+LIBS = @LIBS@
+
+HESIODLIB = @HESIODLIB@
+HESIODINCLUDE = @HESIODINCLUDE@
+INCLUDE_hesiod = @INCLUDE_hesiod@
+LIB_hesiod = @LIB_hesiod@
+
+INCLUDE_krb4 = @INCLUDE_krb4@
+LIB_krb4 = @LIB_krb4@
+
+INCLUDE_openldap = @INCLUDE_openldap@
+LIB_openldap = @LIB_openldap@
+
+INCLUDE_readline = @INCLUDE_readline@
+
+LEXLIB = @LEXLIB@
+
+NROFF_MAN = groff -mandoc -Tascii
+
+@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
+
+@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
+@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
+@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la
+
+CHECK_LOCAL = $(PROGRAMS)
+
+CLEANFILES = print_version.h
+
+noinst_LTLIBRARIES = libvers.la
+
+build_HEADERZ = vers.h
+
+noinst_PROGRAMS = make-print-version
+
+@KRB4_TRUE@@KRB5_TRUE@make_print_version_LDADD = @KRB4_TRUE@@KRB5_TRUE@ $(LIB_krb4) -ldes
+
+libvers_la_SOURCES = print_version.c
+subdir = lib/vers
+mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
+CONFIG_HEADER = ../../include/config.h
+CONFIG_CLEAN_FILES = 
+LTLIBRARIES =  $(noinst_LTLIBRARIES)
+
+
+DEFS = @DEFS@ -I. -I$(srcdir) -I../../include
+CPPFLAGS = @CPPFLAGS@
+LDFLAGS = @LDFLAGS@
+X_CFLAGS = @X_CFLAGS@
+X_LIBS = @X_LIBS@
+X_EXTRA_LIBS = @X_EXTRA_LIBS@
+X_PRE_LIBS = @X_PRE_LIBS@
+libvers_la_LDFLAGS = 
+libvers_la_LIBADD = 
+am_libvers_la_OBJECTS =  print_version.lo
+libvers_la_OBJECTS =  $(am_libvers_la_OBJECTS)
+noinst_PROGRAMS =  make-print-version$(EXEEXT)
+PROGRAMS =  $(noinst_PROGRAMS)
+
+make_print_version_SOURCES = make-print-version.c
+make_print_version_OBJECTS =  make-print-version.$(OBJEXT)
+@KRB4_TRUE@@KRB5_TRUE@make_print_version_DEPENDENCIES = 
+make_print_version_LDFLAGS = 
+COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+CFLAGS = @CFLAGS@
+CCLD = $(CC)
+LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
+DIST_SOURCES =  $(libvers_la_SOURCES) make-print-version.c
+depcomp = 
+DIST_COMMON =  ChangeLog Makefile.am Makefile.in
+
+
+DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
+
+GZIP_ENV = --best
+SOURCES = $(libvers_la_SOURCES) make-print-version.c
+OBJECTS = $(am_libvers_la_OBJECTS) make-print-version.$(OBJEXT)
+
+all: all-redirect
+.SUFFIXES:
+.SUFFIXES: .1 .3 .5 .8 .c .cat1 .cat3 .cat5 .cat8 .et .h .lo .o .obj .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 lib/vers/Makefile
+
+Makefile: $(srcdir)/Makefile.in  $(top_builddir)/config.status
+	cd $(top_builddir) \
+	  && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
+
+
+mostlyclean-noinstLTLIBRARIES:
+
+clean-noinstLTLIBRARIES:
+	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
+
+distclean-noinstLTLIBRARIES:
+
+maintainer-clean-noinstLTLIBRARIES:
+
+mostlyclean-compile:
+	-rm -f *.o core *.core
+	-rm -f *.$(OBJEXT)
+
+clean-compile:
+
+distclean-compile:
+	-rm -f *.tab.c
+
+maintainer-clean-compile:
+
+mostlyclean-libtool:
+	-rm -f *.lo
+
+clean-libtool:
+	-rm -rf .libs _libs
+
+distclean-libtool:
+
+maintainer-clean-libtool:
+
+libvers.la: $(libvers_la_OBJECTS) $(libvers_la_DEPENDENCIES)
+	$(LINK)  $(libvers_la_LDFLAGS) $(libvers_la_OBJECTS) $(libvers_la_LIBADD) $(LIBS)
+
+mostlyclean-noinstPROGRAMS:
+
+clean-noinstPROGRAMS:
+	-test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)
+
+distclean-noinstPROGRAMS:
+
+maintainer-clean-noinstPROGRAMS:
+
+make-print-version$(EXEEXT): $(make_print_version_OBJECTS) $(make_print_version_DEPENDENCIES)
+	@rm -f make-print-version$(EXEEXT)
+	$(LINK) $(make_print_version_LDFLAGS) $(make_print_version_OBJECTS) $(make_print_version_LDADD) $(LIBS)
+.c.o:
+	$(COMPILE) -c $<
+.c.obj:
+	$(COMPILE) -c `cygpath -w $<`
+.c.lo:
+	$(LTCOMPILE) -c -o $@ $<
+
+tags: TAGS
+
+ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
+	list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \
+	unique=`for i in $$list; do \
+	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+	  done | \
+	  $(AWK) '    { files[$$0] = 1; } \
+	       END { for (i in files) print i; }'`; \
+	mkid -fID $$unique $(LISP)
+
+TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
+		$(TAGS_FILES) $(LISP)
+	tags=; \
+	here=`pwd`; \
+	list='$(SOURCES) $(HEADERS) $(TAGS_FILES)'; \
+	unique=`for i in $$list; do \
+	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+	  done | \
+	  $(AWK) '    { files[$$0] = 1; } \
+	       END { for (i in files) print i; }'`; \
+	test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
+	  || etags $(ETAGS_ARGS) $$tags  $$unique $(LISP)
+
+mostlyclean-tags:
+
+clean-tags:
+
+distclean-tags:
+	-rm -f TAGS ID
+
+maintainer-clean-tags:
+
+distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
+
+distdir: $(DISTFILES)
+	@for file in $(DISTFILES); do \
+	  d=$(srcdir); \
+	  if test -d $$d/$$file; then \
+	    cp -pR $$d/$$file $(distdir) \
+	    || exit 1; \
+	  else \
+	    test -f $(distdir)/$$file \
+	    || cp -p $$d/$$file $(distdir)/$$file \
+	    || exit 1; \
+	  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:
+	@$(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: uninstall-am
+all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) all-local
+all-redirect: all-am
+install-strip:
+	$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
+installdirs:
+
+
+mostlyclean-generic:
+
+clean-generic:
+	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
+
+distclean-generic:
+	-rm -f Makefile $(CONFIG_CLEAN_FILES)
+	-rm -f config.cache config.log stamp-h stamp-h[0-9]*
+
+maintainer-clean-generic:
+	-rm -f Makefile.in
+mostlyclean-am:  mostlyclean-noinstLTLIBRARIES mostlyclean-compile \
+		mostlyclean-libtool mostlyclean-noinstPROGRAMS \
+		mostlyclean-tags mostlyclean-generic
+
+mostlyclean: mostlyclean-am
+
+clean-am:  clean-noinstLTLIBRARIES clean-compile clean-libtool \
+		clean-noinstPROGRAMS clean-tags clean-generic \
+		mostlyclean-am
+
+clean: clean-am
+
+distclean-am:  distclean-noinstLTLIBRARIES distclean-compile \
+		distclean-libtool distclean-noinstPROGRAMS \
+		distclean-tags distclean-generic clean-am
+	-rm -f libtool
+
+distclean: distclean-am
+
+maintainer-clean-am:  maintainer-clean-noinstLTLIBRARIES \
+		maintainer-clean-compile maintainer-clean-libtool \
+		maintainer-clean-noinstPROGRAMS 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-noinstLTLIBRARIES distclean-noinstLTLIBRARIES \
+clean-noinstLTLIBRARIES maintainer-clean-noinstLTLIBRARIES \
+mostlyclean-compile distclean-compile clean-compile \
+maintainer-clean-compile mostlyclean-libtool distclean-libtool \
+clean-libtool maintainer-clean-libtool mostlyclean-noinstPROGRAMS \
+distclean-noinstPROGRAMS clean-noinstPROGRAMS \
+maintainer-clean-noinstPROGRAMS 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-am \
+install-exec install-data-local install-data-am install-data install-am \
+install uninstall-am uninstall all-local all-redirect all-am all \
+install-strip 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 \
+	echo "*"; \
+	echo "* Failed to install $$x setuid root"; \
+	echo "*"; \
+	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-cat-mans:
+	$(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_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
+
+print_version.lo: print_version.h
+
+print_version.h: make-print-version$(EXEEXT)
+	./make-print-version$(EXEEXT) print_version.h
+
+make-print-version.o: $(top_builddir)/include/version.h
+
+# 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/lib/vers/make-print-version.c b/crypto/heimdal/lib/vers/make-print-version.c
new file mode 100644
index 000000000000..6102e75abde5
--- /dev/null
+++ b/crypto/heimdal/lib/vers/make-print-version.c
@@ -0,0 +1,68 @@
+/*
+ * 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.2 2000/07/08 10:46:36 assar Exp $");
+#endif
+
+#include <stdio.h>
+
+#ifdef KRB5
+extern const char *heimdal_version;
+#endif
+#ifdef KRB4
+extern const 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/vers/print_version.c b/crypto/heimdal/lib/vers/print_version.c
new file mode 100644
index 000000000000..cb324d0917f9
--- /dev/null
+++ b/crypto/heimdal/lib/vers/print_version.c
@@ -0,0 +1,78 @@
+/*
+ * 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: print_version.c,v 1.1 2000/07/01 19:47:35 assar Exp $");
+#endif
+#include "roken.h"
+
+#include "print_version.h"
+
+void
+print_version(const char *progname)
+{
+    const char *arg[] = VERSIONLIST;
+    const int num_args = sizeof(arg) / sizeof(arg[0]);
+    char *msg;
+    size_t len = 0;
+    int i;
+    
+    if(progname == NULL)
+	progname = __progname;
+    
+    if(num_args == 0)
+	msg = "no version information";
+    else {
+	for(i = 0; i < num_args; i++) {
+	    if(i > 0)
+		len += 2;
+	    len += strlen(arg[i]);
+	}
+	msg = malloc(len + 1);
+	if(msg == NULL) {
+	    fprintf(stderr, "%s: out of memory\n", progname);
+	    return;
+	}
+	msg[0] = '\0';
+	for(i = 0; i < num_args; i++) {
+	    if(i > 0)
+		strcat(msg, ", ");
+	    strcat(msg, arg[i]);
+	}
+    }
+    fprintf(stderr, "%s (%s)\n", progname, msg);
+    fprintf(stderr, "Copyright (c) 1999 - 2000 Kungliga Tekniska Högskolan\n");
+    if(num_args != 0)
+	free(msg);
+}
diff --git a/crypto/heimdal/lib/vers/vers.h b/crypto/heimdal/lib/vers/vers.h
new file mode 100644
index 000000000000..cc70355f42fa
--- /dev/null
+++ b/crypto/heimdal/lib/vers/vers.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (c) 1995 - 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.
+ */
+
+/* $Id: vers.h,v 1.1 2000/07/01 19:47:36 assar Exp $ */
+
+#ifndef __VERS_H__
+#define __VERS_H__
+
+void print_version(const char *);
+
+#endif /*  __VERS_H__ */
diff --git a/crypto/heimdal/tools/Makefile.am b/crypto/heimdal/tools/Makefile.am
new file mode 100644
index 000000000000..4f0290495ae6
--- /dev/null
+++ b/crypto/heimdal/tools/Makefile.am
@@ -0,0 +1,25 @@
+# $Id: Makefile.am,v 1.5 2001/01/29 06:56:33 assar Exp $
+
+include $(top_srcdir)/Makefile.am.common
+
+EXTRA_DIST = krb5-config.1
+
+CLEANFILES = krb5-config
+
+bin_SCRIPTS = krb5-config
+
+man_MANS = krb5-config.1
+
+krb5-config: krb5-config.in
+	sed	-e "s,@PACKAGE\@,$(PACKAGE),g" \
+		-e "s,@VERSION\@,$(VERSION),g" \
+		-e "s,@prefix\@,$(prefix),g" \
+		-e "s,@exec_prefix\@,$(exec_prefix),g" \
+		-e "s,@libdir\@,$(libdir),g" \
+		-e "s,@includedir\@,$(includedir),g" \
+		-e "s,@LIB_crypt\@,$(LIB_crypt),g" \
+		-e "s,@LIB_dbopen\@,$(LIB_dbopen),g" \
+		-e "s,@LIB_des_appl\@,$(LIB_des_appl),g" \
+		-e "s,@LIBS\@,$(LIBS),g" \
+		$(srcdir)/krb5-config.in > $@
+	chmod +x $@
diff --git a/crypto/heimdal/tools/Makefile.in b/crypto/heimdal/tools/Makefile.in
new file mode 100644
index 000000000000..85afdc4d6501
--- /dev/null
+++ b/crypto/heimdal/tools/Makefile.in
@@ -0,0 +1,524 @@
+# Makefile.in generated automatically by automake 1.4a from Makefile.am
+
+# Copyright (C) 1994, 1995-9, 2000 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.
+
+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
+
+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@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_FLAG =
+transform = @program_transform_name@
+
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+
+@SET_MAKE@
+host_alias = @host_alias@
+host_triplet = @host@
+AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
+AMDEP = @AMDEP@
+AMTAR = @AMTAR@
+AS = @AS@
+AWK = @AWK@
+CANONICAL_HOST = @CANONICAL_HOST@
+CATMAN = @CATMAN@
+CATMANEXT = @CATMANEXT@
+CC = @CC@
+CPP = @CPP@
+CXX = @CXX@
+CXXCPP = @CXXCPP@
+DBLIB = @DBLIB@
+DEPDIR = @DEPDIR@
+DIR_des = @DIR_des@
+DIR_roken = @DIR_roken@
+DLLTOOL = @DLLTOOL@
+EXEEXT = @EXEEXT@
+EXTRA_LIB45 = @EXTRA_LIB45@
+GROFF = @GROFF@
+INCLUDES_roken = @INCLUDES_roken@
+INCLUDE_ = @INCLUDE_@
+LEX = @LEX@
+LIBOBJS = @LIBOBJS@
+LIBTOOL = @LIBTOOL@
+LIB_ = @LIB_@
+LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
+LIB_des = @LIB_des@
+LIB_des_appl = @LIB_des_appl@
+LIB_kdb = @LIB_kdb@
+LIB_otp = @LIB_otp@
+LIB_roken = @LIB_roken@
+LIB_security = @LIB_security@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAKEINFO = @MAKEINFO@
+NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@
+NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@
+NROFF = @NROFF@
+OBJDUMP = @OBJDUMP@
+OBJEXT = @OBJEXT@
+PACKAGE = @PACKAGE@
+RANLIB = @RANLIB@
+STRIP = @STRIP@
+VERSION = @VERSION@
+VOID_RETSIGTYPE = @VOID_RETSIGTYPE@
+WFLAGS = @WFLAGS@
+WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
+WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
+YACC = @YACC@
+dpagaix_CFLAGS = @dpagaix_CFLAGS@
+dpagaix_LDADD = @dpagaix_LDADD@
+install_sh = @install_sh@
+
+# $Id: Makefile.am,v 1.5 2001/01/29 06:56:33 assar Exp $
+
+
+# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $
+
+
+# $Id: Makefile.am.common,v 1.23 2000/12/05 09:11:09 joda Exp $
+
+
+AUTOMAKE_OPTIONS = foreign no-dependencies
+
+SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x
+
+INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken)
+
+AM_CFLAGS =  $(WFLAGS)
+
+CP = cp
+
+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_pidfile = @LIB_pidfile@
+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@
+
+LIBS = @LIBS@
+
+HESIODLIB = @HESIODLIB@
+HESIODINCLUDE = @HESIODINCLUDE@
+INCLUDE_hesiod = @INCLUDE_hesiod@
+LIB_hesiod = @LIB_hesiod@
+
+INCLUDE_krb4 = @INCLUDE_krb4@
+LIB_krb4 = @LIB_krb4@
+
+INCLUDE_openldap = @INCLUDE_openldap@
+LIB_openldap = @LIB_openldap@
+
+INCLUDE_readline = @INCLUDE_readline@
+
+LEXLIB = @LEXLIB@
+
+NROFF_MAN = groff -mandoc -Tascii
+
+@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
+
+@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
+@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
+@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la
+
+CHECK_LOCAL = $(PROGRAMS)
+
+EXTRA_DIST = krb5-config.1
+
+CLEANFILES = krb5-config
+
+bin_SCRIPTS = krb5-config
+
+man_MANS = krb5-config.1
+subdir = tools
+mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
+CONFIG_HEADER = ../include/config.h
+CONFIG_CLEAN_FILES = 
+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) $(AM_LDFLAGS) $(LDFLAGS) -o $@
+DIST_SOURCES = 
+man1dir = $(mandir)/man1
+MANS = $(man_MANS)
+depcomp = 
+DIST_COMMON =  Makefile.am Makefile.in
+
+
+DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
+
+GZIP_ENV = --best
+all: all-redirect
+.SUFFIXES:
+.SUFFIXES: .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .et .h .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 tools/Makefile
+
+Makefile: $(srcdir)/Makefile.in  $(top_builddir)/config.status
+	cd $(top_builddir) \
+	  && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
+
+
+install-binSCRIPTS: $(bin_SCRIPTS)
+	@$(NORMAL_INSTALL)
+	$(mkinstalldirs) $(DESTDIR)$(bindir)
+	@list='$(bin_SCRIPTS)'; for p in $$list; do \
+	  f="`echo $$p|sed '$(transform)'`"; \
+	  if test -f $$p; then \
+	    echo " $(INSTALL_SCRIPT) $$p $(DESTDIR)$(bindir)/$$f"; \
+	    $(INSTALL_SCRIPT) $$p $(DESTDIR)$(bindir)/$$f; \
+	  elif test -f $(srcdir)/$$p; then \
+	    echo " $(INSTALL_SCRIPT) $(srcdir)/$$p $(DESTDIR)$(bindir)/$$f"; \
+	    $(INSTALL_SCRIPT) $(srcdir)/$$p $(DESTDIR)$(bindir)/$$f; \
+	  else :; fi; \
+	done
+
+uninstall-binSCRIPTS:
+	@$(NORMAL_UNINSTALL)
+	@list='$(bin_SCRIPTS)'; for p in $$list; do \
+	  f="`echo $$p|sed '$(transform)'`"; \
+	  echo " rm -f $(DESTDIR)$(bindir)/$$f"; \
+	  rm -f $(DESTDIR)$(bindir)/$$f; \
+	done
+
+install-man1:
+	$(mkinstalldirs) $(DESTDIR)$(man1dir)
+	@list='$(man1_MANS)'; \
+	l2='$(man_MANS)'; for i in $$l2; do \
+	  case "$$i" in \
+	    *.1*) list="$$list $$i" ;; \
+	  esac; \
+	done; \
+	for i in $$list; do \
+	  if test -f $(srcdir)/$$i; then file=$(srcdir)/$$i; \
+	  else file=$$i; fi; \
+	  ext=`echo $$i | sed -e 's/^.*\\.//'`; \
+	  inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \
+	  inst=`echo $$inst | sed -e 's/^.*\///'`; \
+	  inst=`echo $$inst | sed '$(transform)'`.$$ext; \
+	  echo " $(INSTALL_DATA) $$file $(DESTDIR)$(man1dir)/$$inst"; \
+	  $(INSTALL_DATA) $$file $(DESTDIR)$(man1dir)/$$inst; \
+	done
+
+uninstall-man1:
+	@list='$(man1_MANS)'; \
+	l2='$(man_MANS)'; for i in $$l2; do \
+	  case "$$i" in \
+	    *.1*) list="$$list $$i" ;; \
+	  esac; \
+	done; \
+	for i in $$list; do \
+	  ext=`echo $$i | sed -e 's/^.*\\.//'`; \
+	  inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \
+	  inst=`echo $$inst | sed -e 's/^.*\///'`; \
+	  inst=`echo $$inst | sed '$(transform)'`.$$ext; \
+	  echo " rm -f $(DESTDIR)$(man1dir)/$$inst"; \
+	  rm -f $(DESTDIR)$(man1dir)/$$inst; \
+	done
+install-man: $(MANS)
+	@$(NORMAL_INSTALL)
+	$(MAKE) $(AM_MAKEFLAGS) install-man1
+uninstall-man:
+	@$(NORMAL_UNINSTALL)
+	$(MAKE) $(AM_MAKEFLAGS) uninstall-man1
+tags: TAGS
+TAGS:
+
+
+distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
+
+distdir: $(DISTFILES)
+	@for file in $(DISTFILES); do \
+	  d=$(srcdir); \
+	  if test -d $$d/$$file; then \
+	    cp -pR $$d/$$file $(distdir) \
+	    || exit 1; \
+	  else \
+	    test -f $(distdir)/$$file \
+	    || cp -p $$d/$$file $(distdir)/$$file \
+	    || exit 1; \
+	  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-binSCRIPTS
+	@$(NORMAL_INSTALL)
+	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
+install-exec: install-exec-am
+
+install-data-am: install-man 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-binSCRIPTS uninstall-man
+uninstall: uninstall-am
+all-am: Makefile $(SCRIPTS) $(MANS) all-local
+all-redirect: all-am
+install-strip:
+	$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
+installdirs:
+	$(mkinstalldirs)  $(DESTDIR)$(bindir) $(DESTDIR)$(mandir)/man1
+
+
+mostlyclean-generic:
+
+clean-generic:
+	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
+
+distclean-generic:
+	-rm -f Makefile $(CONFIG_CLEAN_FILES)
+	-rm -f config.cache config.log stamp-h stamp-h[0-9]*
+
+maintainer-clean-generic:
+	-rm -f Makefile.in
+mostlyclean-am:  mostlyclean-generic
+
+mostlyclean: mostlyclean-am
+
+clean-am:  clean-generic mostlyclean-am
+
+clean: clean-am
+
+distclean-am:  distclean-generic clean-am
+	-rm -f libtool
+
+distclean: distclean-am
+
+maintainer-clean-am:  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: uninstall-binSCRIPTS install-binSCRIPTS install-man1 \
+uninstall-man1 install-man uninstall-man tags distdir info-am info \
+dvi-am dvi check-local check check-am installcheck-am installcheck \
+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 install-strip 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 \
+	echo "*"; \
+	echo "* Failed to install $$x setuid root"; \
+	echo "*"; \
+	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-cat-mans:
+	$(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_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
+
+krb5-config: krb5-config.in
+	sed	-e "s,@PACKAGE\@,$(PACKAGE),g" \
+		-e "s,@VERSION\@,$(VERSION),g" \
+		-e "s,@prefix\@,$(prefix),g" \
+		-e "s,@exec_prefix\@,$(exec_prefix),g" \
+		-e "s,@libdir\@,$(libdir),g" \
+		-e "s,@includedir\@,$(includedir),g" \
+		-e "s,@LIB_crypt\@,$(LIB_crypt),g" \
+		-e "s,@LIB_dbopen\@,$(LIB_dbopen),g" \
+		-e "s,@LIB_des_appl\@,$(LIB_des_appl),g" \
+		-e "s,@LIBS\@,$(LIBS),g" \
+		$(srcdir)/krb5-config.in > $@
+	chmod +x $@
+
+# 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/tools/krb5-config.1 b/crypto/heimdal/tools/krb5-config.1
new file mode 100644
index 000000000000..1eb2e09054d2
--- /dev/null
+++ b/crypto/heimdal/tools/krb5-config.1
@@ -0,0 +1,60 @@
+.\" $Id: krb5-config.1,v 1.3 2000/12/01 04:59:53 assar Exp $
+.\"
+.Dd November 30, 2000
+.Dt KRB5-CONFIG 1
+.Os HEIMDAL
+.Sh NAME
+.Nm krb5-config
+.Nd
+give information on how to link code against Heimdal libraries
+.Sh SYNOPSIS
+.Nm
+.Op Fl -prefix Ns Op = Ns Ar dir
+.Op Fl -exec-prefix Ns Op = Ns Ar dir
+.Op Fl -libs
+.Op Fl -cflags
+.Op Ar libraries
+.Sh DESCRIPTION
+.Nm
+tells the application programmer what special flags to use to compile
+and link programs against the libraries installed by Heimdal.
+.Pp
+Options supported:
+.Bl -tag -width Ds
+.It Fl -prefix Ns Op = Ns Ar dir
+Print the prefix if no
+.Ar dir
+is specified, otherwise set prefix to
+.Ar dir .
+.It Fl -exec-prefix Ns Op = Ns Ar dir
+Print the exec-prefix if no
+.Ar dir
+is specified, otherwise set exec-prefix to
+.Ar dir .
+.It Fl -libs
+Output the set of libraries that should be linked against.
+.It Fl -cflags
+Output the set of flags to give to the C compiler when using the
+Heimdal libraries.
+.El
+.Pp
+By default
+.Nm
+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:
+.Bl -tag -width Ds
+.It krb5
+(the default)
+.It gssapi
+use the krb5 gssapi mechanism
+.It kadm-client
+use the client-side kadmin libraries
+.It kadm-server
+use the server-side kadmin libraries
+.El
+.Sh SEE ALSO
+.Xr cc 1
+.Sh HISTORY
+.Nm
+appeared in Heimdal 0.3d.
diff --git a/crypto/heimdal/tools/krb5-config.in b/crypto/heimdal/tools/krb5-config.in
new file mode 100755
index 000000000000..e1235ac31730
--- /dev/null
+++ b/crypto/heimdal/tools/krb5-config.in
@@ -0,0 +1,110 @@
+#!/bin/sh
+# $Id: krb5-config.in,v 1.8 2001/01/29 06:56:51 assar Exp $
+
+do_libs=no
+do_cflags=no
+do_usage=no
+print_prefix=no
+print_exec_prefix=no
+library=krb5
+
+if test $# -eq 0; then
+  do_usage=yes
+  usage_exit=1
+fi
+
+for i in $*; do
+  case $i in
+  --help)
+    do_usage=yes
+    usage_exit=0
+    ;;
+  --version)
+    echo "@PACKAGE@ @VERSION@"
+    echo '$Id: krb5-config.in,v 1.8 2001/01/29 06:56:51 assar Exp $'
+    exit 0
+    ;;
+  --prefix=*)
+    prefix=`echo $i | sed 's/^--prefix=//'`
+    ;;
+  --prefix)
+    print_prefix=yes
+    ;;
+  --exec-prefix=*)
+    exec_prefix=`echo $i | sed 's/^--exec-prefix=//'`
+    ;;
+  --exec-prefix)
+    print_exec_prefix=yes
+    ;;
+  --libs)
+    do_libs=yes
+    ;;
+  --cflags)
+    do_cflags=yes
+    ;;
+  krb5)
+    library=krb5
+    ;;
+  gssapi)
+    library=gssapi
+    ;;
+  kadm-client)
+    library=kadm-client
+    ;;
+  kadm-server)
+    library=kadm-server
+    ;;
+  *)
+    echo "unknown option: $i"
+    exit 1
+    ;;
+  esac
+done
+
+if test "$do_usage" = "yes"; then
+    echo "usage: $0 [options] [libraries]"
+    echo "options: [--prefix[=dir]] [--exec-prefix[=dir]] [--libs] [--cflags]"
+    echo "libraries: krb5 gssapi kadm-client kadm-server"
+    exit $usage_exit
+fi
+
+if test "$prefix" = ""; then
+  prefix=@prefix@
+fi
+if test "$exec_prefix" = ""; then
+  exec_prefix=@exec_prefix@
+fi
+
+libdir=@libdir@
+includedir=@includedir@
+
+if test "$print_prefix" = "yes"; then
+    echo $prefix
+fi
+
+if test "$print_exec_prefix" = "yes"; then
+    echo $exec_prefix
+fi
+
+if test "$do_libs" = "yes"; then
+    lib_flags="-L${libdir}"
+    case $library in
+    gssapi)
+	lib_flags="$lib_flags -lgssapi"
+	;;
+    kadm-client)
+	lib_flags="$lib_flags -lkadm5clnt"
+	;;
+    kadm-server)
+	lib_flags="$lib_flags -lkadm5srv"
+	;;
+    esac
+    lib_flags="$lib_flags -lkrb5 -lasn1 @LIB_des_appl@ -lroken"
+    lib_flags="$lib_flags @LIB_crypt@ @LIB_dbopen@ @LIBS@"
+    echo $lib_flags
+fi
+if test "$do_cflags" = "yes"; then
+    echo "-I${includedir}"
+fi
+
+exit 0