Import of Heimdal Kerberos from KTH repository circa 2002/02/17.

7 files changed, 1134 insertions, 195 deletions

diff --git a/crypto/heimdal/doc/Makefile.in b/crypto/heimdal/doc/Makefile.in
index ffc5d89..83c8287 100644
--- a/crypto/heimdal/doc/Makefile.in
+++ b/crypto/heimdal/doc/Makefile.in
@@ -1,6 +1,6 @@
-# Makefile.in generated automatically by automake 1.4b from Makefile.am
+# Makefile.in generated automatically by automake 1.5 from Makefile.am.
 
-# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000
+# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
 # Free Software Foundation, Inc.
 # This Makefile.in is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -11,6 +11,16 @@
 # even the implied warranty of MERCHANTABILITY or FITNESS FOR A
 # PARTICULAR PURPOSE.
 
+@SET_MAKE@
+
+# $Id: Makefile.am,v 1.6 1999/03/20 13:58:16 joda Exp $
+
+
+# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $
+
+
+# $Id: Makefile.am.common,v 1.31 2001/09/01 11:12:18 assar Exp $
+
 SHELL = @SHELL@
 
 srcdir = @srcdir@
@@ -31,11 +41,9 @@ infodir = @infodir@
 mandir = @mandir@
 includedir = @includedir@
 oldincludedir = /usr/include
-
 pkgdatadir = $(datadir)/@PACKAGE@
 pkglibdir = $(libdir)/@PACKAGE@
 pkgincludedir = $(includedir)/@PACKAGE@
-
 top_builddir = ..
 
 ACLOCAL = @ACLOCAL@
@@ -47,21 +55,17 @@ INSTALL = @INSTALL@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
-INSTALL_STRIP_FLAG =
+INSTALL_HEADER = $(INSTALL_DATA)
 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@
@@ -69,11 +73,11 @@ CANONICAL_HOST = @CANONICAL_HOST@
 CATMAN = @CATMAN@
 CATMANEXT = @CATMANEXT@
 CC = @CC@
+COMPILE_ET = @COMPILE_ET@
 CPP = @CPP@
-CXX = @CXX@
-CXXCPP = @CXXCPP@
 DBLIB = @DBLIB@
 DEPDIR = @DEPDIR@
+DIR_com_err = @DIR_com_err@
 DIR_des = @DIR_des@
 DIR_roken = @DIR_roken@
 DLLTOOL = @DLLTOOL@
@@ -82,20 +86,27 @@ EXTRA_LIB45 = @EXTRA_LIB45@
 GROFF = @GROFF@
 INCLUDES_roken = @INCLUDES_roken@
 INCLUDE_ = @INCLUDE_@
+INCLUDE_des = @INCLUDE_des@
+INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
 LEX = @LEX@
 LIBOBJS = @LIBOBJS@
 LIBTOOL = @LIBTOOL@
 LIB_ = @LIB_@
 LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
+LIB_NDBM = @LIB_NDBM@
+LIB_com_err = @LIB_com_err@
+LIB_com_err_a = @LIB_com_err_a@
+LIB_com_err_so = @LIB_com_err_so@
 LIB_des = @LIB_des@
+LIB_des_a = @LIB_des_a@
 LIB_des_appl = @LIB_des_appl@
+LIB_des_so = @LIB_des_so@
 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@
@@ -103,38 +114,32 @@ 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@
+X_CFLAGS = @X_CFLAGS@
+X_EXTRA_LIBS = @X_EXTRA_LIBS@
+X_LIBS = @X_LIBS@
+X_PRE_LIBS = @X_PRE_LIBS@
 YACC = @YACC@
+am__include = @am__include@
+am__quote = @am__quote@
 dpagaix_CFLAGS = @dpagaix_CFLAGS@
 dpagaix_LDADD = @dpagaix_LDADD@
 install_sh = @install_sh@
 
-# $Id: Makefile.am,v 1.6 1999/03/20 13:58:16 joda Exp $
-
-
-# $Id: Makefile.am.common,v 1.3 1999/04/01 14:58:43 joda Exp $
-
-
-# $Id: Makefile.am.common,v 1.26 2001/05/21 13:27:48 joda Exp $
-
-
-AUTOMAKE_OPTIONS = foreign no-dependencies no-texinfo.tex
+AUTOMAKE_OPTIONS = foreign no-dependencies 1.4b no-texinfo.tex
 
 SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x
 
 INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken)
 
