From 69a91bec14ec3ad49d1c8a82c40a796755f9e4a3 Mon Sep 17 00:00:00 2001 From: nectar Date: Tue, 19 Feb 2002 15:46:56 +0000 Subject: Import of Heimdal Kerberos from KTH repository circa 2002/02/17. --- crypto/heimdal/doc/Makefile.in | 338 ++++++------ crypto/heimdal/doc/install.texi | 10 +- crypto/heimdal/doc/kerberos4.texi | 12 +- crypto/heimdal/doc/setup.texi | 30 +- .../draft-brezak-win2k-krb-rc4-hmac-02.txt | 592 ++++++++++++++++++++- .../draft-ietf-krb-wg-krb-dns-locate-02.txt | 339 ++++++++++++ crypto/heimdal/doc/win2k.texi | 8 +- 7 files changed, 1134 insertions(+), 195 deletions(-) create mode 100644 crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt (limited to 'crypto/heimdal/doc') 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 + 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 , 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. -- cgit v1.1