-AM_CFLAGS =  $(WFLAGS)
+AM_CFLAGS = $(WFLAGS)
 
 CP = cp
 
-COMPILE_ET = $(top_builddir)/lib/com_err/compile_et
-
 buildinclude = $(top_builddir)/include
 
 LIB_XauReadAuth = @LIB_XauReadAuth@
@@ -152,8 +157,8 @@ LIB_getsockopt = @LIB_getsockopt@
 LIB_logout = @LIB_logout@
 LIB_logwtmp = @LIB_logwtmp@
 LIB_odm_initialize = @LIB_odm_initialize@
+LIB_openpty = @LIB_openpty@
 LIB_pidfile = @LIB_pidfile@
-LIB_readline = @LIB_readline@
 LIB_res_search = @LIB_res_search@
 LIB_setpcred = @LIB_setpcred@
 LIB_setsockopt = @LIB_setsockopt@
@@ -175,18 +180,20 @@ INCLUDE_openldap = @INCLUDE_openldap@
 LIB_openldap = @LIB_openldap@
 
 INCLUDE_readline = @INCLUDE_readline@
+LIB_readline = @LIB_readline@
 
 LEXLIB = @LEXLIB@
 
 NROFF_MAN = groff -mandoc -Tascii
 
-@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
+@KRB4_TRUE@LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
 
-@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \
+@KRB5_TRUE@LIB_krb5 = $(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
 
-@DCE_TRUE@LIB_kdfs = @DCE_TRUE@$(top_builddir)/lib/kdfs/libkdfs.la
+@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
+
+@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
 
 CHECK_LOCAL = $(PROGRAMS)
 
@@ -194,111 +201,73 @@ info_TEXINFOS = heimdal.texi
 heimdal_TEXINFOS = intro.texi install.texi setup.texi kerberos4.texi
 subdir = doc
 mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
-CONFIG_HEADER = ../include/config.h
-CONFIG_CLEAN_FILES = 
+CONFIG_HEADER = $(top_builddir)/include/config.h
+CONFIG_CLEAN_FILES =
+depcomp =
 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)
+COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
+	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
+LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) \
+	$(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
 CCLD = $(CC)
-LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
-DIST_SOURCES = 
-TEXI2DVI = texi2dvi
+LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
+	$(AM_LDFLAGS) $(LDFLAGS) -o $@
+DIST_SOURCES =
 INFO_DEPS = heimdal.info
 DVIS = heimdal.dvi
 TEXINFOS = heimdal.texi
-depcomp = 
-DIST_COMMON =  $(heimdal_TEXINFOS) Makefile.am Makefile.in mdate-sh
+DIST_COMMON = $(heimdal_TEXINFOS) Makefile.am Makefile.in mdate-sh
+all: all-am
 
-
-DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-
-GZIP_ENV = --best
-all: all-redirect
 .SUFFIXES:
-.SUFFIXES: .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x .dvi .info .ps .texi .texinfo .txi
-$(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 doc/Makefile
+.SUFFIXES: .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x .c .dvi .info .ps .texi
+
+mostlyclean-libtool:
+	-rm -f *.lo
 
-Makefile: $(srcdir)/Makefile.in  $(top_builddir)/config.status
-	cd $(top_builddir) \
-	  && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
+clean-libtool:
+	-rm -rf .libs _libs
 
+distclean-libtool:
+	-rm -f libtool
+$(srcdir)/Makefile.in:  Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(top_srcdir)/configure.in $(ACLOCAL_M4)
+	cd $(top_srcdir) && \
+	  $(AUTOMAKE) --foreign  doc/Makefile
+Makefile:  $(srcdir)/Makefile.in  $(top_builddir)/config.status
+	cd $(top_builddir) && \
+	  CONFIG_HEADERS= CONFIG_LINKS= \
+	  CONFIG_FILES=$(subdir)/$@ $(SHELL) ./config.status
 
 heimdal.info: heimdal.texi $(heimdal_TEXINFOS)
 heimdal.dvi: heimdal.texi $(heimdal_TEXINFOS)
 
-
-DVIPS = dvips
-
 .texi.info:
 	@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9]
 	cd $(srcdir) \
-	  && $(MAKEINFO) `echo $< | sed 's,.*/,,'`
+	  && $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) \
+	       `echo $< | sed 's,.*/,,'`
 
 .texi.dvi:
 	TEXINPUTS=$(srcdir):$$TEXINPUTS \
-	  MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<
+	MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir)' \
+	$(TEXI2DVI) $<
 
 .texi:
 	@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9]
 	cd $(srcdir) \
-	  && $(MAKEINFO) `echo $< | sed 's,.*/,,'`
-
-.texinfo.info:
-	@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9]
-	cd $(srcdir) \
-	  && $(MAKEINFO) `echo $< | sed 's,.*/,,'`
+	  && $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) \
+	       `echo $< | sed 's,.*/,,'`
 
-.texinfo:
-	@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9]
-	cd $(srcdir) \
-	  && $(MAKEINFO) `echo $< | sed 's,.*/,,'`
-
-.texinfo.dvi:
-	TEXINPUTS=$(srcdir):$$TEXINPUTS \
-	  MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<
-
-.txi.info:
-	@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9]
-	cd $(srcdir) \
-	  && $(MAKEINFO) `echo $< | sed 's,.*/,,'`
-
-.txi.dvi:
-	TEXINPUTS=$(srcdir):$$TEXINPUTS \
-	  MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<
-
-.txi:
-	@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9]
-	cd $(srcdir) \
-	  && $(MAKEINFO) `echo $< | sed 's,.*/,,'`
+MAKEINFO = @MAKEINFO@
+TEXI2DVI = texi2dvi
+DVIPS = dvips
 .dvi.ps:
 	$(DVIPS) $< -o $@
 
-install-info-am: $(INFO_DEPS)
-	@$(NORMAL_INSTALL)
-	$(mkinstalldirs) $(DESTDIR)$(infodir)
-	@list='$(INFO_DEPS)'; \
-	for file in $$list; do \
-	  d=$(srcdir); \
-	  for ifile in `CDPATH=: && cd $$d && echo $$file $$file-[0-9] $$file-[0-9][0-9]`; do \
-	    if test -f $$d/$$ifile; then \
-	      echo " $(INSTALL_DATA) $$d/$$ifile $(DESTDIR)$(infodir)/$$ifile"; \
-	      $(INSTALL_DATA) $$d/$$ifile $(DESTDIR)$(infodir)/$$ifile; \
-	    else : ; fi; \
-	  done; \
-	done
-	@$(POST_INSTALL)
-	@if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
-	  list='$(INFO_DEPS)'; \
-	  for file in $$list; do \
-	    echo " install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file";\
-	    install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file || :;\
-	  done; \
-	else : ; fi
-
-uninstall-info:
+uninstall-info-am:
 	$(PRE_UNINSTALL)
-	@if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
+	@if (install-info --version && \
+	     install-info --version | fgrep -i -v debian) >/dev/null 2>&1; then \
 	  list='$(INFO_DEPS)'; \
 	  for file in $$list; do \
 	    echo " install-info --info-dir=$(DESTDIR)$(infodir) --remove $(DESTDIR)$(infodir)/$$file"; \
@@ -325,18 +294,13 @@ dist-info: $(INFO_DEPS)
 	done
 
 mostlyclean-aminfo:
-	-rm -f heimdal.aux heimdal.cp heimdal.cps heimdal.dvi heimdal.fn \
-	  heimdal.fns heimdal.pgs heimdal.ky heimdal.kys heimdal.ps \
-	  heimdal.log heimdal.pg heimdal.toc heimdal.tp heimdal.tps \
-	  heimdal.vr heimdal.vrs heimdal.op heimdal.tr heimdal.cv \
-	  heimdal.cn heimdal.cm heimdal.ov
-
-clean-aminfo:
-
-distclean-aminfo:
+	-rm -f heimdal.aux heimdal.cp heimdal.cps heimdal.dvi heimdal.fn heimdal.ky \
+	  heimdal.log heimdal.pg heimdal.ps heimdal.toc heimdal.tp \
+	  heimdal.vr
 
 maintainer-clean-aminfo:
-	cd $(srcdir) && for i in $(INFO_DEPS); do \
+	cd $(srcdir) && \
+	for i in $(INFO_DEPS); do \
 	  rm -f $$i; \
 	  if test "`echo $$i-[0-9]*`" != "$$i-[0-9]*"; then \
 	    rm -f $$i-[0-9]*; \
@@ -346,11 +310,18 @@ tags: TAGS
 TAGS:
 
 
-distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
+DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
+
+top_distdir = ..
+distdir = $(top_distdir)/$(PACKAGE)-$(VERSION)
 
 distdir: $(DISTFILES)
 	@for file in $(DISTFILES); do \
-	  d=$(srcdir); \
+	  if test -f $$file; then d=.; else d=$(srcdir); fi; \
+	  dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
+	  if test "$$dir" != "$$file" && test "$$dir" != "."; then \
+	    $(mkinstalldirs) "$(distdir)/$$dir"; \
+	  fi; \
 	  if test -d $$d/$$file; then \
 	    cp -pR $$d/$$file $(distdir) \
 	    || exit 1; \
@@ -360,76 +331,112 @@ distdir: $(DISTFILES)
 	    || exit 1; \
 	  fi; \
 	done
-	$(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-info
-	$(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-hook
-info-am: $(INFO_DEPS)
-info: info-am
-dvi-am: $(DVIS)
-dvi: dvi-am
+	$(MAKE) $(AM_MAKEFLAGS) \
+	  top_distdir="${top_distdir}" distdir="$(distdir)" \
+	  dist-info dist-hook
 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
+all-am: Makefile $(INFO_DEPS) all-local
 
-install-data-am: install-info-am install-data-local
-install-data: install-data-am
+installdirs:
+	$(mkinstalldirs) $(DESTDIR)$(infodir)
 
-install-am: all-am
-	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
 install: install-am
-uninstall-am: uninstall-info
+install-exec: install-exec-am
+install-data: install-data-am
 uninstall: uninstall-am
-all-am: Makefile $(INFO_DEPS) all-local
-all-redirect: all-am
-install-strip:
-	$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
-installdirs:
-	$(mkinstalldirs)  $(DESTDIR)$(infodir)
 
+install-am: all-am
+	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
 
+installcheck: installcheck-am
+install-strip:
+	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
+	  `test -z '$(STRIP)' || \
+	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
 mostlyclean-generic:
 
 clean-generic:
 
 distclean-generic:
-	-rm -f Makefile $(CONFIG_CLEAN_FILES)
-	-rm -f config.cache config.log stamp-h stamp-h[0-9]*
+	-rm -f Makefile $(CONFIG_CLEAN_FILES) stamp-h stamp-h[0-9]*
 
 maintainer-clean-generic:
-	-rm -f Makefile.in
-mostlyclean-am:  mostlyclean-aminfo mostlyclean-generic
+	@echo "This command is intended for maintainers to use"
+	@echo "it deletes files that may require special tools to rebuild."
+clean: clean-am
 
-mostlyclean: mostlyclean-am
+clean-am: clean-generic clean-libtool mostlyclean-am
 
-clean-am:  clean-aminfo clean-generic mostlyclean-am
+distclean: distclean-am
 
-clean: clean-am
+distclean-am: clean-am distclean-generic distclean-libtool
 
-distclean-am:  distclean-aminfo distclean-generic clean-am
-	-rm -f libtool
+dvi: dvi-am
 
-distclean: distclean-am
+dvi-am: $(DVIS)
 
-maintainer-clean-am:  maintainer-clean-aminfo 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."
+info: info-am
+
+info-am: $(INFO_DEPS)
+
+install-data-am: install-data-local install-info-am
+
+install-exec-am:
+	@$(NORMAL_INSTALL)
+	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
+
+install-info: install-info-am
+
+install-info-am: $(INFO_DEPS)
+	@$(NORMAL_INSTALL)
+	$(mkinstalldirs) $(DESTDIR)$(infodir)
+	@list='$(INFO_DEPS)'; \
+	for file in $$list; do \
+	  d=$(srcdir); \
+	  for ifile in `CDPATH=: && cd $$d && echo $$file $$file-[0-9] $$file-[0-9][0-9]`; do \
+	    if test -f $$d/$$ifile; then \
+	      echo " $(INSTALL_DATA) $$d/$$ifile $(DESTDIR)$(infodir)/$$ifile"; \
+	      $(INSTALL_DATA) $$d/$$ifile $(DESTDIR)$(infodir)/$$ifile; \
+	    else : ; fi; \
+	  done; \
+	done
+	@$(POST_INSTALL)
+	@if (install-info --version && \
+	     install-info --version | fgrep -i -v debian) >/dev/null 2>&1; then \
+	  list='$(INFO_DEPS)'; \
+	  for file in $$list; do \
+	    echo " install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file";\
+	    install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file || :;\
+	  done; \
+	else : ; fi
+install-man:
+
+installcheck-am:
 
 maintainer-clean: maintainer-clean-am
 
-.PHONY: install-info-am uninstall-info mostlyclean-aminfo \
-distclean-aminfo clean-aminfo maintainer-clean-aminfo 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
+maintainer-clean-am: distclean-am maintainer-clean-aminfo \
+	maintainer-clean-generic
+
+mostlyclean: mostlyclean-am
+
+mostlyclean-am: mostlyclean-aminfo mostlyclean-generic \
+	mostlyclean-libtool
+
+uninstall-am: uninstall-info-am
+
+.PHONY: all all-am all-local check check-am check-local clean \
+	clean-generic clean-libtool dist-info distclean \
+	distclean-generic distclean-libtool distdir dvi dvi-am info \
+	info-am install install-am install-data install-data-am \
+	install-data-local install-exec install-exec-am install-info \
+	install-info-am install-man install-strip installcheck \
+	installcheck-am installdirs maintainer-clean \
+	maintainer-clean-aminfo maintainer-clean-generic mostlyclean \
+	mostlyclean-aminfo mostlyclean-generic mostlyclean-libtool \
+	uninstall uninstall-am uninstall-info-am
 
 
 install-suid-programs:
@@ -559,7 +566,6 @@ check-local::
 	  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/doc/install.texi b/crypto/heimdal/doc/install.texi
index aa56cea..61c5282 100644
--- a/crypto/heimdal/doc/install.texi
+++ b/crypto/heimdal/doc/install.texi
@@ -1,4 +1,4 @@
-@c $Id: install.texi,v 1.16 2001/01/28 22:11:22 assar Exp $
+@c $Id: install.texi,v 1.17 2001/07/02 18:06:02 joda Exp $
 
 @node Building and Installing, Setting up a realm, What is Kerberos?, Top
 @comment  node-name,  next,  previous,  up
@@ -54,14 +54,6 @@ path to each with the @kbd{--with-krb4-lib=@file{dir}}, and
 You will need a fairly recent version of our Kerberos 4 distribution for
 @code{rshd} and @code{popper} to support version 4 clients.
 
-@item @kbd{--enable-kaserver}
-Enables experimental kaserver support in the KDC. This is the protocol
-used by the ``KDC'' in AFS. Requires Kerberos 4 support.
-
-@item @kbd{--enable-kaserver-db}
-Enables experimental support for reading kaserver databases in hprop.
-This is useful when migrating from a kaserver to a Heimdal KDC.
-
 @item @kbd{--enable-dce}
 Enables support for getting DCE credentials and tokens.  See the README
 files in @file{appl/dceutils} for more information.
diff --git a/crypto/heimdal/doc/kerberos4.texi b/crypto/heimdal/doc/kerberos4.texi
index 613e352..42a5f89 100644
--- a/crypto/heimdal/doc/kerberos4.texi
+++ b/crypto/heimdal/doc/kerberos4.texi
@@ -1,4 +1,4 @@
-@c $Id: kerberos4.texi,v 1.13 2001/02/24 05:09:24 assar Exp $
+@c $Id: kerberos4.texi,v 1.16 2001/07/19 17:17:46 assar Exp $
 
 @node Kerberos 4 issues, Windows 2000 compatability, Things in search for a better place, Top
 @comment  node-name,  next,  previous,  up
@@ -7,8 +7,8 @@
 If compiled with version 4 support, the KDC can serve requests from a
 Kerberos 4 client. There are a few things you must do for this to work.
 
-You might also want use the built in kaserver emulation in the kdc
-when you have AFS-clients that use @code{klog}.
+The KDC will also have kaserver emulation and be able to handle
+AFS-clients that use @code{klog}.
 
 @menu
 * Principal conversion issues::  
@@ -164,14 +164,14 @@ command to propagate the database to the machine called
 @samp{slave-server} (which should be running a @samp{hpropd}).
 
 @example
-hprop --source=krb4-db -E slave-server
+hprop --source=krb4-db --master-key=/.m slave-server
 @end example
 
 This command can also be to use for converting the v4 database on the
 server:
 
 @example
-hprop -n --source=krb4-db -d /var/kerberos/principal -E | hpropd -n
+hprop -n --source=krb4-db -d /var/kerberos/principal --master-key=/.m | hpropd -n
 @end example
 
 @section Version 4 Kadmin
@@ -202,7 +202,7 @@ contains a minimalistic Rx implementation.
 There are three parts of the kaserver; KAA (Authentication), KAT (Ticket
 Granting), and KAM (Maintenance). The KAA interface and KAT interface
 both passes over DES encrypted data-blobs (just like the
-Kerberos-protocol) and thus o not need any other protection.  The KAM
+Kerberos-protocol) and thus do not need any other protection.  The KAM
 interface uses @code{rxkad} (Kerberos authentication layer for Rx) for
 security and data protection, and is used for example for changing
 passwords.  This part is not implemented in the kdc.
diff --git a/crypto/heimdal/doc/setup.texi b/crypto/heimdal/doc/setup.texi
index 8a1a31b..9cd96e8 100644
--- a/crypto/heimdal/doc/setup.texi
+++ b/crypto/heimdal/doc/setup.texi
@@ -1,4 +1,4 @@
-@c $Id: setup.texi,v 1.22 2001/02/11 17:10:34 assar Exp $
+@c $Id: setup.texi,v 1.25 2001/08/24 05:24:33 assar Exp $
 
 @node Setting up a realm, Things in search for a better place, Building and Installing, Top
 
@@ -209,6 +209,10 @@ following syntax:
 principal       [priv1,priv2,...]       [glob-pattern]
 @end smallexample
 
+The matching is from top to bottom for matching principal (and if given,
+glob-pattern).  When there is a match, the rights of that lines are
+used.
+
 The privileges you can assign to a principal are: @samp{add},
 @samp{change-password} (or @samp{cpw} for short), @samp{delete},
 @samp{get}, @samp{list}, and @samp{modify}, or the special privilege
@@ -273,7 +277,7 @@ low quality, it should return a string explaining why that password
 should not be used.
 
 Code for a password quality checking function that uses the cracklib
-library can be found in @file{kpasswd/sample_password_check.c} in the
+library can be found in @file{lib/kadm5/sample_password_check.c} in the
 source code distribution.  It requires the cracklib library built with
 the patch available at
 @url{ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch}.
@@ -399,13 +403,23 @@ slave#  /usr/heimdal/libexec/ipropd-slave master &
 
 Salting is used to make it harder to precalculate all possible
 keys. Using a salt increases the search space to make it almost
-impossible to precalculate all keys. In salting you just append the salt
-to the password, or somehow merge the password with the salt.
+impossible to precalculate all keys. Salting is the process of mixing a
+public string (the salt) with the password, then sending it through an
+encryption-type specific string-to-key function that will output the
+fixed size encryption key.
+
+In Kerberos 5 the salt is determined by the encryption-type, except
+in some special cases.
+
+In @code{des} there is the Kerberos 4 salt
+(none at all) or the afs-salt (using the cell (realm in
+afs-lingo)).
+
+In @code{arcfour} (the encryption type that Microsoft Windows 2000 uses)
+there is no salt. This is to be compatible with NTLM keys in Windows
+NT 4.
 
-In Kerberos 5 the salting is determined by the encryption-type, except
-in case of @code{des}. In @code{des} there is the kerberos 4 salting
-(none at all) or the afs-salting (using the cell (realm in
-afs-lingo)). @code{[kadmin]default_keys} in @file{krb5.conf} controls
+@code{[kadmin]default_keys} in @file{krb5.conf} controls
 what salting to use,
 
 The syntax of @code{[kadmin]default_keys} is
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
index 85d7456..1fc9927 100644
--- 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
@@ -1,5 +1,589 @@
-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.
+
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-02.txt              Microsoft 
+Category: Informational                                   November 2000 
+
+
+           The Windows 2000 RC4-HMAC Kerberos encryption type 
+
+
+tatus 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. 
+    
+. 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. 
+    
+    
+. Conventions used in this document 
+    
+
+ 
+wift                  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]. 
+    
+. 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 
+    
+. 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 
+ 
+wift                  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. 
+    
+. 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) 
+    
+    
+. 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. 
+ 
+wift                  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. 
+    
+ 
+wift                  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. 
+    
+. 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. 
+
+. GSSAPI Kerberos V5 Mechanism Type  
+
+.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 
+    
+
+ 
+wift                  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. 
+    
+.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); 
+ 
+wift                  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); 
+        } 
+    
+.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 
+ 
+wift                  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. 
+    
+. 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. 
+    
+0. Acknowledgements 
+    
+   We would like to thank Salil Dangi for the valuable input in 
+   refining the descriptions of the functions and review input. 
+     
+1. 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 
+
+
+ 
+wift                  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 
+
+    
+2. 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 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+wift                  Category - Informational                      9 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+
+
+    
+3. 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+wift                  Category - Informational                     10 
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
new file mode 100644
index 0000000..a6dec9d
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                             Ken Hornstein
+<draft-ietf-krb-wg-krb-dns-locate-02.txt>                            NRL
+February 28, 2001                                         Jeffrey Altman
+Expires: August 28, 2001                             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-
+   krb-wg-krb-dns-locate-02.txt>, and expires on August 28, 2001.
+   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                                              February 28, 2001
+
+
+   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 only one of the possible combinations of upper
+   and lower case characters be used.  This restriction may be lifted in
+   the future as the DNS naming scheme is expanded to support non-ASCII
+   names.
+
+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, and Target have the standard mean-
+   ing as defined in RFC 2052.
+
+   As per RFC 2052 the Port number should be the value assigned to "ker-
+   beros" by the Internet Assigned Number Authority (88).
+
+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.
+   Weights are not used in these records.
+
+
+
+
+Hornstein, Altman                                               [Page 2]
+
+RFC DRAFT                                              February 28, 2001
+
+
+   _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, and Target have the standard mean-
+   ing as defined in RFC 2052.
+
+   As per RFC 2052 the Port number should be the value assigned to
+   "kpasswd" by the Internet Assigned Number Authority (464).
+
+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, and Target have the standard mean-
+   ing as defined in RFC 2052.
+
+   As per RFC 2052 the Port number should be the value assigned to
+   "kerberos-adm" by the Internet Assigned Number Authority (749).
+
+   Note that there is no formal definition of a Kerberos admin protocol,
+   so the use of this record is optional and implementation-dependent.
+
+
+
+
+
+Hornstein, Altman                                               [Page 3]
+
+RFC DRAFT                                              February 28, 2001
+
+
+Example - Kerberos administrative server location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has one
+   administrative server, kdc1.asdf.com.
+
+   _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 749 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:
+
+
+
+Hornstein, Altman                                               [Page 4]
+
+RFC DRAFT                                              February 28, 2001
+
+
+   _kerberos.foo.asdf.com. IN TXT
+
+   Finding no match, it would then query:
+
+   _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
+
+
+
+Hornstein, Altman                                               [Page 5]
+
+RFC DRAFT                                              February 28, 2001
+
+
+   be interpretted as permission to use DNS.
+
+Expiration
+
+   This Internet-Draft expires on August 28, 2001.
+
+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/win2k.texi b/crypto/heimdal/doc/win2k.texi
index 1d48677..2db4da1 100644
--- a/crypto/heimdal/doc/win2k.texi
+++ b/crypto/heimdal/doc/win2k.texi
@@ -1,4 +1,4 @@
-@c $Id: win2k.texi,v 1.13 2001/02/24 05:09:24 assar Exp $
+@c $Id: win2k.texi,v 1.15 2001/07/19 16:44:41 assar Exp $
 
 @node Windows 2000 compatability, Programming with Kerberos, Kerberos 4 issues, Top
 @comment  node-name,  next,  previous,  up
@@ -130,7 +130,7 @@ similar to the following if you have it, at least while adding the
 principals that are going to share keys with Windows 2000.
 
 @example
-	[kadmin]default_keys = des3:pw-salt des:pw-salt des:pw-salt:
+	[kadmin]default_keys = v5 v4
 @end example
 
 You must also set:
@@ -240,6 +240,10 @@ unsupported types are generated.
 @comment  node-name,  next,  previous,  up
 @section Useful links when reading about the Windows 2000
 
+See also our paper presented at the 2001 usenix Annual Technical
+Conference, available in the proceedings or at
+@url{http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/westerlund.html}.
+
 There are lots of text about Kerberos on Microsoft's web site, here is a
 short list of the interesting documents that we have managed to find.