diff options
| author | assar <assar@FreeBSD.org> | 2001-02-13 16:46:19 +0000 |
|---|---|---|
| committer | assar <assar@FreeBSD.org> | 2001-02-13 16:46:19 +0000 |
| commit | ebfe6dc471c206300fd82c7c0fd145f683aa52f6 (patch) | |
| tree | e66aa570ad1d12c43b32a7313b0f8e28971bf8a9 /crypto/heimdal/doc | |
| parent | e5f617598c2db0dd51906a38ecea9208123a8b70 (diff) | |
| download | FreeBSD-src-ebfe6dc471c206300fd82c7c0fd145f683aa52f6.zip FreeBSD-src-ebfe6dc471c206300fd82c7c0fd145f683aa52f6.tar.gz | |
import of heimdal 0.3e
Diffstat (limited to 'crypto/heimdal/doc')
36 files changed, 26788 insertions, 200 deletions
diff --git a/crypto/heimdal/doc/Makefile.in b/crypto/heimdal/doc/Makefile.in index 710abb8..2638ef1 100644 --- a/crypto/heimdal/doc/Makefile.in +++ b/crypto/heimdal/doc/Makefile.in @@ -1,6 +1,6 @@ -# Makefile.in generated automatically by automake 1.4 from Makefile.am +# Makefile.in generated automatically by automake 1.4a from Makefile.am -# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc. +# Copyright (C) 1994, 1995-9, 2000 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. @@ -10,15 +10,6 @@ # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. -# $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.13 1999/11/01 03:19:58 assar Exp $ - - SHELL = @SHELL@ srcdir = @srcdir@ @@ -40,8 +31,6 @@ mandir = @mandir@ includedir = @includedir@ oldincludedir = /usr/include -DESTDIR = - pkgdatadir = $(datadir)/@PACKAGE@ pkglibdir = $(libdir)/@PACKAGE@ pkgincludedir = $(includedir)/@PACKAGE@ @@ -54,9 +43,10 @@ AUTOMAKE = @AUTOMAKE@ AUTOHEADER = @AUTOHEADER@ INSTALL = @INSTALL@ -INSTALL_PROGRAM = @INSTALL_PROGRAM@ $(AM_INSTALL_PROGRAM_FLAGS) +INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ +INSTALL_STRIP_FLAG = transform = @program_transform_name@ NORMAL_INSTALL = : @@ -65,26 +55,39 @@ POST_INSTALL = : NORMAL_UNINSTALL = : PRE_UNINSTALL = : POST_UNINSTALL = : + +@SET_MAKE@ host_alias = @host_alias@ host_triplet = @host@ -AFS_EXTRA_LD = @AFS_EXTRA_LD@ AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@ +AMDEP = @AMDEP@ +AMTAR = @AMTAR@ +AS = @AS@ AWK = @AWK@ CANONICAL_HOST = @CANONICAL_HOST@ CATMAN = @CATMAN@ CATMANEXT = @CATMANEXT@ CC = @CC@ +CPP = @CPP@ +CXX = @CXX@ +CXXCPP = @CXXCPP@ DBLIB = @DBLIB@ +DEPDIR = @DEPDIR@ +DIR_des = @DIR_des@ +DIR_roken = @DIR_roken@ +DLLTOOL = @DLLTOOL@ EXEEXT = @EXEEXT@ EXTRA_LIB45 = @EXTRA_LIB45@ GROFF = @GROFF@ +INCLUDES_roken = @INCLUDES_roken@ INCLUDE_ = @INCLUDE_@ -LD = @LD@ LEX = @LEX@ LIBOBJS = @LIBOBJS@ LIBTOOL = @LIBTOOL@ LIB_ = @LIB_@ LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@ +LIB_des = @LIB_des@ +LIB_des_appl = @LIB_des_appl@ LIB_kdb = @LIB_kdb@ LIB_otp = @LIB_otp@ LIB_roken = @LIB_roken@ @@ -92,31 +95,43 @@ LIB_security = @LIB_security@ LN_S = @LN_S@ LTLIBOBJS = @LTLIBOBJS@ MAKEINFO = @MAKEINFO@ -MAKE_X_PROGS_BIN_PROGS = @MAKE_X_PROGS_BIN_PROGS@ -MAKE_X_PROGS_BIN_SCRPTS = @MAKE_X_PROGS_BIN_SCRPTS@ -MAKE_X_PROGS_LIBEXEC_PROGS = @MAKE_X_PROGS_LIBEXEC_PROGS@ NEED_WRITEAUTH_FALSE = @NEED_WRITEAUTH_FALSE@ NEED_WRITEAUTH_TRUE = @NEED_WRITEAUTH_TRUE@ -NM = @NM@ NROFF = @NROFF@ +OBJDUMP = @OBJDUMP@ OBJEXT = @OBJEXT@ PACKAGE = @PACKAGE@ RANLIB = @RANLIB@ +STRIP = @STRIP@ VERSION = @VERSION@ VOID_RETSIGTYPE = @VOID_RETSIGTYPE@ WFLAGS = @WFLAGS@ WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@ WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@ YACC = @YACC@ +dpagaix_CFLAGS = @dpagaix_CFLAGS@ +dpagaix_LDADD = @dpagaix_LDADD@ +install_sh = @install_sh@ + +# $Id: Makefile.am,v 1.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.23 2000/12/05 09:11:09 joda Exp $ + AUTOMAKE_OPTIONS = foreign no-dependencies no-texinfo.tex SUFFIXES = .et .h .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .x -INCLUDES = -I$(top_builddir)/include +INCLUDES = -I$(top_builddir)/include $(INCLUDES_roken) AM_CFLAGS = $(WFLAGS) +CP = cp + COMPILE_ET = $(top_builddir)/lib/com_err/compile_et buildinclude = $(top_builddir)/include @@ -136,6 +151,7 @@ LIB_getsockopt = @LIB_getsockopt@ LIB_logout = @LIB_logout@ LIB_logwtmp = @LIB_logwtmp@ LIB_odm_initialize = @LIB_odm_initialize@ +LIB_pidfile = @LIB_pidfile@ LIB_readline = @LIB_readline@ LIB_res_search = @LIB_res_search@ LIB_setpcred = @LIB_setpcred@ @@ -144,6 +160,8 @@ LIB_socket = @LIB_socket@ LIB_syslog = @LIB_syslog@ LIB_tgetent = @LIB_tgetent@ +LIBS = @LIBS@ + HESIODLIB = @HESIODLIB@ HESIODINCLUDE = @HESIODINCLUDE@ INCLUDE_hesiod = @INCLUDE_hesiod@ @@ -152,29 +170,26 @@ LIB_hesiod = @LIB_hesiod@ INCLUDE_krb4 = @INCLUDE_krb4@ LIB_krb4 = @LIB_krb4@ +INCLUDE_openldap = @INCLUDE_openldap@ +LIB_openldap = @LIB_openldap@ + INCLUDE_readline = @INCLUDE_readline@ LEXLIB = @LEXLIB@ -cat1dir = $(mandir)/cat1 -cat3dir = $(mandir)/cat3 -cat5dir = $(mandir)/cat5 -cat8dir = $(mandir)/cat8 - -MANRX = \(.*\)\.\([0-9]\) -CATSUFFIX = @CATSUFFIX@ - NROFF_MAN = groff -mandoc -Tascii -@KRB4_TRUE@LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS) +@KRB4_TRUE@LIB_kafs = @KRB4_TRUE@$(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS) -@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la $(top_builddir)/lib/asn1/libasn1.la -@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la +@KRB5_TRUE@LIB_krb5 = @KRB5_TRUE@$(top_builddir)/lib/krb5/libkrb5.la \ +@KRB5_TRUE@ $(top_builddir)/lib/asn1/libasn1.la +@KRB5_TRUE@LIB_gssapi = @KRB5_TRUE@$(top_builddir)/lib/gssapi/libgssapi.la CHECK_LOCAL = $(PROGRAMS) 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 = @@ -182,17 +197,18 @@ CFLAGS = @CFLAGS@ COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) CCLD = $(CC) -LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ +LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ +DIST_SOURCES = TEXI2DVI = texi2dvi INFO_DEPS = heimdal.info DVIS = heimdal.dvi TEXINFOS = heimdal.texi +depcomp = DIST_COMMON = $(heimdal_TEXINFOS) Makefile.am Makefile.in mdate-sh -DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST) +DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) -TAR = tar GZIP_ENV = --best all: all-redirect .SUFFIXES: @@ -217,7 +233,7 @@ DVIPS = dvips && $(MAKEINFO) `echo $< | sed 's,.*/,,'` .texi.dvi: - TEXINPUTS=.:$$TEXINPUTS \ + TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $< .texi: @@ -236,7 +252,7 @@ DVIPS = dvips && $(MAKEINFO) `echo $< | sed 's,.*/,,'` .texinfo.dvi: - TEXINPUTS=.:$$TEXINPUTS \ + TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $< .txi.info: @@ -245,7 +261,7 @@ DVIPS = dvips && $(MAKEINFO) `echo $< | sed 's,.*/,,'` .txi.dvi: - TEXINPUTS=.:$$TEXINPUTS \ + TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $< .txi: @@ -261,7 +277,7 @@ install-info-am: $(INFO_DEPS) @list='$(INFO_DEPS)'; \ for file in $$list; do \ d=$(srcdir); \ - for ifile in `cd $$d && echo $$file $$file-[0-9] $$file-[0-9][0-9]`; do \ + 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; \ @@ -280,35 +296,37 @@ install-info-am: $(INFO_DEPS) uninstall-info: $(PRE_UNINSTALL) @if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \ - ii=yes; \ - else ii=; fi; \ - list='$(INFO_DEPS)'; \ - for file in $$list; do \ - test -z "$ii" \ - || install-info --info-dir=$(DESTDIR)$(infodir) --remove $$file; \ - done + list='$(INFO_DEPS)'; \ + for file in $$list; do \ + echo " install-info --info-dir=$(DESTDIR)$(infodir) --remove $(DESTDIR)$(infodir)/$$file"; \ + install-info --info-dir=$(DESTDIR)$(infodir) --remove $(DESTDIR)$(infodir)/$$file; \ + done; \ + else :; fi @$(NORMAL_UNINSTALL) - list='$(INFO_DEPS)'; \ + @list='$(INFO_DEPS)'; \ for file in $$list; do \ - (cd $(DESTDIR)$(infodir) && rm -f $$file $$file-[0-9] $$file-[0-9][0-9]); \ + (if cd $(DESTDIR)$(infodir); then \ + echo " rm -f $$file $$file-[0-9] $$file-[0-9][0-9])"; \ + rm -f $$file $$file-[0-9] $$file-[0-9][0-9]; \ + else :; fi); \ done dist-info: $(INFO_DEPS) list='$(INFO_DEPS)'; \ for base in $$list; do \ d=$(srcdir); \ - for file in `cd $$d && eval echo $$base*`; do \ + for file in `CDPATH=: && cd $$d && eval echo $$base*`; do \ test -f $(distdir)/$$file \ - || ln $$d/$$file $(distdir)/$$file 2> /dev/null \ || cp -p $$d/$$file $(distdir)/$$file; \ done; \ done mostlyclean-aminfo: -rm -f heimdal.aux heimdal.cp heimdal.cps heimdal.dvi heimdal.fn \ - heimdal.fns 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.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: @@ -327,17 +345,16 @@ TAGS: distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir) -subdir = doc - distdir: $(DISTFILES) @for file in $(DISTFILES); do \ d=$(srcdir); \ if test -d $$d/$$file; then \ - cp -pr $$/$$file $(distdir)/$$file; \ + cp -pR $$d/$$file $(distdir) \ + || exit 1; \ else \ test -f $(distdir)/$$file \ - || ln $$d/$$file $(distdir)/$$file 2> /dev/null \ - || cp -p $$d/$$file $(distdir)/$$file || :; \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ fi; \ done $(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-info @@ -367,7 +384,7 @@ uninstall: uninstall-am all-am: Makefile $(INFO_DEPS) all-local all-redirect: all-am install-strip: - $(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install + $(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install installdirs: $(mkinstalldirs) $(DESTDIR)$(infodir) @@ -381,6 +398,7 @@ distclean-generic: -rm -f config.cache config.log stamp-h stamp-h[0-9]* maintainer-clean-generic: + -rm -f Makefile.in mostlyclean-am: mostlyclean-aminfo mostlyclean-generic mostlyclean: mostlyclean-am @@ -406,9 +424,9 @@ 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 installdirs mostlyclean-generic \ -distclean-generic clean-generic maintainer-clean-generic clean \ -mostlyclean distclean maintainer-clean +all-local all-redirect all-am all install-strip installdirs \ +mostlyclean-generic distclean-generic clean-generic \ +maintainer-clean-generic clean mostlyclean distclean maintainer-clean install-suid-programs: @@ -416,7 +434,10 @@ install-suid-programs: for file in $$foo; do \ x=$(DESTDIR)$(bindir)/$$file; \ if chown 0:0 $$x && chmod u+s $$x; then :; else \ - chmod 0 $$x; fi; done + echo "*"; \ + echo "* Failed to install $$x setuid root"; \ + echo "*"; \ + fi; done install-exec-hook: install-suid-programs @@ -428,8 +449,8 @@ install-build-headers:: $(include_HEADERS) $(build_HEADERZ) else file="$$f"; fi; \ if cmp -s $$file $(buildinclude)/$$f 2> /dev/null ; then \ : ; else \ - echo " cp $$file $(buildinclude)/$$f"; \ - cp $$file $(buildinclude)/$$f; \ + echo " $(CP) $$file $(buildinclude)/$$f"; \ + $(CP) $$file $(buildinclude)/$$f; \ fi ; \ done @@ -498,87 +519,8 @@ dist-cat8-mans: dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans -install-cat1-mans: - @ext=1;\ - foo='$(man1_MANS)'; \ - bar='$(man_MANS)'; \ - for i in $$bar; do \ - case $$i in \ - *.1) foo="$$foo $$i";; \ - esac; done; \ - if test "$$foo"; then \ - $(mkinstalldirs) $(DESTDIR)$(cat1dir); \ - for x in $$foo; do \ - f=`echo $$x | sed 's/\.[^.]*$$/.cat1/'`; \ - if test -f "$(srcdir)/$$f"; then \ - b=`echo $$x | sed 's!$(MANRX)!\1!'`; \ - echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat1dir)/$$b.$(CATSUFFIX)";\ - $(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat1dir)/$$b.$(CATSUFFIX);\ - fi; \ - done ;\ - fi - -install-cat3-mans: - @ext=3;\ - foo='$(man3_MANS)'; \ - bar='$(man_MANS)'; \ - for i in $$bar; do \ - case $$i in \ - *.3) foo="$$foo $$i";; \ - esac; done; \ - if test "$$foo"; then \ - $(mkinstalldirs) $(DESTDIR)$(cat3dir); \ - for x in $$foo; do \ - f=`echo $$x | sed 's/\.[^.]*$$/.cat3/'`; \ - if test -f "$(srcdir)/$$f"; then \ - b=`echo $$x | sed 's!$(MANRX)!\1!'`; \ - echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat3dir)/$$b.$(CATSUFFIX)";\ - $(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat3dir)/$$b.$(CATSUFFIX);\ - fi; \ - done ;\ - fi - -install-cat5-mans: - @ext=5;\ - foo='$(man5_MANS)'; \ - bar='$(man_MANS)'; \ - for i in $$bar; do \ - case $$i in \ - *.5) foo="$$foo $$i";; \ - esac; done; \ - if test "$$foo"; then \ - $(mkinstalldirs) $(DESTDIR)$(cat5dir); \ - for x in $$foo; do \ - f=`echo $$x | sed 's/\.[^.]*$$/.cat5/'`; \ - if test -f "$(srcdir)/$$f"; then \ - b=`echo $$x | sed 's!$(MANRX)!\1!'`; \ - echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat5dir)/$$b.$(CATSUFFIX)";\ - $(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat5dir)/$$b.$(CATSUFFIX);\ - fi; \ - done ;\ - fi - -install-cat8-mans: - @ext=8;\ - foo='$(man8_MANS)'; \ - bar='$(man_MANS)'; \ - for i in $$bar; do \ - case $$i in \ - *.8) foo="$$foo $$i";; \ - esac; done; \ - if test "$$foo"; then \ - $(mkinstalldirs) $(DESTDIR)$(cat8dir); \ - for x in $$foo; do \ - f=`echo $$x | sed 's/\.[^.]*$$/.cat8/'`; \ - if test -f "$(srcdir)/$$f"; then \ - b=`echo $$x | sed 's!$(MANRX)!\1!'`; \ - echo "$(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(cat8dir)/$$b.$(CATSUFFIX)";\ - $(INSTALL_DATA) $(srcdir)/$$g $(DESTDIR)$(cat8dir)/$$b.$(CATSUFFIX);\ - fi; \ - done ;\ - fi - -install-cat-mans: install-cat1-mans install-cat3-mans install-cat5-mans install-cat8-mans +install-cat-mans: + $(SHELL) $(top_srcdir)/cf/install-catman.sh "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS) install-data-local: install-cat-mans diff --git a/crypto/heimdal/doc/ack.texi b/crypto/heimdal/doc/ack.texi index 1594194..eedbc53 100644 --- a/crypto/heimdal/doc/ack.texi +++ b/crypto/heimdal/doc/ack.texi @@ -1,3 +1,5 @@ +@c $Id: ack.texi,v 1.13 2001/01/30 01:57:31 assar Exp $ + @node Acknowledgments, , Windows 2000 compatability, Top @comment node-name, next, previous, up @appendix Acknowledgments @@ -26,7 +28,7 @@ Bugfixes, documentation, encouragement, and code has been contributed by: @item Johan Ihrén @email{johani@@pdc.kth.se} @item Love Hörnquist-Åstrand -@email{e96_lho@@e.kth.se} +@email{lha@@stacken.kth.se} @item Magnus Ahltorp @email{map@@stacken.kth.se} @item Mark Eichin @@ -51,6 +53,10 @@ Bugfixes, documentation, encouragement, and code has been contributed by: @email{bmay@@snoopy.apana.org.au} @item Chaskiel M Grundman @email{cg2v@@andrew.cmu.edu} +@item Richard Nyberg +@email{rnyberg@@it.su.se} +@item Frank van der Linden +@email{fvdl@@netbsd.org} @item and we hope that those not mentioned here will forgive us. @end table diff --git a/crypto/heimdal/doc/heimdal.texi b/crypto/heimdal/doc/heimdal.texi index 4cf1b3f..3d9d4cd 100644 --- a/crypto/heimdal/doc/heimdal.texi +++ b/crypto/heimdal/doc/heimdal.texi @@ -1,6 +1,6 @@ \input texinfo @c -*- texinfo -*- @c %**start of header -@c $Id: heimdal.texi,v 1.14 2000/01/02 04:09:00 assar Exp $ +@c $Id: heimdal.texi,v 1.16 2000/07/28 15:43:36 assar Exp $ @setfilename heimdal.info @settitle HEIMDAL @iftex @@ -15,9 +15,9 @@ @c %**end of header @c not yet @include version.texi -@set UPDATED $Date: 2000/01/02 04:09:00 $ -@set EDITION 0.0 -@set VERSION 0.2k +@set UPDATED $Date: 2000/07/28 15:43:36 $ +@set EDITION 0.1 +@set VERSION 0.3a @ifinfo @dircategory Heimdal @@ -227,6 +227,7 @@ to the following restrictions: * Things in search for a better place:: * Kerberos 4 issues:: * Windows 2000 compatability:: +* Migration:: * Acknowledgments:: @end menu @@ -237,6 +238,7 @@ to the following restrictions: @include setup.texi @include misc.texi @include kerberos4.texi +@include migration.texi @include win2k.texi @include ack.texi diff --git a/crypto/heimdal/doc/install.texi b/crypto/heimdal/doc/install.texi index 5d195a6..aa56cea 100644 --- a/crypto/heimdal/doc/install.texi +++ b/crypto/heimdal/doc/install.texi @@ -1,3 +1,5 @@ +@c $Id: install.texi,v 1.16 2001/01/28 22:11:22 assar Exp $ + @node Building and Installing, Setting up a realm, What is Kerberos?, Top @comment node-name, next, previous, up @chapter Building and Installing @@ -60,6 +62,10 @@ used by the ``KDC'' in AFS. Requires Kerberos 4 support. 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. + @item @kbd{--disable-otp} By default some of the application programs will build with support for one-time passwords (OTP). Use this option to disable that support. @@ -83,4 +89,21 @@ Probably only useful (and working) on NextStep/Mac OS X. @item @kbd{--without-ipv6} Disable the IPv6 support. +@item @kbd{--with-openldap} +Compile Heimdal with support for storing the database in LDAP. Requires +OpenLDAP @url{http://www.openldap.org}. See +@url{http://www.padl.com/~lukeh/heimdal/} for more information. + +@item @kbd{--enable-bigendian} +@item @kbd{--enable-littleendian} +Normally, the build process will figure out by itself if the machine is +big or little endian. It might fail in some cases when +cross-compiling. If it does fail to figure it out, use the relevant of +these two options. + +@item @kbd{--with-mips-abi=@var{abi}} +On Irix there are three different ABIs that can be used (@samp{32}, +@samp{n32}, or @samp{64}). This option allows you to override the +automatic selection. + @end table diff --git a/crypto/heimdal/doc/intro.texi b/crypto/heimdal/doc/intro.texi index 518aada..6c6ff3a 100644 --- a/crypto/heimdal/doc/intro.texi +++ b/crypto/heimdal/doc/intro.texi @@ -1,3 +1,5 @@ +@c $Id: intro.texi,v 1.12 2001/01/28 22:11:22 assar Exp $ + @node Introduction, What is Kerberos?, Top, Top @c @node Introduction, What is Kerberos?, Top, Top @comment node-name, next, previous, up diff --git a/crypto/heimdal/doc/kerberos4.texi b/crypto/heimdal/doc/kerberos4.texi index 2e4f92c..92614c8 100644 --- a/crypto/heimdal/doc/kerberos4.texi +++ b/crypto/heimdal/doc/kerberos4.texi @@ -1,13 +1,19 @@ -@node Kerberos 4 issues, Windows 2000 compatability, Things in search for a better place, Top +@c $Id: kerberos4.texi,v 1.12 2001/01/30 17:07:03 assar Exp $ + +@node Kerberos 4 issues, Migration, Things in search for a better place, Top @comment node-name, next, previous, up @chapter Kerberos 4 issues 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}. + @menu * Principal conversion issues:: * Converting a version 4 database:: +* kaserver:: @end menu @node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues @@ -51,7 +57,7 @@ principal exists in the database. The KDC will use @code{krb5_425_conv_principal_ext} to convert principals when handling to version 4 requests. -@node Converting a version 4 database, , Principal conversion issues, Kerberos 4 issues +@node Converting a version 4 database, kaserver , Principal conversion issues, Kerberos 4 issues @section Converting a version 4 database If you want to convert an existing version 4 database, the principal @@ -153,13 +159,19 @@ the @samp{[libdefaults]} section. @subsection Converting a database -The database conversion is done with @samp{hprop}. Assuming that you -have the @samp{kadmin/hprop} key in the keytab @file{hprop.keytab}, you -can run this command to propagate the database to the machine called +The database conversion is done with @samp{hprop}. You can run this +command to propagate the database to the machine called @samp{slave-server} (which should be running a @samp{hpropd}). @example -hprop -4 -E -k hprop.keytab slave-server +hprop --source=krb4-db -E 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 @end example @section Version 4 Kadmin @@ -177,3 +189,38 @@ version 4 uses port 751, not 749). @emph{And then there are a many more things you can do; more on this in a later version of this manual. Until then, UTSL.} + +@node kaserver, , Converting a version 4 database, Kerberos 4 issues +@section kaserver + +@subsection kaserver emulation + +The Heimdal kdc can emulate a kaserver. The kaserver is a Kerberos 4 +server with pre-authentication using Rx as the on-wire protocol. The kdc +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 +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. + +Another difference between the ka-protocol and the Kerberos 4 protocol +is that the pass-phrase is salted with the cellname in the @code{string to +key} function in the ka-protocol, while in the Kerberos 4 protocol there +is no salting of the password at all. To make sure AFS-compatible keys +are added to each principals when they are created or their password are +changed, @samp{afs3-salt} should be added to +@samp{[kadmin]default_keys}. + +@subsection Transarc AFS Windows client + +The Transarc Windows client uses Kerberos 4 to obtain tokens, and thus +does not need a kaserver. The Windows client assumes that the Kerberos +server is on the same machine as the AFS-database server. If you do not +like to do that you can add a small program that runs on the database +servers that forward all kerberos requests to the real kerberos +server. A program that does this is @code{krb-forward} +(@url{ftp://ftp.stacken.kth.se/pub/projekts/krb-forward}). diff --git a/crypto/heimdal/doc/migration.texi b/crypto/heimdal/doc/migration.texi new file mode 100644 index 0000000..90deed7 --- /dev/null +++ b/crypto/heimdal/doc/migration.texi @@ -0,0 +1,43 @@ +@c $Id: migration.texi,v 1.2 2001/01/28 22:03:36 assar Exp $ + +@node Migration, Windows 2000 compatability, Kerberos 4 issues, Top +@chapter Migration + +@section General issues + +When migrating from a Kerberos 4 KDC. + +@section Order in what to do things: + +@itemize @bullet + +@item Convert the database, check all principals that hprop complains +about. + +@samp{hprop -n --source=<NNN>| hpropd -n} + +Replace <NNN> with whatever source you have, like krb4-db or krb4-dump. + +@item Run a Kerberos 5 slave for a while. + +@c XXX Add you slave first to your kdc list in you kdc. + +@item Figure out if it does everything you want it to. + +Make sure that all things that you use works for you. + +@item Let a small number of controlled users use Kerberos 5 tools. + +Find a sample population of your users and check what programs they use, +you can also check the kdc-log to check what ticket are checked out. + +@item Burn the bridge and change the master. +@item Let all users use the Kerberos 5 tools by default. +@item Turn off services that do not need Kerberos 4 authentication. + +Things that might be hard to get away is old programs with support for +Kerberos 4. Example applications are old Eudora installations using +KPOP, and Zephyr. Eudora can use the Kerberos 4 kerberos in the Heimdal +kdc. + +@end itemize diff --git a/crypto/heimdal/doc/misc.texi b/crypto/heimdal/doc/misc.texi index e926536..994f6f2 100644 --- a/crypto/heimdal/doc/misc.texi +++ b/crypto/heimdal/doc/misc.texi @@ -1,14 +1,16 @@ +@c $Id: misc.texi,v 1.5 2001/01/28 22:11:23 assar Exp $ + @node Things in search for a better place, Kerberos 4 issues, Setting up a realm, Top @chapter Things in search for a better place @section Making things work on Ciscos Modern versions of Cisco IOS has some support for authenticating via -Kerberos 5. This can be used both to verify passwords via a ticket -exchange Kerberos 5 (boring), and to use Kerberos authenticated telnet -to access your router (less boring). The following has been tested on -IOS 11.2(12), things might be different with other versions. Old -versions are known to have bugs. +Kerberos 5. This can be used both by having the router get a ticket when +you login (boring), and by using Kerberos authenticated telnet to access +your router (less boring). The following has been tested on IOS +11.2(12), things might be different with other versions. Old versions +are known to have bugs. To make this work, you will first have to configure your router to use Kerberos (this is explained in the documentation). A sample @@ -24,31 +26,25 @@ kerberos server FOO.SE 10.0.0.1 kerberos instance map admin 15 @end example -This tells you (among other things) that the when logging in, the router -should try to authenticate with kerberized telnet, and if that fails try +This tells you (among other things) that when logging in, the router +should try to authenticate with kerberised telnet, and if that fails try to verify a plain text password via a Kerberos ticket exchange (as -opposed to a local database or RADIUS or something similar), and if that +opposed to a local database, RADIUS or something similar), and if that fails try the local enable password. If you're not careful when you specify the `login default' authentication mechanism, you might not be -able to login. The `instance map' and `authorization exec' lines says -that people with `admin' instances should be given `enabled' shells when -logging in. +able to login at all. The `instance map' and `authorization exec' lines +says that people with `admin' instances should be given `enabled' shells +when logging in. + +The numbers after the principal on the `srvtab' line are principal type, +timestamp (in seconds since 1970), key version number (4), keytype (1 == +des), key length (always 8 with des), and then the key. To make the Heimdal KDC produce tickets that the Cisco can decode you might have to turn on the @samp{encode_as_rep_as_tgs_rep} flag in the KDC. You will also have to specify that the router can't handle anything -but @samp{des-cbc-crc}. There currently isn't an easy way to do -this. The best you can do is to dump your database (with @samp{kadmin -l -dump}), remove all entries for keys other than @samp{des-cbc-crc}, and -then reloading the database (@samp{kadmin -l load}). An example should -clarify this. You should have something like (again, truncated): -@example -host/router.foo.se@@FOO.SE 4:0:1:...:-:... - - - - - - - 126 -@end example -Change this to: -@example -host/router.foo.se@@FOO.SE 4:0:1:...:- - - - - - - - 126 -@end example +but @samp{des-cbc-crc}. This can be done with the @samp{del_enctype} +command of @samp{kadmin}. This all fine and so, but unless you have an IOS version with encryption (available only in the U.S) it doesn't really solve any problems. Sure diff --git a/crypto/heimdal/doc/setup.texi b/crypto/heimdal/doc/setup.texi index a43eb7e..ed14306 100644 --- a/crypto/heimdal/doc/setup.texi +++ b/crypto/heimdal/doc/setup.texi @@ -1,6 +1,21 @@ +@c $Id: setup.texi,v 1.21 2001/01/29 04:39:46 assar Exp $ + @node Setting up a realm, Things in search for a better place, Building and Installing, Top + @chapter Setting up a realm +@menu +* Configuration file:: +* Creating the database:: +* keytabs:: +* Remote administration:: +* Password changing:: +* Testing clients and servers:: +* Slave Servers:: +* Incremental propagation:: +* Salting:: +@end menu + A @cindex realm realm is an administrative domain. The name of a Kerberos realm is @@ -8,6 +23,7 @@ usually the Internet domain name in uppercase. Call your realm the same as your Internet domain name if you do not have strong reasons for not doing so. It will make life easier for you and everyone else. +@node Configuration file, Creating the database, Setting up a realm, Setting up a realm @section Configuration file To setup a realm you will first have to create a configuration file: @@ -77,6 +93,7 @@ If you use a realm name equal to your domain name, you can omit the SRV-record for your realm, or your kerberos server has CNAME called @samp{kerberos.my.realm}, you can omit the @samp{realms} section too. +@node Creating the database, keytabs, Configuration file, Setting up a realm @section Creating the database The database library will look for the database in @file{/var/heimdal}, @@ -148,15 +165,16 @@ krbtgt/MY.REALM@@MY.REALM 1:0:1:52b53b61c875ce16:-:0:7:c8943be ... kadmin/changepw@@MY.REALM 1:0:1:f48c8af2b340e9fb:-:0:7:e3e6088 ... @end smallexample +@node keytabs, Remote administration, Creating the database, Setting up a realm @section keytabs To extract a service ticket from the database and put it in a keytab you need to first create the principal in the database with @samp{ank} -(using the @kbd{--random} flag to get a random password) and then +(using the @kbd{--random-key} flag to get a random key) and then extract it with @samp{ext_keytab}. @example -kadmin> add --random host/my.host.name +kadmin> add --random-key host/my.host.name Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: @@ -169,11 +187,13 @@ Version Type Principal 1 des3-cbc-sha1 host/my.host.name@@MY.REALM @end example +@node Remote administration, Password changing, keytabs, Setting up a realm @section Remote administration -The administration server, @samp{kadmind}, is started by @samp{inetd} -and you should add a line similar to the one below to your -@file{/etc/inetd.conf}. +The administration server, @samp{kadmind}, can be started by +@samp{inetd} (which isn't recommended) or run as a normal daemon. If you +want to start it from @samp{inetd} you should add a line similar to the +one below to your @file{/etc/inetd.conf}. @example kerberos-adm stream tcp nowait root /usr/heimdal/libexec/kadmind kadmind @@ -186,7 +206,7 @@ Access to the admin server is controlled by an acl-file, (default @file{/var/heimdal/kadmind.acl}.) The lines in the access file, has the following syntax: @smallexample -principal [priv1,priv2,...] +principal [priv1,priv2,...] [glob-pattern] @end smallexample The privileges you can assign to a principal are: @samp{add}, @@ -195,6 +215,26 @@ The privileges you can assign to a principal are: @samp{add}, @samp{all}. All of these roughly corresponds to the different commands in @samp{kadmin}. +If a @var{glob-pattern} is given on a line, it restricts the right for +the principal to only apply for the subjects that match the pattern. +The patters are of the same type as those used in shell globbing, see +@url{none,,fnmatch(3)}. + +In the example below @samp{lha/admin} can change every principal in the +database. @samp{jimmy/admin} can only modify principals that belong to +the realm @samp{E.KTH.SE}. @samp{mille/admin} is working at the +helpdesk, so he should only be able to change the passwords for single +component principals (ordinary users). He will not be able to change any +@samp{/admin} principal. + +@example +lha/admin@@E.KTH.SE all +jimmy/admin@@E.KTH.SE all *@@E.KTH.SE +jimmy/admin@@E.KTH.SE all */*@@E.KTH.SE +mille/admin@@E.KTH.SE change-password *@@E.KTH.SE +@end example + +@node Password changing, Testing clients and servers, Remote administration, Setting up a realm @section Password changing To allow users to change their passwords, you should run @samp{kpasswdd}. @@ -241,7 +281,155 @@ the patch available at If no password quality checking function is configured, it is only verified that it is at least six characters of length. +@node Testing clients and servers, Slave Servers, Password changing, Setting up a realm @section Testing clients and servers Now you should be able to run all the clients and servers. Refer to the appropriate man pages for information on how to use them. + +@node Slave Servers, Incremental propagation, Testing clients and servers, Setting up a realm +@section Slave servers, Incremental propagation, Testing clients and servers, Setting up a realm + +It is desirable to have at least one backup (slave) server in case the +master server fails. It is possible to have any number of such slave +servers but more than three usually doesn't buy much more redundancy. + +All Kerberos servers for a realm shall have the same database so that +they present the same service to all the users. The +@pindex hprop +@code{hprop} program, running on the master, will propagate the database +to the slaves, running +@pindex hpropd +@code{hpropd} processes. + +Every slave needs a keytab with a principal, +@samp{hprop/@var{hostname}}. Add that with the +@pindex ktutil +@code{ktutil} command and start +@pindex hpropd +@code{propd}, as follows: + +@example +slave# ktutil get -p foo/admin host/`hostname` +slave# hpropd +@end example + +The master will use the principal @samp{kadmin/hprop} to authenticate to +the slaves. This principal should be added when running @kbd{kadmin -l +init} but if you do not have it in your database for whatever reason, +please add it with @kbd{kadmin -l add}. + +Then run +@pindex hprop +@code{hprop} on the master: + +@example +master# hprop slave +@end example + +This was just an on-hands example to make sure that everything was +working properly. Doing it manually is of course the wrong way and to +automate this you will want to start +@pindex hpropd +@code{hpropd} from @code{inetd} on the slave(s) and regularly run +@pindex hprop +@code{hprop} on the master to regularly propagate the database. +Starting the propagation once an hour from @code{cron} is probably a +good idea. + +@node Incremental propagation, Salting , Slave Servers, Setting up a realm +@section Incremental propagation + +There is also a newer and still somewhat experimental mechanism for +doing incremental propagation in Heimdal. Instead of sending the whole +database regularly, it sends the changes as they happen on the master to +the slaves. The master keeps track of all the changes by assigned a +version number to every change to the database. The slaves know which +was the latest version they saw and in this way it can be determined if +they are in sync or not. A log of all the changes is kept on the master +and when a slave is at an older versioner than the oldest one in the +log, the whole database has to be sent. + +Protocol-wise, all the slaves connects to the master and as a greeting +tell it the latest version that they have (@samp{IHAVE} message). The +master then responds by sending all the changes between that version and +the current version at the master (a series of @samp{FORYOU} messages) +or the whole database in a @samp{TELLYOUEVERYTHING} message. + +@subsection Configuring incremental propagation + +The program that runs on the master is @code{ipropd-master} and all +clients run @code{ipropd-slave}. + +Create the file @file{/var/heimdal/slaves} on the master containing all +the slaves that the database should be propagated to. Each line contains +the full name of the principal (for example +@samp{iprop/hemligare.foo.se@@FOO.SE}). + +You should already have @samp{iprop/tcp} defined as 2121, in your +@file{/etc/services}. Otherwise, or if you need to use a different port +for some peculiar reason, you can use the @kbd{--port} option. This is +useful when you have multiple realms to distribute from one server. + +Then you need to create these principals that you added in the +configuration file. Create one @samp{iprop/hostname} for the master and +for every slave. + + +@example +master# /usr/heimdal/sbin/ktutil get iprop/`hostname` +@end example + +The next step is to start the @code{ipropd-master} process on the master +server. The @code{ipropd-master} listens on the UNIX-socket +@file{/var/heimdal/signal} to know when changes have been made to the +database so they can be propagated to the slaves. There is also a +safety feature of testing the version number regularly (every 30 +seconds) to see if it has been modified by some means that do not raise +this signal. Then, start @code{ipropd-slave} on all the slaves: + +@example +master# /usr/heimdal/libexec/ipropd-master & +slave# /usr/heimdal/libexec/ipropd-slave master & +@end example + +@node Salting, , Incremental propagation, Setting up a realm +@section Salting +@cindex Salting + +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. + +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 +what salting to use, + +The syntax of @code{[kadmin]default_keys} is +@samp{[etype:]salt-type[:salt-string]}. @samp{etype} is the encryption +type (des, des3, arcfour), @code{salt-type} is the type of salt (pw-salt +or afs3-salt), and the salt-string is the string that will be used as +salt (remember that if the salt is appened/prepended, the empty salt "" +is the same thing as no salt at all). + +Common types of salting includes + +@itemize +@item @code{v4} (or @code{des:pw-salt:}) + +The Kerberos 4 salting is using no salt att all. Reson there is colon +that the end is that + +@item @code{v5} (or @code{pw-salt}) + +@code{pw-salt} means all regular encryption-types that is regular + +@item @code{afs3-salt} + +@code{afs3-salt} is the salting that is used with Transarc kaserver. Its +the cell appended to the password. + +@end itemize diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt new file mode 100644 index 0000000..85d7456 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on July 17, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt new file mode 100644 index 0000000..202d44e --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt @@ -0,0 +1,587 @@ +CAT working group M. Swift +Internet Draft J. Brezak +Document: draft-brezak-win2k-krb-rc4-hmac-03.txt Microsoft +Category: Informational June 2000 + + + The Windows 2000 RC4-HMAC Kerberos encryption type + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be + updated, replaced, or obsoleted by other documents at any time. It + is inappropriate to use Internet- Drafts as reference material or to + cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The Windows 2000 implementation of Kerberos introduces a new + encryption type based on the RC4 encryption algorithm and using an + MD5 HMAC for checksum. This is offered as an alternative to using + the existing DES based encryption types. + + The RC4-HMAC encryption types are used to ease upgrade of existing + Windows NT environments, provide strong crypto (128-bit key + lengths), and provide exportable (meet United States government + export restriction requirements) encryption. + + The Windows 2000 implementation of Kerberos contains new encryption + and checksum types for two reasons: for export reasons early in the + development process, 56 bit DES encryption could not be exported, + and because upon upgrade from Windows NT 4.0 to Windows 2000, + accounts will not have the appropriate DES keying material to do the + standard DES encryption. Furthermore, 3DES is not available for + export, and there was a desire to use a single flavor of encryption + in the product for both US and international products. + + As a result, there are two new encryption types and one new checksum + type introduced in Windows 2000. + + +2. Conventions used in this document + + + +Swift Category - Informational 1 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. Key Generation + + On upgrade from existing Windows NT domains, the user accounts would + not have a DES based key available to enable the use of DES base + encryption types specified in RFC 1510. The key used for RC4-HMAC is + the same as the existing Windows NT key (NT Password Hash) for + compatibility reasons. Once the account password is changed, the DES + based keys are created and maintained. Once the DES keys are + available DES based encryption types can be used with Kerberos. + + The RC4-HMAC String to key function is defined as follow: + + String2Key(password) + + K = MD4(UNICODE(password)) + + The RC4-HMAC keys are generated by using the Windows UNICODE version + of the password. Each Windows UNICODE character is encoded in + little-endian format of 2 octets each. Then performing an MD4 [6] + hash operation on just the UNICODE characters of the password (not + including the terminating zero octets). + + For an account with a password of "foo", this String2Key("foo") will + return: + + 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, + 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc + +4. Basic Operations + + The MD5 HMAC function is defined in [3]. It is used in this + encryption type for checksum operations. Refer to [3] for details on + its operation. In this document this function is referred to as + HMAC(Key, Data) returning the checksum using the specified key on + the data. + + The basic MD5 hash operation is used in this encryption type and + defined in [7]. In this document this function is referred to as + MD5(Data) returning the checksum of the data. + + RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A + compatible cipher is described in [8]. In this document the function + is referred to as RC4(Key, Data) returning the encrypted data using + the specified key on the data. + + These encryption types use key derivation as defined in [9] (RFC- + 1510BIS) in Section titled "Key Derivation". With each message, the + message type (T) is used as a component of the keying material. This + summarizes the different key derivation values used in the various + +Swift Category - Informational 2 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + operations. Note that these differ from the key derivations used in + other Kerberos encryption types. + + T = 1 for TS-ENC-TS in the AS-Request + T = 8 for the AS-Reply + T = 7 for the Authenticator in the TGS-Request + T = 8 for the TGS-Reply + T = 2 for the Server Ticket in the AP-Request + T = 11 for the Authenticator in the AP-Request + T = 12 for the Server returned AP-Reply + T = 15 in the generation of checksum for the MIC token + T = 0 in the generation of sequence number for the MIC token + T = 13 in the generation of checksum for the WRAP token + T = 0 in the generation of sequence number for the WRAP token + T = 0 in the generation of encrypted data for the WRAPPED token + + All strings in this document are ASCII unless otherwise specified. + The lengths of ASCII encoded character strings include the trailing + terminator character (0). + + The concat(a,b,c,...) function will return the logical concatenation + (left to right) of the values of the arguments. + + The nonce(n) function returns a pseudo-random number of "n" octets. + +5. Checksum Types + + There is one checksum type used in this encryption type. The + Kerberos constant for this type is: + #define KERB_CHECKSUM_HMAC_MD5 (-138) + + The function is defined as follows: + + K - is the Key + T - the message type, encoded as a little-endian four byte integer + + CHKSUM(K, T, data) + + Ksign = HMAC(K, "signaturekey") //includes zero octet at end + tmp = MD5(concat(T, data)) + CHKSUM = HMAC(Ksign, tmp) + + +6. Encryption Types + + There are two encryption types used in these encryption types. The + Kerberos constants for these types are: + #define KERB_ETYPE_RC4_HMAC 23 + #define KERB_ETYPE_RC4_HMAC_EXP 24 + + The basic encryption function is defined as follow: + + T = the message type, encoded as a little-endian four byte integer. + +Swift Category - Informational 3 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + BYTE L40[14] = "fortybits"; + BYTE SK = "signaturekey"; + + ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 10 + 4, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + add_8_random_bytes(data, data_len, conf_plus_data); + HMAC (K2, conf_plus_data, 8 + data_len, checksum); + HMAC (K1, checksum, 16, K3); + RC4(K3, conf_plus_data, 8 + data_len, edata + 16); + memcpy (edata, checksum, 16); + edata_len = 16 + 8 + data_len; + } + + DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + HMAC (K1, edata, 16, K3); // checksum is at edata + RC4(K3, edata + 16, edata_len - 16, edata + 16); + data_len = edata_len - 16 - 8; + memcpy (data, edata + 16 + 8, data_len); + + // verify generated and received checksums + HMAC (K2, edata + 16, edata_len - 16, checksum); + if (memcmp(edata, checksum, 16) != 0) + printf("CHECKSUM ERROR !!!!!!\n"); + } + + The header field on the encrypted data in KDC messages is: + + typedef struct _RC4_MDx_HEADER { + UCHAR Checksum[16]; + UCHAR Confounder[8]; + } RC4_MDx_HEADER, *PRC4_MDx_HEADER; + + The KDC message is encrypted using the ENCRYPT function not + including the Checksum in the RC4_MDx_HEADER. + + +Swift Category - Informational 4 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +7. Key Strength Negotiation + + A Kerberos client and server can negotiate over key length if they + are using mutual authentication. If the client is unable to perform + full strength encryption, it may propose a key in the "subkey" field + of the authenticator, using a weaker encryption type. The server + must then either return the same key or suggest its own key in the + subkey field of the AP reply message. The key used to encrypt data + is derived from the key returned by the server. If the client is + able to perform strong encryption but the server is not, it may + propose a subkey in the AP reply without first being sent a subkey + in the authenticator. + +8. GSSAPI Kerberos V5 Mechanism Type + +8.1 Mechanism Specific Changes + + The GSSAPI per-message tokens also require new checksum and + encryption types. The GSS-API per-message tokens must be changed to + support these new encryption types (See [5] Section 1.2.2). The + sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption + is: + Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 + + The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: + Byte 2..3 SGN ALG 0x11 0x00 - HMAC + + The only support quality of protection is: + #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 + + In addition, when using an RC4 based encryption type, the sequence + number is sent in big-endian rather than little-endian order. + + The Windows 2000 implementation also defines new GSSAPI flags in the + initial token passed when initializing a security context. These + flags are passed in the checksum field of the authenticator (See [5] + Section 1.1.1). + + GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s + implementation of DCE RPC, which initially expected three legs of + authentication. Setting this flag causes an extra AP reply to be + sent from the client back to the server after receiving the server’s + AP reply. In addition, the context negotiation tokens do not have + GSSAPI framing - they are raw AP message and do not include object + identifiers. + #define GSS_C_DCE_STYLE 0x1000 + + + +Swift Category - Informational 5 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the + server that it should only allow the server application to identify + the client by name and ID, but not to impersonate the client. + #define GSS_C_IDENTIFY_FLAG 0x2000 + + GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the + client wants to be informed of extended error information. In + particular, Windows 2000 status codes may be returned in the data + field of a Kerberos error message. This allows the client to + understand a server failure more precisely. In addition, the server + may return errors to the client that are normally handled at the + application layer in the server, in order to let the client try to + recover. After receiving an error message, the client may attempt to + resubmit an AP request. + #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 + + These flags are only used if a client is aware of these conventions + when using the SSPI on the Windows platform, they are not generally + used by default. + + When NetBIOS addresses are used in the GSSAPI, they are identified + by the GSS_C_AF_NETBIOS value. This value is defined as: + #define GSS_C_AF_NETBIOS 0x14 + NetBios addresses are 16-octet addresses typically composed of 1 to
th
15 characters, trailing blank (ascii char 20) filled, with a 16 + octet of 0x0. + +8.2 GSSAPI Checksum Type + + The GSSAPI checksum type and algorithm is defined in Section 5. Only + the first 8 octets of the checksum are used. The resulting checksum + is stored in the SGN_CKSUM field (See [5] Section 1.2) for + GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). + + MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, + MIC_seq, MIC_checksum) + { + HMAC (K, SK, 13, K4); + T = 15; + memcpy (T_plus_hdr_plus_msg + 00, &T, 4); + memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8); + // 0101 1100 FFFFFFFF + memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); + MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); + HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); + memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K5); + }else{ + HMAC (K, &T, 4, K5); + +Swift Category - Informational 6 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + } + if (fRC4_EXP) memset(K5+7, 0xAB, 9); + HMAC(K5, MIT_checksum, 8, K6); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K6, seq_plus_direction, 8, MIC_seq); + } + +8.3 GSSAPI Encryption Types + + There are two encryption types for GSSAPI message tokens, one that + is 128 bits in strength, and one that is 56 bits in strength as + defined in Section 6. + + All padding is rounded up to 1 byte. One byte is needed to say that + there is 1 byte of padding. The DES based mechanism type uses 8 byte + padding. See [5] Section 1.2.2.3. + + The encryption mechanism used for GSS wrap based messages is as + follow: + + + WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, + WRAP_seq, WRAP_checksum, edata, edata_len) + { + HMAC (K, SK, 13, K7); + T = 13; + PAD = 1; + memcpy (T_hdr_conf_msg_pad + 00, &T, 4); + memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 + FFFFFFFF + memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); + memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); + MD5 (T_hdr_conf_msg_pad, + 4 + 8 + 8 + msg_len + 1, + MD5_of_T_hdr_conf_msg_pad); + HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); + memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 + bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K8); + }else{ + HMAC (K, &T, 4, K8); + } + if (fRC4_EXP) memset(K8+7, 0xAB, 9); + HMAC(K8, WRAP_checksum, 8, K9); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + +Swift Category - Informational 7 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K9, seq_plus_direction, 8, WRAP_seq); + + for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte + of key with 0xF0 + T = 0; + if (fRC4_EXP){ + *(DWORD *)(L40+10) = T; + HMAC(K10, L40, 14, K11); + memset(K11+7, 0xAB, 9); + }else{ + HMAC(K10, &T, 4, K11); + } + HMAC(K11, seq_num, 4, K12); + RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, + edata); /* skip T & hdr */ + edata_len = 8 + msg_len + 1; // conf + msg_len + pad + } + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +9. Security Considerations + + Care must be taken in implementing this encryption type because it + uses a stream cipher. If a different IV isn’t used in each direction + when using a session key, the encryption is weak. By using the + sequence number as an IV, this is avoided. + +10. Acknowledgements + + We would like to thank Salil Dangi for the valuable input in + refining the descriptions of the functions and review input. + +11. References + + 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997 + + 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993 + + + +Swift Category - Informational 8 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, + June 1996 + + 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April + 1992 + + 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April + 1992 + + 8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption + Algorithm", Work in Progress. + + 9 RC4 is a proprietary encryption algorithm available under license + from RSA Data Security Inc. For licensing information, contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + 10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 04.txt, June 25, 1999 + + +12. Author's Addresses + + Mike Swift + Dept. of Computer Science + Sieg Hall + University of Washington + Seattle, WA 98105 + Email: mikesw@cs.washington.edu + + John Brezak + Microsoft + One Microsoft Way + Redmond, Washington + Email: jbrezak@microsoft.com + + + + + + + + + + + + + + + +Swift Category - Informational 9 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + +13. Full Copyright Statement + + "Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and + furnished to others, and derivative works that comment on or + otherwise explain it or assist in its implementation may be + prepared, copied, published and distributed, in whole or in + part, without restriction of any kind, provided that the above + copyright notice and this paragraph are included on all such + copies and derivative works. However, this document itself may + not be modified in any way, such as by removing the copyright + notice or references to the Internet Society or other Internet + organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or + as required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will + not be revoked by the Internet Society or its successors or + assigns. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 10 + diff --git a/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt new file mode 100644 index 0000000..89e6452 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt @@ -0,0 +1,1594 @@ + +DHC Working Group Ken Hornstein +INTERNET-DRAFT NRL +Category: Standards Track Ted Lemon +<draft-hornstein-dhc-kerbauth-02.txt> Internet Engines, Inc. +20 February 2000 Bernard Aboba +Expires: September 1, 2000 Microsoft + Jonathan Trostle + Cisco Systems + + DHCP Authentication Via Kerberos V + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet- Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference material +or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +The distribution of this memo is unlimited. + +1. Copyright Notice + +Copyright (C) The Internet Society (2000). All Rights Reserved. + +2. Abstract + +The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for +host configuration. In some circumstances, it is useful for the DHCP +client and server to be able to mutually authenticate as well as to +guarantee the integrity of DHCP packets in transit. This document +describes how Kerberos V may be used in order to allow a DHCP client and +server to mutually authenticate as well as to protect the integrity of +the DHCP exchange. The protocol described in this document is capable of +handling both intra-realm and inter-realm authentication. + + + + + + +Hornstein, et al. Standards Track [Page 1] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +3. Introduction + +The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for +host configuration. In some circumstances, it is useful for the DHCP +client and server to be able to mutually authenticate as well as to +guarantee the integrity of DHCP packets in transit. This document +describes how Kerberos V may be used in order to allow a DHCP client and +server to mutually authenticate as well as to protect the integrity of +the DHCP exchange. The protocol described in this document is capable +of handling both intra-realm and inter-realm authentication. + +3.1. Terminology + +This document uses the following terms: + +DHCP client + A DHCP client or "client" is an Internet host using DHCP to + obtain configuration parameters such as a network address. + +DHCP server + A DHCP server or "server" is an Internet host that returns + configuration parameters to DHCP clients. + +Home KDC The KDC corresponding to the DHCP client's realm. + +Local KDC The KDC corresponding to the DHCP server's realm. + +3.2. Requirements language + +In this document, the key words "MAY", "MUST, "MUST NOT", "optional", +"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as +described in [1]. + +4. Protocol overview + +In DHCP authentication via Kerberos V, DHCP clients and servers utilize +a Kerberos session key in order to compute a message integrity check +value included within the DHCP authentication option. The message +integrity check serves to authenticate as well as integrity protect the +messages, while remaining compatible with the operation of a DHCP relay. +Replay protection is also provided by a replay counter within the +authentication option, as described in [3]. + +Each server maintains a list of session keys and identifiers for +clients, so that the server can retrieve the session key and identifier +used by a client to which the server has provided previous configuration +information. Each server MUST save the replay counter from the previous +authenticated message. To avoid replay attacks, the server MUST discard + + + +Hornstein, et al. Standards Track [Page 2] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +any incoming message whose replay counter is not strictly greater than +the replay counter from the previous message. + +DHCP authentication, described in [3], must work within the existing +DHCP state machine described in [4]. For a client in INIT state, this +means that the client must obtain a valid TGT, as well as a session key, +within the two round-trips provided by the +DHCPDISCOVER/OFFER/REQUEST/ACK sequence. + +In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP +server within the DHCPDISCOVER message. The DHCP server then completes +the AS_REQ using the IP address to be assigned to the client, and +submits this to the client's home KDC in order to obtain a TGT on the +client's behalf. Once the home KDC responds with an AS_REP, the DHCP +server extracts the client TGT and submits this along with its own TGT +to the home KDC, in order to obtain a user-to-user ticket to the DHCP +client. The AS_REP as well as the AP_REQ are included by the DHCP server +in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain +a home realm TGT and TGT session key, using the latter to decrypt the +user-to-user ticket to obtain the user-to-user session key. It is the +user-to-user session key that is used to authenticate and integrity +protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly, +this same session key is used to compute the integrity attribute in the +server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3]. + +In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit +the home realm TGT in the DHCPREQUEST, along with authenticating and +integrity protecting the message using an integrity attribute within the +authentication option. The integrity attribute is computed using the +existing session key. The DHCP server can then return a renewed user- +to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST +message from a client in INIT-REBOOT state can only be validated by +servers that used the same session key to compute the integrity +attribute in their DHCPOFFER messages. + +Other servers will discard the DHCPREQUEST messages. Thus, only servers +that used the user-to-user session key selected by the client will be +able to determine that their offered configuration information was not +selected, returning the offered network address to the server's pool of +available addresses. The servers that cannot validate the DHCPREQUEST +message will eventually return their offered network addresses to their +pool of available addresses as described in section 3.1 of the DHCP +specification [4]. + +When sending a DHCPINFORM, there are two possible procedures. If the +client knows the DHCP server it will be interacting with, then it can +obtain a ticket to the DHCP server from the local realm KDC. This will +require obtaining a TGT to its home realm, as well as possibly a cross- + + + +Hornstein, et al. Standards Track [Page 3] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +realm TGT to the local realm if the local and home realms differ. Once +the DHCP client has a local realm TGT, it can then request a DHCP server +ticket in a TGS_REQ. The DHCP client can then include AP_REQ and +integrity attributes within the DHCPINFORM. The integrity attribute is +computed as described in [3], using the session key obtained from the +TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated +using the same session key. + +If the DHCP client does not know the DHCP server it is interacting with +then it will not be able to obtain a ticket to it and a different +procedure is needed. In this case, the client will include in the +DHCPINFORM an authentication option with a ticket attribute containing +its home realm TGT. The DHCP server will then use this TGT in order to +request a user-to-user ticket from the home KDC in a TGS_REQ. The DHCP +server will return the user-to-user ticket and will authenticate and +integrity protect the DHCPACK/DHCPNAK message. This is accomplished by +including AP_REQ and integrity attributes within the authentication +option included with the DHCPACK/DHCPNAK messages. + +In order to support the DHCP client's ability to authenticate the DHCP +server in the case where the server name is unknown, the Kerberos +principal name for the DHCP server must be of type KRB_NT_SRV_HST with +the service name component equal to 'dhcp'. For example, the DHCP server +principal name for the host srv.foo.org would be of the form +dhcp/srv.foo.org. The client MUST validate that the DHCP server +principal name has the above format. This convention requires that the +administrator ensure that non-DHCP server principals do not have names +that match the above format. + +4.1. Authentication Option Format + +A summary of the authentication option format for DHCP authentication +via Kerberos V is shown below. The fields are transmitted from left to +right. + +0 1 2 3 +0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Code | Length | Protocol | Algorithm | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Global Replay Counter | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Global Replay Counter | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attributes... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Code + + + +Hornstein, et al. Standards Track [Page 4] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + TBD - DHCP Authentication + +Length + + The length field is a single octet and indicates the length of the + Protocol, Algorith, and Authentication Information fields. Octets + outside the range of the length field should be ignored on reception. + +Protocol + + TBD - DHCP Kerberos V authentication + +Algorithm + + The algorithm field is a single octet and defines the specific + algorithm to be used for computation of the authentication option. + Values for the field are as follows: + + 0 - reserved + 1 - HMAC-MD5 + 2 - HMAC-SHA + 3 - 255 reserved + +Global Replay Counter + + As described in [3], the global replay counter field is 8 octets in + length. It MUST be set to the value of a monotonically increasing + counter. Using a counter value such as the current time of day (e.g., + an NTP-format timestamp [10]) can reduce the danger of replay + attacks. + +Attributes + + The attributes field consists of type-length-value attributes of the + following format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Reserved | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Type + The type field is a single octet and is defined as follows: + + 0 - Integrity check + + + +Hornstein, et al. Standards Track [Page 5] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + 1 - TICKET + 2 - Authenticator + 3 - EncTicketPart + 10 - AS_REQ + 11 - AS_REP + 12 - TGS_REQ + 13 - TGS_REP + 14 - AP_REQ + 15 - AP_REP + 20 - KRB_SAFE + 21 - KRB_PRIV + 22 - KRB_CRED + 25 - EncASRepPart + 26 - EncTGSRepPart + 27 - EncAPRepPart + 28 - EncKrbPrvPart + 29 - EncKrbCredPart + 30 - KRB_ERROR + + Note that the values of the Type field are the same as in the + Kerberos MSG-TYPE field. As a result, no new number spaces are + created for IANA administration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hornstein, et al. Standards Track [Page 6] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + The following attribute types are allowed within the following + messages: + + DISCOVER OFFER REQUEST DECLINE # Attribute + -------------------------------------------------------- + 0 1 1 1 0 Integrity check + 0 0 0-1 0 1 Ticket + 1 0 0 0 10 AS_REQ + 0 1 0 0 11 AS_REP + 0 1 0 0 14 AP_REQ + 0 0-1 0 0 30 KRB_ERROR + + RELEASE ACK NAK INFORM INFORM # Attribute + w/known w/unknown + server server + --------------------------------------------------------------- + 1 1 1 1 0 0 Integrity check + 0 0 0 0 1 1 Ticket + 0 0 0 0 0 10 AS_REQ + 0 0 0 0 0 11 AS_REP + 0 0-1 0 1 0 14 AP_REQ + 0 0 0-1 0 0 30 KRB_ERROR + +4.2. Client behavior + +The following section, which incorporates material from [3], describes +client behavior in detail. + +4.2.1. INIT state + +When in INIT state, the client behaves as follows: + + +[1] As described in [3], the client MUST include the authentication + request option in its DHCPDISCOVER message along with option 61 + [11] to identify itself uniquely to the server. An AS_REQ attribute + MUST be included within the authentication request option. This + (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags + and MAY include pre-authentication data (PADATA) if the client + knows what PADATA its home KDC will require. The ADDRESSES field in + the AS_REQ will be ommitted since the client does not yet know its + IP address. The ETYPE field will be set to an encryption type that + the client can accept. + +[2] The client MUST validate DHCPOFFER messages that include an + authentication option. Messages including an authentication option + with a KRB_ERROR attribute and no integrity attribute are treated + as though they are unauthenticated. More typically, authentication + + + +Hornstein, et al. Standards Track [Page 7] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + options within the DHCPOFFER message will include AS_REP, AP_REQ, + and integrity attributes. To validate the authentication option, + the client decrypts the enc-part of the AS_REP in order to obtain + the TGT session key. This is used to decrypt the enc-part of the + AP_REQ in order to obtain the user-to-user session key. The user- + to-user session key is then used to compute the message integrity + check as described in [3], and the computed value is compared to + the value within the integrity attribute. The client MUST discard + any messages which fail to pass validation and MAY log the + validation failure. + + As described in [3], the client selects one DHCPOFFER message as + its selected configuration. If none of the DHCPOFFER messages + received by the client include an authentication option, the client + MAY choose an unauthenticated message as its selected + configuration. DHCPOFFER messages including an authentication + option with a KRB_ERROR attribute and no integrity attribute are + treated as though they are unauthenticated. The client SHOULD be + configurable to accept or reject unauthenticated DHCPOFFER + messages. + +[3] The client replies with a DHCPREQUEST message that MUST include an + authentication option. The authentication option MUST include an + integrity attribute, computed as described in [3], using the user + to user session key recovered in step 2. + +[4] As noted in [3], the client MUST validate a DHCPACK message from + the server that includes an authentication option. DHCPACK or + DHCPNAK messages including an authentication option with a + KRB_ERROR attribute and no integrity attribute are treated as + though they are unauthenticated. The client MUST silently discard + the DHCPACK if the message fails to pass validation and MAY log the + validation failure. If the DHCPACK fails to pass validation, the + client MUST revert to the INIT state and return to step 1. The + client MAY choose to remember which server replied with an invalid + DHCPACK message and discard subsequent messages from that server. + +4.2.2. INIT-REBOOT state + +When in INIT-REBOOT state, if the user-to-user ticket is still valid, +the client MUST re-use the session key from the DHCP server user-to-user +ticket in its DHCPREQUEST message. This is used to generate the +integrity attribute contained within the authentication option, as +described in [3]. In the DHCPREQUEST, the DHCP client also includes its +home realm TGT in a ticket attribute in the authentication option in +order to assist the DHCP server in renewing the user-to-user ticket. To +ensure that the user-to-user ticket remains valid throughout the DHCP +lease period so that the renewal process can proceed, the Kerberos + + + +Hornstein, et al. Standards Track [Page 8] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +ticket lifetime SHOULD be set to exceed the DHCP lease time. If the +user-to-user ticket is expired, then the client MUST return to the INIT +state. + +The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages +if no authenticated messages were received. DHCPACK/DHCPNAK messages +with an authentication option containing a KRB_ERROR attribute and no +integrity attribute are treated as though they are unauthenticated. The +client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK +messages as specified in section 3.2 of the DHCP specification [4]. + +4.2.3. RENEWING state + +When in RENEWING state, the DHCP client can be assumed to have a valid +IP address, as well as a TGT to the home realm, a user-to-user ticket +provided by the DHCP server, and a session key with the DHCP server, all +obtained during the original DHCP conversation. If the user-to-user +ticket is still valid, the client MUST re-use the session key from the +user-to-user ticket in its DHCPREQUEST message to generate the integrity +attribute contained within the authentication option. + +Since the DHCP client can renew the TGT to the home realm, it is +possible for it to continue to hold a valid home realm TGT. However, +since the DHCP client did not obtain the user-to-user ticket on its own, +it will need to rely on the DHCP server to renew this ticket. In the +DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket +attribute in the authentication option in order to assist the DHCP +server in renewing the user-to-user ticket. + +If the DHCP server user-to-user ticket is expired, then the client MUST +return to INIT state. To ensure that the user-to-user ticket remains +valid throughout the DHCP lease period so that the renewal process can +proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP +lease time. If client receives no DHCPACK messages or none of the +DHCPACK messages pass validation, the client behaves as if it had not +received a DHCPACK message in section 4.4.5 of the DHCP specification +[4]. + +4.2.4. REBINDING state + +When in REBINDING state, the DHCP client can be assumed to have a valid +IP address, as well as a TGT to the home realm, a user-to-user ticket +and a session key with the DHCP server, all obtained during the original +DHCP conversation. If the user-to-user ticket is still valid, the +client MUST re-use the session key from the user-to-user ticket in its +DHCPREQUEST message to generate the integrity attribute contained within +the authentication option, as described in [3]. + + + + +Hornstein, et al. Standards Track [Page 9] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +Since the DHCP client can renew the TGT to the home realm, it is +possible for it to continue to hold a valid home realm TGT. However, +since the DHCP client did not obtain the user-to-user ticket on its own, +it will need to rely on the DHCP server to renew this ticket. In the +DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket +attribute in the authentication option in order to assist the DHCP +server in renewing the user-to-user ticket. + +If the user-to-user ticket is expired, then the client MUST return to +INIT state. To ensure that the user-to-user ticket remains valid +throughout the DHCP lease period so that the renewal process can +proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP +lease time. If client receives no DHCPACK messages or none of the +DHCPACK messages pass validation, the client behaves as if it had not +received a DHCPACK message in section 4.4.5 of the DHCP specification +[4]. + +4.2.5. DHCPRELEASE message + +Clients sending a DHCPRELEASE MUST include an authentication option. The +authentication option MUST include an integrity attribute, computed as +described in [3], using the user to user session key. + +4.2.6. DHCPDECLINE message + +Clients sending a DHCPDECLINE MUST include an authentication option. The +authentication option MUST include an integrity attribute, computed as +described in [3], using the user to user session key. + +4.2.7. DHCPINFORM message + +Since the client already has some configuration information, it can be +assumed that it has the ability to obtain a home or local realm TGT +prior to sending the DHCPINFORM. + +If the DHCP client knows which DHCP server it will be interacting with, +then it SHOULD include an authentication option containing AP_REQ and +integrity attributes within the DHCPINFORM. The DHCP client first +requests a TGT to the local realm via an AS_REQ and then using the TGT +returned in the AS_REP to request a ticket to the DHCP server from the +local KDC in a TGS_REQ. The session key obtained from the TGS_REP will +be used to generate the integrity attribute as described in [3]. + +If the DHCP client does not know what DHCP server it will be talking to, +then it cannot obtain a ticket to the DHCP server. In this case, the +DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an +authentication option including a ticket attribute only. The ticket +attribute includes a TGT for the home realm. The client MUST validate + + + +Hornstein, et al. Standards Track [Page 10] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +that the DHCP server name in the received Kerberos AP_REQ message is of +the form dhcp/.... as described in section 4. + +The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages +if no authenticated messages were received. DHCPACK/DHCPNAK messages +with an authentication option containing a KRB_ERROR attribute and no +integrity attribute are treated as though they are unauthenticated. The +client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK +messages as specified in section 3.2 of the DHCP specification [4]. + +4.3. Server behavior + +This section, which relies on material from [3], describes the behavior +of a server in response to client messages. + +4.3.1. After receiving a DHCPDISCOVER message + +For installations where IP addresses are required within tickets, the +DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field +based on the IP address that it will include in the DHCPOFFER. The DHCP +server sends the AS_REQ to the home KDC with the FORWARDABLE flag set. +The home KDC then replies to the DHCP server with an AS_REP. The DHCP +server extracts the client TGT from the AS_REP and forms a TGS_REQ, +which it sends to the home KDC. + +If the DHCP server and client are in different realms, then the DHCP +server will need to obtain a TGT to the home realm from the KDC of its +own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the +DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag +set and includes the client home realm TGT in the ADDITIONAL-TICKETS +field, thus requesting a user-to ticket to the DHCP client. The home +KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user +ticket is encrypted in the client's home realm TGT session key. + +In order to recover the user-to-user session key, the DHCP server +decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP +server uses the session key that it shares with the home realm, obtained +in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to +the home realm. + +The DHCP server then sends a DHCPOFFER to the client, including AS_REP, +AP_REQ and integrity attributes within the authentication option. The +AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the +home KDC. The AP_REQ attribute includes an AP_REQ constructed by the +DHCP server based on the TGS_REP sent to it by the home KDC. The server +also includes an integrity attribute generated as specified in [3] from +the user-to-user session key. The server MUST record the user-to-user +session key selected for the client and use that session key for + + + +Hornstein, et al. Standards Track [Page 11] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +validating subsequent messages with the client. + +4.3.2. After receiving a DHCPREQUEST message + +The DHCP server uses the user-to-user session key in order to validate +the integrity attribute contained within the authentication option, +using the method specified in [3]. If the message fails to pass +validation, it MUST discard the message and MAY choose to log the +validation failure. + +If the message passes the validation procedure, the server responds as +described in [4], including an integrity attribute computed as specified +in [3] within the DHCPACK or DHCPNAK message. + +If the authentication option included within the DHCPREQUEST message +contains a ticket attribute then the DHCP server will use the home realm +TGT included in the ticket attribute in order to renew the user-to-user +ticket, which it returns in an AP_REQ attribute within the DHCPACK. +DHCPACK or DHCPNAK messages then include an integrity attribute +generated as specified in [3], using the new user-to-user session key +included within the AP_REQ. + +4.3.3. After receiving a DHCPINFORM message + +The server MAY choose to accept unauthenticated DHCPINFORM messages, or +only accept authenticated DHCPINFORM messages based on a site policy. + +When a client includes an authentication option in a DHCPINFORM message, +the server MUST respond with an authenticated DHCPACK or DHCPNAK +message. If the DHCPINFORM message includes an authentication option +including AP_REQ and integrity attributes, the DHCP server decrypts the +AP_REQ attribute and then recovers the session key. The DHCP server than +validates the integrity attribute included in the authentication option +using the session key. If the integrity attribute is invalid then the +DHCP server MUST silently discard the DHCPINFORM message. + +If the authentication option only includes a ticket attribute and no +integrity or AP_REQ attributes, then the DHCP server should assume that +the client needs the server to obtain a user-to-user ticket from the +home realm KDC. In this case, the DHCP server includes the client home +realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC. +It then receives a user-to-user ticket from the home realm KDC in a +TGS_REP. The DHCP server will then include AP_REQ and integrity +attributes within the DHCPACK/DHCPNAK. + +If the client does not include an authentication option in the +DHCPINFORM, the server can either respond with an unauthenticated +DHCPACK message, or a DHCPNAK if the server does not accept + + + +Hornstein, et al. Standards Track [Page 12] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +unauthenticated clients. + +4.3.4. After receiving a DHCPRELEASE message + +The DHCP server uses the session key in order to validate the integrity +attribute contained within the authentication option, using the method +specified in [3]. If the message fails to pass validation, it MUST +discard the message and MAY choose to log the validation failure. + +If the message passes the validation procedure, the server responds as +described in [4], marking the client's network address as not allocated. + +4.3.5. After receiving a DHCPDECLINE message + +The DHCP server uses the session key in order to validate the integrity +attribute contained within the authentication option, using the method +specified in [3]. If the message fails to pass validation, it MUST +discard the message and MAY choose to log the validation failure. + +If the message passes the validation procedure, the server proceeds as +described in [4]. + +4.4. Error handling + +When an error condition occurs during a Kerberos exchange, Kerberos +error messages can be returned by either side. These Kerberos error +messages MAY be logged by the receiving and sending parties. + +In some cases, it may be possible for these error messages to be +included within the authentication option via the KRB_ERROR attribute. +However, in most cases, errors will result in messages being silently +discarded and so no response will be returned. + +For example, if the home KDC returns a KRB_ERROR in response to the +AS_REQ submitted by the DHCP server on the client's behalf, then the +DHCP server will conclude that the DHCPDISCOVER was not authentic, and +will silently discard it. + +However, if the AS_REQ included PADATA and the home KDC responds with an +AS_REP, then the DHCP server can conclude that the client is authentic. +If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by +the home KDC in the TGS_REP, then the fault may lie with the DHCP server +rather than with the client. In this case, the DHCP server MAY choose to +return a KRB_ERROR within the authentication option included in the +DHCPOFFER. The client will then treat this as an unauthenticated +DHCPOFFER. + + + + + +Hornstein, et al. Standards Track [Page 13] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +Similarly, if the integrity attribute contained in the DHCPOFFER proves +invalid, the client will silently discard the DHCPOFFER and instead +accept an offer from another server if one is available. If the +integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then +the client behaves as if it did not receive a DHCPACK/DHCPNAK. + +When in INIT-REBOOT, REBINDING or RENEWING state, the client will +include a ticket attribute and integrity attribute within the +authentication option of the DHCPREQUEST, in order to assist the DHCP +server in renewing the user-to-user ticket. If the integrity attribute +is invalid, then the DHCP server MUST silently discard the DHCPREQUEST. + +However, if the integrity attribute is successfully validated by the +DHCP server, but the home realm TGT included in the ticket attribute is +invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in +response to its TGS_REQ to the home KDC. In this case, the DHCP server +MAY respond with a DHCPNAK including a KRB_ERROR attribute and no +integrity attribute within the authentication option. This will force +the client back to the INIT state, where it can receive a valid home +realm TGT. + +Where the client included PADATA in the AS_REQ attribute of the +authentication option within the DHCPDISCOVER and the AS_REQ was +successfully validated by the KDC, the DHCP server will conclude that +the DHCP client is authentic. In this case if the client successfully +validates the integrity attribute in the DHCPOFFER, but the server does +not validate the integrity attribute in the client's DHCPREQUEST, the +server MAY choose to respond with an authenticated DHCPNAK containing a +KRB_ERROR attribute. + +4.5. PKINIT issues + +When public key authentication is supported with Kerberos as described +in [8], the client certificate and a signature accompany the initial +request in the preauthentication fields. As a result, it is conceivable +that the incomplete AS_REQ included in the DHCPDISCOVER packet may +exceed the size of a single DHCP option, or even the MTU size. As noted +in [4], a single option may be as large as 255 octets. If the value to +be passed is larger than this the client concatenates together the +values of multiple instances of the same option. + +4.6. Examples + +4.6.1. INIT state + +In the intra-realm case where the DHCP Kerberos mutual authentication is +successful, the conversation will appear as follows: + + + + +Hornstein, et al. Standards Track [Page 14] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCPACK + (Integrity) + +In the case where the KDC returns a KRB_ERROR in response to the AS_REQ, +the server will silently discard the DHCPDISCOVER and the conversation +will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ) -> + AS_REQ -> + <- KRB_ERROR + +In the inter-realm case where the DHCP Kerberos mutual authentication is +successful, the conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +DHCPDISCOVER +(Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + + + +Hornstein, et al. Standards Track [Page 15] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + <- TGS_REP + + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCPACK + (Integrity) + +In the case where the client includes PADATA in the AS_REQ attribute +within the authentication option of the DHCPDISCOVER and the KDC returns +an error-free AS_REP indicating successful validation of the PADATA, the +DHCP server will conclude that the DHCP client is authentic. If the KDC +then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault +that lies with the DHCP server, the server MAY choose not to silently +discard the DHCPDISCOVER. Instead it MAY respond with a DHCPOFFER +including a KRB_ERROR attribute within the authentication option. The +client will then treat this as an unauthenticated DHCPOFFER. The +conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ + w/PADATA) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- KRB_ERROR + <- DHCPOFFER, + (KRB_ERROR) +DHCPREQUEST -> + <- DHCPACK + +In the intra-realm case where the client included PADATA in the AS_REQ +attribute of the authentication option and the AS_REQ was successfully +validated by the KDC, the DHCP server will conclude that the DHCP client +is authentic. In this case if the client successfully validates the +integrity attribute in the DHCPOFFER, but the server does not validate +the integrity attribute in the client's DHCPREQUEST, the server MAY + + + +Hornstein, et al. Standards Track [Page 16] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +choose to respond with an authenticated DHCPNAK containing a KRB_ERROR +attribute. The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ + w/PADATA) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCNAK + (KRB_ERROR, + Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +In the intra-realm case where the DHCP client cannot validate the +integrity attribute in the DHCPOFFER, the client silently discards the +DHCPOFFER. The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER + (Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + + + +Hornstein, et al. Standards Track [Page 17] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + [To another server] + (Integrity) -> + +In the intra-realm case where the DHCP client cannot validate the +integrity attribute in the DHCPACK, the client reverts to INIT state. +The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +DHCPDISCOVER +(Incomplete + AS_REQ) -> + AS_REQ -> + <- AS_REP + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPOFFER, + (AS_REP, + AP_REQ, + Integrity) +DHCPREQUEST + (Integrity) -> + <- DHCPACK + (Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +4.6.2. INIT-REBOOT, RENEWING or REBINDING + +In the intra-realm or inter-realm case where the original user-to-user +ticket is still valid, and the DHCP server still has a valid TGT to the +home realm, the conversation will appear as follows: + + DHCP DHCP Home + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPACK + (AP_REQ, + + + +Hornstein, et al. Standards Track [Page 18] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + Integrity) + +In the intra-realm or inter-realm case where the DHCP server validates +the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in +response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to +silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK +to the client instead, using the user-to-user session key previously +established with the client. The conversation appears as follows: + + DHCP DHCP Home + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + TGS_REQ + U-2-U -> + <- KRB_ERROR + <- DHCPNAK + (KRB_ERROR, + Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +In the intra-realm or inter-realm case where the DHCP server cannot +validate the integrity attribute in the DHCPREQUEST, the DHCP server +MUST silently discard the DHCPREQUEST and the conversation will appear +as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + Silent discard +[Sequence repeats + until timeout] + +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +In the intra-realm or inter-realm case where the original user-to-user +ticket is still valid, the server validates the integrity attribute in + + + +Hornstein, et al. Standards Track [Page 19] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +the DHCPREQUEST, but the client fails to validate the integrity +attribute in the DHCPACK, the client will silently discard the DHCPACK. +The conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- + +DHCPREQUEST + (TGT, + Integrity) -> + + <- DHCPACK + (AP_REQ, + Integrity) +DHCPDISCOVER + (Incomplete + AS_REQ) -> + +4.6.3. DHCPINFORM (with known DHCP server) + +In the case where the DHCP client knows the DHCP server it will be +interacting with, the DHCP client will obtain a ticket to the DHCP +server and will include AP_REQ and integrity attributes within the +DHCPINFORM. + +Where the DHCP Kerberos mutual authentication is successful, the +conversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + (AP_REQ, + Integrity) -> + <- DHCPACK + (Integrity) + +In the inter-realm case where the DHCP Kerberos mutual authentication is +successful, the conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- + + + +Hornstein, et al. Standards Track [Page 20] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + (AP_REQ, + Integrity) -> + <- DHCPACK + (Integrity) + +In the inter-realm case where the DHCP server fails to validate the +integrity attribute in the DHCPINFORM, the server MUST silently discard +the DHCPINFORM. The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + (AP_REQ, + Integrity) -> + <- DHCPACK + (Integrity) +DHCPINFORM + (AP_REQ, + Integrity) -> + +In the inter-realm case where the DHCP client fails to validate the +integrity attribute in the DHCPACK, the client MUST silently discard the +DHCPACK. The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +TGS_REQ -> + <- TGS_REP +TGS_REQ -> + <- TGS_REP +DHCPINFORM + + + +Hornstein, et al. Standards Track [Page 21] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + (AP_REQ, + Integrity) -> + +4.6.4. DHCPINFORM (with unknown DHCP server) + +In the case where the DHCP client does not know the DHCP server it will +be interacting with, the DHCP client will only include a ticket +attribute within the DHCPINFORM. Thus the DHCP server will not be able +to validate the authentication option. + +Where the DHCP client is able to validate the DHCPACK and no error +occur, the onversation will appear as follows: + + DHCP DHCP + Client Server KDC +-------------- ------------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + TGS_REQ + U-2-U -> + <- TGS_REP + <- DHCPACK + (AP_REQ, + Integrity) + +In the inter-realm case where the DHCP server needs to obtain a TGT to +the home realm, and where the client successfully validates the DHCPACK, +the conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + <- TGS_REP + + TGS_REQ + U-2-U -> + + + +Hornstein, et al. Standards Track [Page 22] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + <- TGS_REP + <- DHCPACK + (AP_REQ, + Integrity) + +In the inter-realm case where the local KDC returns a KRB_ERROR in +response to the TGS_REQ from the DHCP server, the DHCP server MAY return +a KRB_ERROR within the DHCP authentication option included in a DHCPNAK. +The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + <- KRB_ERROR + <- DHCPNAK + (KRB_ERROR) + + +In the inter-realm case where the DHCP client fails to validate the +integrity attribute in the DHCPACK, the client MUST silently discard the +DHCPACK. The conversation will appear as follows: + + DHCP DHCP Home Local + Client Server KDC KDC +-------------- ------------- --------- --------- +AS_REQ -> + <- AS_REP +DHCPINFORM + (Ticket) -> + AS_REQ -> + <- AS_REP + TGS_REQ -> + (cross realm, + for home + KDC) + <- TGS_REP + + TGS_REQ + + + +Hornstein, et al. Standards Track [Page 23] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + + U-2-U -> + <- TGS_REP + <- DHCPACK + (AP_REQ, + Integrity) +DHCPINFORM + (Ticket) -> + +5. References + + +[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +[2] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service + (V5)", RFC 1510, September 1993. + +[3] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", + Internet draft (work in progress), draft-ietf-dhc- + authentication-11.txt, June 1999. + +[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March + 1997. + +[5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + +[6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. + +[7] Jain, V., Congdon, P., Roese, J., "Network Port Authentication", + IEEE 802.1 PAR submission, June 1999. + +[8] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, + J., Trostle, J., "Public Key Cryptography for Initial + Authentication in Kerberos", Internet draft (work in progress), + draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. + +[9] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., + Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm + Authentication in Kerberos", Internet draft (work in progress), + draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. + +[10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March + 1992. + +[11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft + (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt, + November 1998. + + + +Hornstein, et al. Standards Track [Page 24] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +6. Security Considerations + +DHCP authentication, described in [3], addresses the following threats: + + Modification of messages + Rogue servers + Unauthorized clients + +This section describes how DHCP authentication via Kerberos V addresses +each of these threats. + +6.1. Client security + +As noted in [3], it may be desirable to ensure that IP addresses are +only allocated to authorized clients. This can serve to protect against +denial of service attacks. To address this issue it is necessary for +DHCP client messages to be authenticated. In order to guard against +message modification, it is also necessary for DHCP client messages to +be integrity protected. + +Note that this protocol does not make use of KRB_SAFE, so as to allow +modification of mutable fields by the DHCP relay. Replay protection is +therefore provided within the DHCP authentication option itself. + +In DHCP authentication via Kerberos V the DHCP client will authenticate, +integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and +DHCPRELEASE messages using a user-to-user session key obtained by the +DHCP server from the home KDC. If the DHCP client knows the DHCP server +it will be interacting with, then the DHCP client MAY also authenticate, +integrity and replay-protect the DHCPINFORM message using a session key +obtained from the local realm KDC for the DHCP server it expects to +converse with. + +Since the client has not yet obtained a session key, DHCPDISCOVER +packets cannot be authenticated using the session key. However, the +client MAY include pre-authentication data in the PADATA field included +in the DHCPDISCOVER packet. Since the PADATA will then be used by the +DHCP server to request a ticket on the client's behalf, the DHCP server +will learn from the AS_REP whether the PADATA was acceptable or not. +Therefore in this case, the DHCPDISCOVER will be authenticated but not +integrity protected. + +Where the DHCP client does not know the DHCP server it will be +interacting with ahead of time, the DHCPINFORM message will not be +authenticated, integrity or replay protected. + +Note that snooping of PADATA and TGTs on the wire may provide an +attacker with a means of mounting a dictionary attack, since these items + + + +Hornstein, et al. Standards Track [Page 25] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +are typically encrypted with a key derived from the user's password. +Thus use of strong passwords and/or pre-authentication methods utilizing +strong cryptography (see [8]) are recommended. + +6.2. Network access control + +DHCP authentication has been proposed as a method of limiting access to +network media that are not physically secured such as wireless LANs and +ports in college residence halls. However, it is not particularly well +suited to this purpose since even if address allocation is denied an +inauthentic client may use a statically assigned IP address instead, or +may attempt to access the network using non-IP protocols. As a result, +other methods, described in [6]-[7], have been proposed for controlling +access to wireless media and switched LANs. + +6.3. Server security + +As noted in [3], it may be desirable to protect against rogue DHCP +servers put on the network either intentionally or by accident. To +address this issue it is necessary for DHCP server messages to be +authenticated. In order to guard against message modification, it is +also necessary for DHCP server messages to be integrity protected. +Replay protection is also provided within the DHCP authentication +option. + +All messages sent by the DHCP server are authenticated and integrity and +replaly protected using a session key. This includes the DHCPOFFER, +DHCPACK, and DHCPNAK messages. The session key is used to compute the +DHCP authentication option, which is verified by the client. + +In order to provide protection against rogue servers it is necessary to +prevent rogue servers from obtaining the credentials necessary to act as +a DHCP server. As noted in Section 4, the Kerberos principal name for +the DHCP server must be of type KRB_NT_SRV_HST with the service name +component equal to 'dhcp'. The client MUST validate that the DHCP server +principal name has the above format. This convention requires that the +administrator ensure that non-DHCP server principals do not have names +that match the above format. + +7. IANA Considerations + +This draft does not create any new number spaces for IANA +administration. + +8. Acknowledgements + +The authors would like to acknowledge Ralph Droms and William Arbaugh, +authors of the DHCP authentication draft [3]. This draft incorporates + + + +Hornstein, et al. Standards Track [Page 26] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +material from their work; however, any mistakes in this document are +solely the responsibility of the authors. + +9. Authors' Addresses + +Ken Hornstein +US Naval Research Laboratory +Bldg A-49, Room 2 +4555 Overlook Avenue +Washington DC 20375 USA + +Phone: +1 (202) 404-4765 +EMail: kenh@cmf.nrl.navy.mil + +Ted Lemon +Internet Engines, Inc. +950 Charter Street +Redwood City, CA 94063 + +Phone: +1 (650) 779 6031 +Email: mellon@iengines.net + +Bernard Aboba +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +Phone: +1 (425) 936-6605 +EMail: bernarda@microsoft.com + +Jonathan Trostle +170 W. Tasman Dr. +San Jose, CA 95134, U.S.A. + +Email: jtrostle@cisco.com +Phone: +1 (408) 527-6201 + + +10. Intellectual Property Statement + +The IETF takes no position regarding the validity or scope of any +intellectual property or other rights that might be claimed to pertain +to the implementation or use of the technology described in this +document or the extent to which any license under such rights might or +might not be available; neither does it represent that it has made any +effort to identify any such rights. Information on the IETF's +procedures with respect to rights in standards-track and standards- +related documentation can be found in BCP-11. Copies of claims of + + + +Hornstein, et al. Standards Track [Page 27] + + +INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 + + +rights made available for publication and any assurances of licenses to +be made available, or the result of an attempt made to obtain a general +license or permission for the use of such proprietary rights by +implementors or users of this specification can be obtained from the +IETF Secretariat. + +The IETF invites any interested party to bring to its attention any +copyrights, patents or patent applications, or other proprietary rights +which may cover technology that may be required to practice this +standard. Please address the information to the IETF Executive +Director. + +11. Full Copyright Statement + +Copyright (C) The Internet Society (2000). All Rights Reserved. +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it or +assist in its implmentation may be prepared, copied, published and +distributed, in whole or in part, without restriction of any kind, +provided that the above copyright notice and this paragraph are included +on all such copies and derivative works. However, this document itself +may not be modified in any way, such as by removing the copyright notice +or references to the Internet Society or other Internet organizations, +except as needed for the purpose of developing Internet standards in +which case the procedures for copyrights defined in the Internet +Standards process must be followed, or as required to translate it into +languages other than English. The limited permissions granted above are +perpetual and will not be revoked by the Internet Society or its +successors or assigns. This document and the information contained +herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE +INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +12. Expiration Date + +This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>, and +expires October 1, 2000. + + + + + + + + + + + + +Hornstein, et al. Standards Track [Page 28] + + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt new file mode 100644 index 0000000..208d057 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt @@ -0,0 +1,301 @@ +INTERNET-DRAFT Mike Swift +draft-ietf-cat-iakerb-04.txt Microsoft +Updates: RFC 1510 Jonathan Trostle +July 2000 Cisco Systems + + + Initial Authentication and Pass Through Authentication + Using Kerberos V5 and the GSS-API (IAKERB) + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance + with all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This draft expires on January 31st, 2001. + + +1. Abstract + + This document defines an extension to the Kerberos protocol + specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC + 1964 [2]) that enables a client to obtain Kerberos tickets for + services where: + + (1) The client knows its principal name and password, but not + its realm name (applicable in the situation where a user is already + on the network but needs to authenticate to an ISP, and the user + does not know his ISP realm name). + (2) The client is able to obtain the IP address of the service in + a realm which it wants to send a request to, but is otherwise unable + to locate or communicate with a KDC in the service realm or one of + the intermediate realms. (One example would be a dial up user who + does not have direct IP connectivity). + (3) The client does not know the realm name of the service. + + +2. Motivation + + When authenticating using Kerberos V5, clients obtain tickets from + a KDC and present them to services. This method of operation works + + well in many situations, but is not always applicable since it + requires the client to know its own realm, the realm of the target + service, the names of the KDC's, and to be able to connect to the + KDC's. + + This document defines an extension to the Kerberos protocol + specification (RFC 1510) [1] that enables a client to obtain + Kerberos tickets for services where: + + (1) The client knows its principal name and password, but not + its realm name (applicable in the situation where a user is already + on the network but needs to authenticate to an ISP, and the user + does not know his ISP realm name). + (2) The client is able to obtain the IP address of the service in + a realm which it wants to send a request to, but is otherwise unable + to locate or communicate with a KDC in the service realm or one of + the intermediate realms. (One example would be a dial up user who + does not have direct IP connectivity). + (3) The client does not know the realm name of the service. + + In this proposal, the client sends KDC request messages directly + to application servers if one of the above failure cases develops. + The application server acts as a proxy, forwarding messages back + and forth between the client and various KDC's (see Figure 1). + + + Client <---------> App Server <----------> KDC + proxies + + + Figure 1: IAKERB proxying + + + In the case where the client has sent a TGS_REQ message to the + application server without a realm name in the request, the + application server will forward an error message to the client + with its realm name in the e-data field of the error message. + The client will attempt to proceed using conventional Kerberos. + +3. When Clients Should Use IAKERB + + We list several, but possibly not all, cases where the client + should use IAKERB. In general, the existing Kerberos paradigm + where clients contact the KDC to obtain service tickets should + be preserved where possible. + + (a) AS_REQ cases: + + (i) The client is unable to locate the user's KDC or the KDC's + in the user's realm are not responding, or + (ii) The user has not entered a name which can be converted + into a realm name (and the realm name cannot be derived from + a certificate). + + (b) TGS_REQ cases: + + (i) the client determines that the KDC(s) in either an + intermediate realm or the service realm are not responding or + + the client is unable to locate a KDC, + + (ii) the client is not able to generate the application server + realm name. + + +4. GSSAPI Encapsulation + + The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the + mechanism proposed by SPNEGO for negotiating protocol variations, is: + {iso(1) member-body(2) United States(840) mit(113554) infosys(1) + gssapi(2) krb5(2) initialauth(4)} + + The AS request, AS reply, TGS request, and TGS reply messages are all + encapsulated using the format defined by RFC1964 [2]. This consists + of the GSS-API token framing defined in appendix B of RFC1508 [3]: + + InitialContextToken ::= + [APPLICATION 0] IMPLICIT SEQUENCE { + thisMech MechType + -- MechType is OBJECT IDENTIFIER + -- representing "Kerberos V5" + innerContextToken ANY DEFINED BY thisMech + -- contents mechanism-specific; + -- ASN.1 usage within innerContextToken + -- is not required + } + + The innerContextToken consists of a 2-byte TOK_ID field (defined + below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, + KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field + shall be one of the following values, to denote that the message is + either a request to the KDC or a response from the KDC. + + Message TOK_ID + KRB-KDC-REQ 00 03 + KRB-KDC-REP 01 03 + + +5. The Protocol + + a. The user supplies a password (AS_REQ): Here the Kerberos client + will send an AS_REQ message to the application server if it cannot + locate a KDC for the user's realm, or such KDC's do not respond, + or the user does not enter a name from which the client can derive + the user's realm name. The client sets the realm field of the + request equal to its own realm if the realm name is known, + otherwise the realm length is set to 0. Upon receipt of the AS_REQ + message, the application server checks if the client has included + a realm. + + If the realm was not included in the original request, the + application server must determine the realm and add it to the + AS_REQ message before forwarding it. If the application server + cannot determine the client realm, it returns the + KRB_AP_ERR_REALM_REQUIRED error-code in an error message to + the client: + + KRB_AP_ERR_REALM_REQUIRED 77 + + The error message can be sent in response to either an AS_REQ + message, or in response to a TGS_REQ message, in which case the + realm and principal name of the application server are placed + into the realm and sname fields respectively, of the KRB-ERROR + message. In the AS_REQ case, once the realm is filled in, the + application server forwards the request to a KDC in the user's + realm. It will retry the request if necessary, and forward the + KDC response back to the client. + + At the time the user enters a username and password, the client + should create a new credential with an INTERNAL NAME [3] that can + be used as an input into the GSS_Acquire_cred function call. + + This functionality is useful when there is no trust relationship + between the user's logon realm and the target realm (Figure 2). + + + User Realm KDC + / + / + / + / 2,3 + 1,4 / + Client<-------------->App Server + + + 1 Client sends AS_REQ to App Server + 2 App server forwards AS_REQ to User Realm KDC + 3 App server receives AS_REP from User Realm KDC + 4 App server sends AS_REP back to Client + + + Figure 2: IAKERB AS_REQ + + + + b. The user does not supply a password (TGS_REQ): The user includes a + TGT targetted at the user's realm, or an intermediate realm, in a + TGS_REQ message. The TGS_REQ message is sent to the application + server. + + If the client has included the realm name in the TGS request, then + the application server will forward the request to a KDC in the + request TGT srealm. It will forward the response back to the client. + + If the client has not included the realm name in the TGS request, + then the application server will return its realm name and principal + name to the client using the KRB_AP_ERR_REALM_REQUIRED error + described above. Sending a TGS_REQ message to the application server + without a realm name in the request, followed by a TGS request using + the returned realm name and then sending an AP request with a mutual + authentication flag should be subject to a local policy decision + (see security considerations below). Using the returned server + principal name in a TGS request followed by sending an AP request + message using the received ticket MUST NOT set any mutual + authentication flags. + + +6. Addresses in Tickets + + In IAKERB, the machine sending requests to the KDC is the server and + not the client. As a result, the client should not include its + addresses in any KDC requests for two reasons. First, the KDC may + reject the forwarded request as being from the wrong client. Second, + in the case of initial authentication for a dial-up client, the client + machine may not yet possess a network address. Hence, as allowed by + RFC1510 [1], the addresses field of the AS and TGS requests should be + blank and the caddr field of the ticket should similarly be left blank. + + +7. Combining IAKERB with Other Kerberos Extensions + + This protocol is usable with other proposed Kerberos extensions such as + PKINIT (Public Key Cryptography for Initial Authentication in Kerberos + [4]). In such cases, the messages which would normally be sent to the + KDC by the GSS runtime are instead sent by the client application to the + server, which then forwards them to a KDC. + + +8. Security Considerations + + A principal is identified by its principal name and realm. A client + that sends a TGS request to an application server without the request + realm name will only be able to mutually authenticate the server + up to its principal name. Thus when requesting mutual authentication, + it is preferable if clients can either determine the server realm name + beforehand, or apply some policy checks to the realm name obtained from + the returned error message. + + +9. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments 1510. + + [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request + for Comments 1964 + + [3] J. Linn. Generic Security Service Application Program Interface. + Request for Comments 1508 + + [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, + J. Trostle, Public Key Cryptography for Initial Authentication in + Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos- + pkinit-10.txt. + + +10. This draft expires on January 31st, 2001. + + +11. Authors' Addresses + + Michael Swift + Microsoft + One Microsoft Way + Redmond, Washington, 98052, U.S.A. + Email: mikesw@microsoft.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134, U.S.A. + Email: jtrostle@cisco.com + Phone: (408) 527-6201 diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt new file mode 100644 index 0000000..b3ec336 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt @@ -0,0 +1,174 @@ +INTERNET-DRAFT Jonathan Trostle +draft-ietf-cat-kerberos-extra-tgt-02.txt Cisco Systems +Updates: RFC 1510 Michael M. Swift +expires January 30, 2000 University of WA + + + Extension to Kerberos V5 For Additional Initial Encryption + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance + with all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + This document defines an extension to the Kerberos protocol + specification (RFC 1510) [1] to enable a preauthentication field in + the AS_REQ message to carry a ticket granting ticket. The session + key from this ticket granting ticket will be used to + cryptographically strengthen the initial exchange in either the + conventional Kerberos V5 case or in the case the user stores their + encrypted private key on the KDC [2]. + + +2. Motivation + + In Kerberos V5, the initial exchange with the KDC consists of the + AS_REQ and AS_REP messages. For users, the encrypted part of the + AS_REP message is encrypted in a key derived from a password. + Although a password policy may be in place to prevent dictionary + attacks, brute force attacks may still be a concern due to + insufficient key length. + + This draft specifies an extension to the Kerberos V5 protocol to + allow a ticket granting ticket to be included in an AS_REQ message + preauthentication field. The session key from this ticket granting + ticket will be used to cryptographically strengthen the initial + + exchange in either the conventional Kerberos V5 case or in the case + the user stores their encrypted private key on the KDC [2]. The + session key from the ticket granting ticket is combined with the + user password key (key K2 in the encrypted private key on KDC + option) using HMAC to obtain a new triple des key that is used in + place of the user key in the initial exchange. The ticket granting + ticket could be obtained by the workstation using its host key. + +3. The Extension + + The following new preauthentication type is proposed: + + PA-EXTRA-TGT 22 + + The preauthentication-data field contains a ticket granting ticket + encoded as an ASN.1 octet string. The server realm of the ticket + granting ticket must be equal to the realm in the KDC-REQ-BODY of + the AS_REQ message. In the absence of a trust relationship, the + local Kerberos client should send the AS_REQ message without this + extension. + + In the conventional (non-pkinit) case, we require the RFC 1510 + PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message. + If neither it or the PA-PK-KEY-REQ preauthentication field is + included in the AS_REQ message, the KDC will reply with a + KDC_ERR_PREAUTH_FAILED error message. + + We propose the following new etypes: + + des3-cbc-md5-xor 16 + des3-cbc-sha1-xor 17 + + The encryption key is obtained by: + + (1) Obtaining an output M from the HMAC-SHA1 function [3] using + the user password key (the key K2 in the encrypted private + key on KDC option of pkinit) as the text and the triple des + session key as the K input in HMAC: + + M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1. + + The session key from the accompanying ticket granting ticket + must be a triple des key when one of the triple des xor + encryption types is used. + (2) Concatenate the output M (20 bytes) with the first 8 non-parity + bits of the triple-des ticket granting ticket session key to + get 168 bits that will be used for the new triple-des encryption + key. + (3) Set the parity bits of the resulting key. + + The resulting triple des key is used to encrypt the timestamp + for the PA-ENC-TIMESTAMP preauthentication value (or in the + encrypted private key on KDC option of pkinit, it is used in + place of the key K2 to both sign in the PA-PK-KEY-REQ and for + encryption in the PA-PK-KEY-REP preauthentication types). + + If the KDC decrypts the encrypted timestamp and it is not within + the appropriate clock skew period, the KDC will reply with the + KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if + the above ticket granting ticket fails to decrypt properly, or if + it is not a valid ticket. + + The KDC will create the shared triple des key from the ticket + granting ticket session key and the user password key (the key K2 + in the encrypted private key on KDC case) using HMAC as specified + above and use it to validate the AS_REQ message and then to + encrypt the encrypted part of the AS_REP message (use it in place + of the key K2 for encryption in the PA-PK-KEY-REP preauthentication + field). + + Local workstation policy will determine the exact behaviour of + the Kerberos client with respect to the extension protocol. For + example, the client should consult policy to decide when to use + use the extension. This policy could be dependent on the user + identity, or whether the workstation is in the same realm as the + user. One possibility is for the workstation logon to fail if + the extension is not used. Another possibility is for the KDC + to set a flag in tickets issued when this extension is used. + + A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a + preauthentication field containing a ticket granting ticket, + a randomly generated subkey encrypted in the session key from + the ticket, and a timestamp structure encrypted in the user + password and then the randomly generated subkey was proposed. + Some advantages of the current proposal are that the KDC has two + fewer decryptions to perform per request and the client does not + have to generate a random key. + +4. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments 1510. + + [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle. + Public Key Cryptography for Initial Authentication in Kerberos. + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerberos-pkinit-08.txt + + [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for + Message Authentication. Request for Comments 2104. + + [4] J. Pato. Using Pre-authentication to Avoid Password Guessing + Attacks. OSF DCE SIG Request for Comments 26.0. + +5. Acknowledgement: We thank Ken Hornstein for some helpful comments. + +6. Expires January 30, 2000. + +7. Authors' Addresses + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134, U.S.A. + + Email: jtrostle@cisco.com + Phone: (408) 527-6201 + + Michael Swift + Email: mikesw@cs.washington.edu diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt new file mode 100644 index 0000000..d09a2de --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt new file mode 100644 index 0000000..1ab2b03 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt @@ -0,0 +1,523 @@ + +INTERNET-DRAFT Matthew Hur +draft-ietf-cat-kerberos-pk-cross-06.txt CyberSafe Corporation +Updates: RFC 1510 Brian Tung +expires October 10, 2000 Tatyana Ryutov + Clifford Neuman + Gene Tsudik + ISI + Ari Medvinsky + Keen.com + Bill Sommerfeld + Hewlett-Packard + + + Public Key Cryptography for Cross-Realm Authentication in Kerberos + + +0. Status Of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may + also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as ``work in + progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + + To learn the current status of any Internet-Draft, please check + the ``1id-abstracts.txt'' listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-cross-06.txt, and expires May 15, 1999. + Please send comments to the authors. + + +1. Abstract + + This document defines extensions to the Kerberos protocol + specification [1] to provide a method for using public key + cryptography to enable cross-realm authentication. The methods + defined here specify the way in which message exchanges are to be + used to transport cross-realm secret keys protected by encryption + under public keys certified as belonging to KDCs. + + +2. Introduction + + The Kerberos authentication protocol [2] can leverage the + advantages provided by public key cryptography. PKINIT [3] + describes the use of public key cryptography in the initial + authentication exchange in Kerberos. PKTAPP [4] describes how an + application service can essentially issue a kerberos ticket to + itself after utilizing public key cryptography for authentication. + Another informational document species the use of public key + crypography for anonymous authentication in Kerberos [5]. This + specification describes the use of public key crpytography in cross- + realm authentication. + + Without the use of public key cryptography, administrators must + maintain separate keys for every realm which wishes to exchange + authentication information with another realm (which implies n(n-1) + keys), or they must utilize a hierachichal arrangement of realms, + which may complicate the trust model by requiring evaluation of + transited realms. + + Even with the multi-hop cross-realm authentication, there must be + some way to locate the path by which separate realms are to be + transited. The current method, which makes use of the DNS-like + realm names typical to Kerberos, requires trust of the intermediate + KDCs. + + PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify + the administrative burden of maintaining cross-realm keys. Such + usage leverages a PKI for a non-centrally-administratable environment + (namely, inter-realm). Thus, a shared key for cross-realm + authentication can be established for a set period of time, and a + remote realm is able to issue policy information that is returned to + itself when a client requests cross-realm authentication. Such policy + information may be in the form of restrictions [7]. Furthermore, + these methods are transparent to the client; therefore, only the KDCs + need to be modified to use them. In this way, we take advantage of + the the distributed trust management capabilities of public key + crypography while maintaining the advantages of localized trust + management provided by Kerberos. + + + Although this specification utilizes the protocol specfied in the + PKINIT specification, it is not necessary to implement client + changes in order to make use of the changes in this document. + + +3. Objectives + + The objectives of this specification are as follows: + + 1. Simplify the administration required to establish Kerberos + cross-realm keys. + + 2. Avoid modification of clients and application servers. + + 3. Allow remote KDC to control its policy on cross-realm + keys shared between KDCs, and on cross-realm tickets + presented by clients. + + 4. Remove any need for KDCs to maintain state about keys + shared with other KDCs. + + 5. Leverage the work done for PKINIT to provide the public key + protocol for establishing symmetric cross realm keys. + + +4. Definitions + + The following notation is used throughout this specification: + KDC_l ........... local KDC + KDC_r ........... remote KDC + XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the + local KDC + TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the + client for presentation to the remote KDC + + This specification defines the following new types to be added to the + Kerberos specification: + PKCROSS kdc-options field in the AS_REQ is bit 9 + TE-TYPE-PKCROSS-KDC 2 + TE-TYPE-PKCROSS-CLIENT 3 + + This specification defines the following ASN.1 type for conveying + policy information: + CrossRealmTktData ::= SEQUENCE OF TypedData + + This specification defines the following types for policy information + conveyed in CrossRealmTktData: + PLC_LIFETIME 1 + PLC_SET_TKT_FLAGS 2 + PLC_NOSET_TKT_FLAGS 3 + + TicketExtensions are defined per the Kerberos specification [8]: + TicketExtensions ::= SEQUENCE OF TypedData + Where + TypedData ::= SEQUENCE { + data-type[0] INTEGER, + data-value[1] OCTET STRING OPTIONAL + } + + +5. Protocol Specification + + We assume that the client has already obtained a TGT. To perform + cross-realm authentication, the client does exactly what it does + with ordinary (i.e. non-public-key-enabled) Kerberos; the only + changes are in the KDC; although the ticket which the client + forwards to the remote realm may be changed. This is acceptable + since the client treats the ticket as opaque. + + +5.1. Overview of Protocol + + The basic operation of the PKCROSS protocol is as follows: + + 1. The client submits a request to the local KDC for + credentials for the remote realm. This is just a typical + cross realm request that may occur with or without PKCROSS. + + 2. The local KDC submits a PKINIT request to the remote KDC to + obtain a "special" PKCROSS ticket. This is a standard + PKINIT request, except that PKCROSS flag (bit 9) is set in + the kdc-options field in the AS_REQ. + + 3. The remote KDC responds as per PKINIT, except that + the ticket contains a TicketExtension, which contains + policy information such as lifetime of cross realm tickets + issued by KDC_l to a client. The local KDC must reflect + this policy information in the credentials it forwards to + the client. Call this ticket XTKT_(l,r) to indicate that + this ticket is used to authenticate the local KDC to the + remote KDC. + + 4. The local KDC passes a ticket, TGT_(c,r) (the cross realm + TGT between the client and remote KDC), to the client. + This ticket contains in its TicketExtension field the + ticket, XTKT_(l,r), which contains the cross-realm key. + The TGT_(c,r) ticket is encrypted using the key sealed in + XTKT_(l,r). (The TicketExtension field is not encrypted.) + The local KDC may optionally include another TicketExtension + type that indicates the hostname and/or IP address for the + remote KDC. + + 5. The client submits the request directly to the remote + KDC, as before. + + 6. The remote KDC extracts XTKT_(l,r) from the TicketExtension + in order to decrypt the encrypted part of TGT_(c,r). + + -------------------------------------------------------------------- + + Client Local KDC (KDC_l) Remote KDC (KDC_r) + ------ ----------------- ------------------ + Normal Kerberos + request for + cross-realm + ticket for KDC_r + ----------------------> + + PKINIT request for + XTKT(l,r) - PKCROSS flag + set in the AS-REQ + * -------------------------> + + PKINIT reply with + XTKT_(l,r) and + policy info in + ticket extension + <-------------------------- * + + Normal Kerberos reply + with TGT_(c,r) and + XTKT(l,r) in ticket + extension + <--------------------------------- + + Normal Kerberos + cross-realm TGS-REQ + for remote + application + service with + TGT_(c,r) and + XTKT(l,r) in ticket + extension + -------------------------------------------------> + + Normal Kerberos + cross-realm + TGS-REP + <--------------------------------------------------------------- + + * Note that the KDC to KDC messages occur only periodically, since + the local KDC caches the XTKT_(l,r). + -------------------------------------------------------------------- + + + Sections 5.2 through 5.4 describe in detail steps 2 through 4 + above. Section 5.6 describes the conditions under which steps + 2 and 3 may be skipped. + + Note that the mechanism presented above requires infrequent KDC to + KDC communication (as dictated by policy - this is discussed + later). Without such an exchange, there are the following issues: + 1) KDC_l would have to issue a ticket with the expectation that + KDC_r will accept it. + 2) In the message that the client sends to KDC_r, KDC_l would have + to authenticate KDC_r with credentials that KDC_r trusts. + 3) There is no way for KDC_r to convey policy information to KDC_l. + 4) If, based on local policy, KDC_r does not accept a ticket from + KDC_l, then the client gets stuck in the middle. To address such + an issue would require modifications to standard client + processing behavior. + Therefore, the infreqeunt use of KDC to KDC communication assures + that inter-realm KDC keys may be established in accordance with local + policies and that clients may continue to operate without + modification. + + +5.2. Local KDC's Request to Remote KDC + + When the local KDC receives a request for cross-realm authentication, + it first checks its ticket cache to see if it has a valid PKCROSS + ticket, XTKT_(l,r). If it has a valid XTKT_(l,r), then it does not + need to send a request to the remote KDC (see section 5.5). + + If the local KDC does not have a valid XTKT_(l,r), it sends a + request to the remote KDC in order to establish a cross realm key and + obtain the XTKT_(l,r). This request is in fact a PKINIT request as + described in the PKINIT specification; i.e., it consists of an AS-REQ + with a PA-PK-AS-REQ included as a preauthentication field. Note, + that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the + kdc_options field of the AS-REQ. Otherwise, this exchange exactly + follows the description given in the PKINIT specification. In + addition, the naming + + +5.3. Remote KDC's Response to Local KDC + + When the remote KDC receives the PKINIT/PKCROSS request from the + local KDC, it sends back a PKINIT response as described in + the PKINIT specification with the following exception: the encrypted + part of the Kerberos ticket is not encrypted with the krbtgt key; + instead, it is encrypted with the ticket granting server's PKCROSS + key. This key, rather than the krbtgt key, is used because it + encrypts a ticket used for verifying a cross realm request rather + than for issuing an application service ticket. Note that, as a + matter of policy, the session key for the XTKT_(l,r) MAY be of + greater strength than that of a session key for a normal PKINIT + reply, since the XTKT_(l,r) SHOULD be much longer lived than a + normal application service ticket. + + In addition, the remote KDC SHOULD include policy information in the + XTKT_(l,r). This policy information would then be reflected in the + cross-realm TGT, TGT_(c,r). Otherwise, the policy for TGT_(c,r) + would be dictated by KDC_l rather than by KDC_r. The local KDC MAY + enforce a more restrictive local policy when creating a cross-realm + ticket, TGT_(c,r). For example, KDC_r may dictate a lifetime + policy of eight hours, but KDC_l may create TKT_(c,r) with a + lifetime of four hours, as dictated by local policy. Also, the + remote KDC MAY include other information about itself along with the + PKCROSS ticket. These items are further discussed in section 6 + below. + + +5.4. Local KDC's Response to Client + + Upon receipt of the PKINIT/CROSS response from the remote KDC, + the local KDC formulates a response to the client. This reply + is constructed exactly as in the Kerberos specification, except + for the following: + + A) The local KDC places XTKT_(l,r) in the TicketExtension field of + the client's cross-realm, ticket, TGT_(c,r), for the remote realm. + Where + data-type equals 3 for TE-TYPE-PKCROSS-CLIENT + data-value is ASN.1 encoding of XTKT_(l,r) + + B) The local KDC adds the name of its CA to the transited field of + TGT_(c,r). + + +5.5 Remote KDC's Processing of Client Request + + When the remote KDC, KDC_r, receives a cross-realm ticket, + TGT_(c,r), and it detects that the ticket contains a ticket + extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt + the ticket, XTKT_(l,r), that is encoded in the ticket extension. + KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r). KDC_r + then uses the key obtained from XTKT_(l,r) in order to decrypt the + cross-realm ticket, TGT_(c,r). + + KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in + compliance with any policy information contained in XTKT_(l,r) (see + section 6). If the TGT_(c,r) is not in compliance with policy, then + the KDC_r responds to the client with a KRB-ERROR message of type + KDC_ERR_POLICY. + + +5.6. Short-Circuiting the KDC-to-KDC Exchange + + As we described earlier, the KDC to KDC exchange is required only + for establishing a symmetric, inter-realm key. Once this key is + established (via the PKINIT exchange), no KDC to KDC communication + is required until that key needs to be renewed. This section + describes the circumstances under which the KDC to KDC exchange + described in Sections 5.2 and 5.3 may be skipped. + + The local KDC has a known lifetime for TGT_(c,r). This lifetime may + be determined by policy information included in XTKT_(l,r), and/or + it may be determined by local KDC policy. If the local KDC already + has a ticket XTKT(l,r), and the start time plus the lifetime for + TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then + the local KDC may skip the exchange with the remote KDC, and issue a + cross-realm ticket to the client as described in Section 5.4. + + Since the remote KDC may change its PKCROSS key (referred to in + Section 5.2) while there are PKCROSS tickets still active, it SHOULD + cache the old PKCROSS keys until the last issued PKCROSS ticket + expires. Otherwise, the remote KDC will respond to a client with a + KRB-ERROR message of type KDC_ERR_TGT_REVOKED. + + +6. Extensions for the PKCROSS Ticket + + As stated in section 5.3, the remote KDC SHOULD include policy + information in XTKT_(l,r). This policy information is contained in + a TicketExtension, as defined by the Kerberos specification, and the + authorization data of the ticket will contain an authorization + record of type AD-IN-Ticket-Extensions. The TicketExtension defined + for use by PKCROSS is TE-TYPE-PKCROSS-KDC. + Where + data-type equals 2 for TE-TYPE-PKCROSS-KDC + data-value is ASN.1 encoding of CrossRealmTktData + + CrossRealmTktData ::= SEQUENCE OF TypedData + + + ------------------------------------------------------------------ + CrossRealmTktData types and the corresponding data are interpreted + as follows: + + ASN.1 data + type value interpretation encoding + ---------------- ----- -------------- ---------- + PLC_LIFETIME 1 lifetime (in seconds) INTEGER + for TGT_(c,r) + - cross-realm tickets + issued for clients by + TGT_l + + PLC_SET_TKT_FLAGS 2 TicketFlags that must BITSTRING + be set + - format defined by + Kerberos specification + + PLC_NOSET_TKT_FLAGS 3 TicketFlags that must BITSTRING + not be set + - format defined by + Kerberos specification + + Further types may be added to this table. + ------------------------------------------------------------------ + + +7. Usage of Certificates + + In the cases of PKINIT and PKCROSS, the trust in a certification + authority is equivalent to Kerberos cross realm trust. For this + reason, an implementation MAY choose to use the same KDC certificate + when the KDC is acting in any of the following three roles: + 1) KDC is authenticating clients via PKINIT + 2) KDC is authenticating another KDC for PKCROSS + 3) KDC is the client in a PKCROSS exchange with another KDC + + Note that per PKINIT, the KDC X.509 certificate (the server in a + PKINIT exchange) MUST contain the principal name of the KDC in the + subjectAltName field. + + +8. Transport Issues + + Because the messages between the KDCs involve PKINIT exchanges, and + PKINIT recommends TCP as a transport mechanism (due to the length of + the messages and the likelihood that they will fragment), the same + recommendation for TCP applies to PKCROSS as well. + + +9. Security Considerations + + Since PKCROSS utilizes PKINIT, it is subject to the same security + considerations as PKINIT. Administrators should assure adherence + to security policy - for example, this affects the PKCROSS policies + for cross realm key lifetime and for policy propogation from the + PKCROSS ticket, issued from a remote KDC to a local KDC, to + cross realm tickets that are issued by a local KDC to a client. + + +10. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray + J. Trostle. Public Key Cryptography for Initial Authentication + in Kerberos. + draft-ietf-cat-kerberos-pk-init-11.txt + + [4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman. Public + Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf- + cat-pktapp-02.txt + + [5] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt + + [6] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [7] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [8] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network Authentication + Service (V5). draft-ietf-cat-kerberos-revisions-05.txt + + +11. Authors' Addresses + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Brian Tung + Tatyana Ryutov + Clifford Neuman + Gene Tsudik + USC/Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey, CA 90292-6695 + Phone: +1 310 822 1511 + E-Mail: {brian, tryutov, bcn, gts}@isi.edu + + Ari Medvinsky + Keen.com + 2480 Sand Hill Road, Suite 200 + Menlo Park, CA 94025 + Phone +1 650 289 3134 + E-mail: ari@keen.com + + Bill Sommerfeld + Hewlett Packard + 300 Apollo Drive + Chelmsford MA 01824 + Phone: +1 508 436 4352 + E-Mail: sommerfeld@apollo.hp.com + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt new file mode 100644 index 0000000..9b0e76ad --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt @@ -0,0 +1,1059 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-11.txt Clifford Neuman +Updates: RFC 1510 USC/ISI +expires September 15, 2000 Matthew Hur + CyberSafe Corporation + Ari Medvinsky + Keen.com, Inc. + Sasha Medvinsky + Motorola + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15, + 2000. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with digital signature keys as the primary, required + mechanism. It also allows for the use of RSA keys and/or (static) + Diffie-Hellman certificates. Note in particular that PKINIT supports + the use of separate signature and encryption keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + secret key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], + anonymous Kerberos tickets can be issued by applying a NULL + signature in combination with Diffie-Hellman in the PKINIT exchange. + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a realm it will be represented using the "other" form of the realm + name as specified in the naming constraints section of RFC1510. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + <nametype> + ":" + <string> + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [14] (part of LDAPv3 [18]). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, in cases where the KDC does not provide a specific + policy based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name shall be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510 as: + + KRB_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm shall be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section + + RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + For the purposes of encoding an X.500 name as a Kerberos name for + use in Kerberos structures, the name-string shall be encoded as a + single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL, + as noted above. All Kerberos names must conform to validity + requirements as given in RFC 1510. Note that name mapping may be + required or optional, based on policy. + + We also define the following similar ASN.1 structure: + + CertPrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF UTF8String + } + + When a Kerberos PrincipalName is to be placed within an X.509 data + structure, the CertPrincipalName structure is to be used, with the + name-string encoded as a single UTF8String. The name-type should be + as identified in the original PrincipalName structure. The mapping + between the GeneralString and UTF8String formats can be found in + [19]. + + The following rules relate to the the matching of PrincipalNames (or + corresponding CertPrincipalNames) with regard to the PKI name + constraints for CAs as laid out in RFC 2459 [15]. In order to be + regarded as a match (for permitted and excluded name trees), the + following must be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a user plus instance plus realm name (as specified in + RFC 1510), the realm name must be valid (see 2.a-d below) + and the match must be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and must match exactly, byte for byte. + + b. Otherwise, if the realm contains an equal sign, it + is treated as an X.500 name. In order to match, every + component in the constraint MUST be in the principal + name, and have the same value. For example, 'C=US' + matches 'C=US/O=ISI' but not 'C=UK'. + + c. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + d. Otherwise, the realm name is invalid and does not match + under any conditions. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key shall be produced from the + agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [11] and + in [15] shall be used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [15]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [16]. + Currently, only PKCS#1 v1.5 is specified by CMS [11], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [11]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- Defined in CMS [11]; + -- AuthPack (below) defines the + -- data that is signed. + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- As defined in CMS [11]; + -- specifies a particular KDC + -- certificate if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field shall contain the OID value for + pkdata: iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) pkdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key + from the client's certificate to verify the signature in the + request. Note that the client may pass different certificate + chains that are used for signing or for encrypting. Thus, + the KDC may utilize a different client certificate for + signature verification than the one it uses to encrypt the + reply to the client. For example, the client may place a + Diffie-Hellman certificate in this field in order to convey + its static Diffie Hellman certificate to the KDC to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there must always be (at least) a signature certificate. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention as in RFC1510 + ctime [3] KerberosTime, + -- for replay prevention as in RFC1510 + nonce [4] INTEGER + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [10] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm ALGORITHM.&id, + parameters ALGORITHM.&type + } -- as specified by the X.509 recommendation [10] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510 revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, and + to bind the request and response. The PKAuthenticator is signed + with the client's signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Finally, if the certificate chain is verified, but the KDC's name + or realm as given in the PKAuthenticator does not match the KDC's + actual principal name, then the KDC returns an error of type + KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again + a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or + TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET + STRING whose data-value is the DER encoding of a PrincipalName or + Realm as defined in RFC 1510 revisions. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + mapping as necessary (e.g., as per RFC 2253 for X.500 + names). In this case the realm in the ticket shall be the + name of the certifier that issued the user's certificate. + + Note that a principal name may be carried in the subject alt name + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subject alt name may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension , that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [17], may utilize the email address. If the KDC + is presented with an S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be + canonicalized. If the resulting name does not correspond to a + registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by the client's CA (if in the + middle of a CA key roll-over, use the KDC cert issued under same + CA key as user cert used to verify request). + 3. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + + When the Diffie-Hellman option is used, dhSignedData in + PA-PK-AS-REP provides authenticated Diffie-Hellman parameters + of the KDC. The reply key used to encrypt part of the KDC reply + message is derived from the Diffie-Hellman exchange: + + 1. Both the KDC and the client calculate a secret value + (g^ab mod p), where a is the client's private exponent and + b is the KDC's private exponent. + + 2. Both the KDC and the client take the first N bits of this + secret value and convert it into a reply key. N depends on + the reply key type. + + 3. If the reply key is DES, N=64 bits, where some of the bits + are replaced with parity bits, according to FIPS PUB 74. + + 4. If the reply key is (3-key) 3-DES, N=192 bits, where some + of the bits are replaced with parity bits, according to + FIPS PUB 74. + + 5. The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field shall contain the OID value for + pkdata: iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) pkdata (1) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 6. The certificates field must contain the certificates + necessary for the client to establish trust in the KDC's + certificate based on the list of trusted certifiers sent by + the client in the PA-PK-AS-REQ. This field may be empty if + the client did not send to the KDC a list of trusted + certifiers (the trustedCertifiers field was empty, meaning + that the client already possesses the KDC's certificate). + + 7. The signerInfos field is a SET that must contain at least + one member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + Usage of EnvelopedData: + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which must contain exactly + one member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. The contentType field shall contain the OID value for + id-signedData: iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field must contains the + ReplyKeyPack. + + * The eContentType field shall contain the OID value + for pkdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdata (1) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. The certificates field must contain the certificates + necessary for the client to establish trust in the + KDC's certificate based on the list of trusted + certifiers sent by the client in the PA-PK-AS-REQ. + This field may be empty if the client did not send + to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the + client already possesses the KDC's certificate). + + iii. The signerInfos field is a SET that must contain at + least one member, since it contains the actual + signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain must be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + The KDC's certificate(s) must bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates shall contain the principal name of the KDC + (defined in section 8.2 of RFC 1510) as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, + as specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] OtherName, + ... + } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } + + For the purpose of specifying a Kerberos principal name, the value + in OtherName shall be a KerberosName as defined in RFC 1510, but with + the PrincipalName replaced by CertPrincipalName as mentioned in + Section 3.1: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + principalName [1] CertPrincipalName -- defined above + } + + This specific syntax is identified within subjectAltName by setting + the type-id in OtherName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510. + +3.2.3. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + * Diffie-Hellman public/private key pairs + * utilizing Diffie-Hellman ephemeral-ephemeral mode + * SHA1 digest and DSA for signatures + * 3-key triple DES keys derived from the Diffie-Hellman Exchange + * 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in the + limited capacity of self-signing their certificates, but one of the + additional benefits is to align Kerberos authentication with a global + public key infrastructure. Anyone using PKINIT in this way must be + aware of how the certification infrastructure they are linking to + works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt + + [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman. + Public Key Utilizing Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-02.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + + [19] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires September 15, 2000. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Ari Medvinsky + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + Phone +1 619 404 2825 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt new file mode 100644 index 0000000..b1e5968 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt @@ -0,0 +1,1080 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-12.txt Clifford Neuman +Updates: RFC 1510 USC/ISI +expires January 15, 2001 Matthew Hur + CyberSafe Corporation + Ari Medvinsky + Keen.com, Inc. + Sasha Medvinsky + Motorola + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15, + 2001. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with digital signature keys as the primary, required + mechanism. It also allows for the use of RSA keys and/or (static) + Diffie-Hellman certificates. Note in particular that PKINIT supports + the use of separate signature and encryption keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + secret key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], + anonymous Kerberos tickets can be issued by applying a NULL + signature in combination with Diffie-Hellman in the PKINIT exchange. + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a realm it will be represented using the "other" form of the realm + name as specified in the naming constraints section of RFC1510. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + <nametype> + ":" + <string> + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [14] (part of LDAPv3 [18]). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, in cases where the KDC does not provide a specific + policy based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name shall be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510 as: + + KRB_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm shall be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section + + RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + For the purposes of encoding an X.500 name as a Kerberos name for + use in Kerberos structures, the name-string shall be encoded as a + single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL, + as noted above. All Kerberos names must conform to validity + requirements as given in RFC 1510. Note that name mapping may be + required or optional, based on policy. + + We also define the following similar ASN.1 structure: + + CertPrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF UTF8String + } + + When a Kerberos PrincipalName is to be placed within an X.509 data + structure, the CertPrincipalName structure is to be used, with the + name-string encoded as a single UTF8String. The name-type should be + as identified in the original PrincipalName structure. The mapping + between the GeneralString and UTF8String formats can be found in + [19]. + + The following rules relate to the the matching of PrincipalNames (or + corresponding CertPrincipalNames) with regard to the PKI name + constraints for CAs as laid out in RFC 2459 [15]. In order to be + regarded as a match (for permitted and excluded name trees), the + following must be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a user plus instance plus realm name (as specified in + RFC 1510), the realm name must be valid (see 2.a-d below) + and the match must be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and must match exactly, byte for byte. + + b. Otherwise, if the realm contains an equal sign, it + is treated as an X.500 name. In order to match, every + component in the constraint MUST be in the principal + name, and have the same value. For example, 'C=US' + matches 'C=US/O=ISI' but not 'C=UK'. + + c. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + d. Otherwise, the realm name is invalid and does not match + under any conditions. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key shall be produced from the + agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [11] and + in [15] shall be used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [15]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [16]. + Currently, only PKCS#1 v1.5 is specified by CMS [11], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [11]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- Defined in CMS [11]; + -- AuthPack (below) defines the + -- data that is signed. + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- As defined in CMS [11]; + -- specifies a particular KDC + -- certificate if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field shall contain the OID value for + pkauthdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key + from the client's certificate to verify the signature in the + request. Note that the client may pass different certificate + chains that are used for signing or for encrypting. Thus, + the KDC may utilize a different client certificate for + signature verification than the one it uses to encrypt the + reply to the client. For example, the client may place a + Diffie-Hellman certificate in this field in order to convey + its static Diffie Hellman certificate to the KDC to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there must always be (at least) a signature certificate. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + -- for replay prevention as in RFC1510 + ctime [1] KerberosTime, + -- for replay prevention as in RFC1510 + nonce [2] INTEGER, + pachecksum [3] Checksum + -- Checksum over KDC-REQ-BODY + -- Defined by Kerberos spec + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [10] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + -- for dhKeyAgreement, this is + -- { iso (1) member-body (2) US (840) + -- rsadsi (113459) pkcs (1) 3 1 } + -- from PKCS #3 [20] + parameters ANY DEFINED by algorithm OPTIONAL + -- for dhKeyAgreement, this is + -- DHParameter + } -- as specified by the X.509 recommendation [10] + + DHParameter ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + -- l + } -- as defined in PKCS #3 [20] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510 revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, to + bind the pre-authentication data to the KDC-REQ-BODY, and to bind the + request and response. The PKAuthenticator is signed with the client's + signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Finally, if the certificate chain is verified, but the KDC's name + or realm as given in the PKAuthenticator does not match the KDC's + actual principal name, then the KDC returns an error of type + KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again + a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or + TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET + STRING whose data-value is the DER encoding of a PrincipalName or + Realm as defined in RFC 1510 revisions. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + mapping as necessary (e.g., as per RFC 2253 for X.500 + names). In this case the realm in the ticket shall be the + name of the certifier that issued the user's certificate. + + Note that a principal name may be carried in the subject alt name + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subject alt name may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension , that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [17], may utilize the email address. If the KDC + is presented with an S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be + canonicalized. If the resulting name does not correspond to a + registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by the client's CA (if in the + middle of a CA key roll-over, use the KDC cert issued under same + CA key as user cert used to verify request). + 3. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + + When the Diffie-Hellman option is used, dhSignedData in + PA-PK-AS-REP provides authenticated Diffie-Hellman parameters + of the KDC. The reply key used to encrypt part of the KDC reply + message is derived from the Diffie-Hellman exchange: + + 1. Both the KDC and the client calculate a secret value + (g^ab mod p), where a is the client's private exponent and + b is the KDC's private exponent. + + 2. Both the KDC and the client take the first N bits of this + secret value and convert it into a reply key. N depends on + the reply key type. + + 3. If the reply key is DES, N=64 bits, where some of the bits + are replaced with parity bits, according to FIPS PUB 74. + + 4. If the reply key is (3-key) 3-DES, N=192 bits, where some + of the bits are replaced with parity bits, according to + FIPS PUB 74. + + 5. The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field shall contain the OID value for + pkdhkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 6. The certificates field must contain the certificates + necessary for the client to establish trust in the KDC's + certificate based on the list of trusted certifiers sent by + the client in the PA-PK-AS-REQ. This field may be empty if + the client did not send to the KDC a list of trusted + certifiers (the trustedCertifiers field was empty, meaning + that the client already possesses the KDC's certificate). + + 7. The signerInfos field is a SET that must contain at least + one member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + Usage of EnvelopedData: + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which must contain exactly + one member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. The contentType field shall contain the OID value for + id-signedData: iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field must contains the + ReplyKeyPack. + + * The eContentType field shall contain the OID value + for pkrkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. The certificates field must contain the certificates + necessary for the client to establish trust in the + KDC's certificate based on the list of trusted + certifiers sent by the client in the PA-PK-AS-REQ. + This field may be empty if the client did not send + to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the + client already possesses the KDC's certificate). + + iii. The signerInfos field is a SET that must contain at + least one member, since it contains the actual + signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain must be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + The KDC's certificate(s) must bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates shall contain the principal name of the KDC + (defined in section 8.2 of RFC 1510) as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, + as specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] OtherName, + ... + } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } + + For the purpose of specifying a Kerberos principal name, the value + in OtherName shall be a KerberosName as defined in RFC 1510, but with + the PrincipalName replaced by CertPrincipalName as mentioned in + Section 3.1: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + principalName [1] CertPrincipalName -- defined above + } + + This specific syntax is identified within subjectAltName by setting + the type-id in OtherName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510. + +3.2.3. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + * Diffie-Hellman public/private key pairs + * utilizing Diffie-Hellman ephemeral-ephemeral mode + * SHA1 digest and DSA for signatures + * SHA1 digest also for the Checksum in the PKAuthenticator + * 3-key triple DES keys derived from the Diffie-Hellman Exchange + * 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in the + limited capacity of self-signing their certificates, but one of the + additional benefits is to align Kerberos authentication with a global + public key infrastructure. Anyone using PKINIT in this way must be + aware of how the certification infrastructure they are linking to + works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt + + [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman. + Public Key Utilizing Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-02.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + + [19] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + + [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA + Laboratories Technical Note, Version 1.4, Revised November 1, 1993. + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires January 15, 2001. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Ari Medvinsky + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + +1 858 404 2367 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt new file mode 100644 index 0000000..6581dd5 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt @@ -0,0 +1,378 @@ +INTERNET-DRAFT Ari Medvinsky +draft-ietf-cat-kerberos-pk-tapp-03.txt Keen.com, Inc. +Expires January 14, 2001 Matthew Hur +Informational CyberSafe Corporation + Sasha Medvinsky + Motorola + Clifford Neuman + USC/ISI + +Public Key Utilizing Tickets for Application Servers (PKTAPP) + + +0. Status Of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), +its areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six +months and may be updated, replaced, or obsoleted by other +documents at any time. It is inappropriate to use Internet-Drafts +as reference material or to cite them other than as "work in +progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +To learn the current status of any Internet-Draft, please check +the "1id-abstracts.txt" listing contained in the Internet-Drafts +Shadow Directories on ftp.ietf.org (US East Coast), +nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or +munnari.oz.au (Pacific Rim). + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, +2000. Please send comments to the authors. + +1. Abstract + +Public key based Kerberos for Distributed Authentication[1], (PKDA) +proposed by Sirbu & Chuang, describes PK based authentication that +eliminates the use of a centralized key distribution center while +retaining the advantages of Kerberos tickets. This draft describes how, +without any modification, the PKINIT specification[2] may be used to +implement the ideas introduced in PKDA. The benefit is that only a +single PK Kerberos extension is needed to address the goals of PKINIT & +PKDA. + + + +2. Introduction + +With the proliferation of public key cryptography, a number of public +key extensions to Kerberos have been proposed to provide +interoperability with the PK infrastructure and to improve the Kerberos +authentication system [4]. Among these are PKINIT[2] (under development +in the CAT working group) and more recently PKDA [1] proposed by Sirbu & +Chuang of CMU. One of the principal goals of PKINIT is to provide for +interoperability between a PK infrastructure and Kerberos. Using +PKINIT, a user can authenticate to the KDC via a public key certificate. +A ticket granting ticket (TGT), returned by the KDC, enables a PK user +to obtain tickets and authenticate to kerberized services. The PKDA +proposal goes a step further. It supports direct client to server +authentication, eliminating the need for an online key distribution +center. In this draft, we describe how, without any modification, the +PKINIT protocol may be applied to achieve the goals of PKDA. For direct +client to server authentication, the client will use PKINIT to +authenticate to the end server (instead of a central KDC), which then, +will issue a ticket for itself. The benefit of this proposal, is that a +single PK extension to Kerberos can addresses the goals of PKINIT and +PKDA. + + +3. PKDA background + +The PKDA proposal provides direct client to server authentication, thus +eliminating the need for an online key distribution center. A client +and server take part in an initial PK based authentication exchange, +with an added caveat that the server acts as a Kerberos ticket granting +service and issues a traditional Kerberos ticket for itself. In +subsequent communication, the client makes use of the Kerberos ticket, +thus eliminating the need for public key operations on the server. This +approach has an advantage over SSL in that the server does not need to +save state (cache session keys). Furthermore, an additional benefit, is +that Kerberos tickets can facilitate delegation (see Neuman[3]). + +Below is a brief overview of the PKDA protocol. For a more detailed +description see [1]. + +SCERT_REQ: Client to Server +The client requests a certificate from the server. If the serverÆs +certificate is cached locally, SCERT_REQ and SCERT_REP are omitted. + +SCERT_REP: Server to Client +The server returns its certificate to the client. + +PKTGS_REQ: Client to Server +The client sends a request for a service ticket to the server. To +authenticate the request, the client signs, among other fields, a time +stamp and a newly generated symmetric key . The time stamp is used to +foil replay attacks; the symmetric key is used by the server to secure +the PKTGS_REP message. +The client provides a certificate in the request (the certificate +enables the server to verify the validity of the clientÆs signature) and +seals it along with the signed information using the serverÆs public +key. + + +PKTGS_REP: Server to Client +The server returns a service ticket (which it issued for itself) along +with the session key for the ticket. The session key is protected by +the client-generated key from the PKTGS_REQ message. + +AP_REQ: Client to Server +After the above exchange, the client can proceed in a normal fashion, +using the conventional Kerberos ticket in an AP_REQ message. + + +4. PKINIT background + +One of the principal goals of PKINIT is to provide for interoperability +between a public key infrastructure and Kerberos. Using a public key +certificate, a client can authenticate to the KDC and receive a TGT +which enables the client to obtain service tickets to kerberized +services.. In PKINIT, the AS-REQ and AS-REP messages remain the same; +new preauthentication data types are used to conduct the PK exchange. +Client and server certificates are exchanged via the preauthentication +data. Thus, the exchange of certificates , PK authentication, and +delivery of a TGT can occur in two messages. + +Below is a brief overview of the PKINIT protocol. For a more detailed +description see [2]. + +PreAuthentication data of AS-REQ: Client to Server +The client sends a list of trusted certifiers, a signed PK +authenticator, and its certificate. The PK authenticator, based on the +Kerberos authenticator, contains the name of the KDC, a timestamp, and a +nonce. + +PreAuthentication data of AS-REP: Server to Client +The server responds with its certificate and the key used for decrypting +the encrypted part of the AS-REQ. This key is encrypted with the +clientÆs public key. + +AP_REQ: Client to Server +After the above exchange, the client can proceed in a normal fashion, +using the conventional Kerberos ticket in an AP_REQ message. + + +5. Application of PKINIT to achieve equivalence to PKDA + +While PKINIT is normally used to retrieve a ticket granting ticket +(TGT), it may also be used to request an end service ticket. When used +in this fashion, PKINIT is functionally equivalent to PKDA. We +introduce the concept of a local ticket granting server (LTGS) to +illustrate how PKINIT may be used for issuing end service tickets based +on public key authentication. It is important to note that the LTGS may +be built into an application server, or it may be a stand-alone server +used for issuing tickets within a well-defined realm, such as a single +machine. We will discuss both of these options. + + +5.1. The LTGS + +The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT +preauthentication data. When a client submits an AS-REQ to the LTGS, it +specifies an application server, in order to receive an end service +ticket instead of a TGT. + + +5.1.1. The LTGS as a standalone server + +The LTGS may run as a separate process that serves applications which +reside on the same machine. This serves to consolidate administrative +functions and provide an easier migration path for a heterogeneous +environment consisting of both public key and Kerberos. The LTGS would +use one well-known port (port #88 - same as the KDC) for all message +traffic and would share a symmetric with each service. After the client +receives a service ticket, it then contacts the application server +directly. This approach is similar to the one suggested by Sirbu , et +al [1]. + +5.1.1.1. Ticket Policy for PKTAPP Clients + +It is desirable for the LTGS to have access to a PKTAPP client ticket +policy. This policy will contain information for each client, such as +the maximum lifetime of a ticket, whether or not a ticket can be +forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for +authentication and are not required to be registered as Kerberos +principals. + +As one possible solution, each public key Certification Authority could +be registered in a secure database, along with the ticket policy +information for all PKTAPP clients that are certified by this +Certification Authority. + +5.1.1.2. LTGS as a Kerberos Principal + +Since the LTGS serves only PKTAPP clients and returns only end service +tickets for other services, it does not require a Kerberos service key +or a Kerberos principal identity. It is therefore not necessary for the +LTGS to even be registered as a Kerberos principal. + +The LTGS still requires public key credentials for the PKINIT exchange, +and it may be desired to have some global restrictions on the Kerberos +tickets that it can issue. It is recommended (but not required) that +this information be associated with a Kerberos principal entry for the +LTGS. + + +5.1.1.3. Kerberos Principal Database + +Since the LTGS issues tickets for Kerberos services, it will require +access to a Kerberos principal database containing entries for at least +the end services. Each entry must contain a service key and may also +contain restrictions on the service tickets that are issued to clients. +It is recommended that (for ease of administration) this principal +database be centrally administered and distributed (replicated) to all +hosts where an LTGS may be running. + +In the case that there are other clients that do not support PKINIT +protocol, but still need access to the same Kerberos services, this +principal database will also require entries for Kerberos clients and +for the TGS entries. + +5.1.2. The LTGS as part of an application server + +The LTGS may be combined with an application server. This accomplishes +direct client to application server authentication; however, it requires +that applications be modified to process AS-REQ and AS-REP messages. +The LTGS would communicate over the port assigned to the application +server or over the well known Kerberos port for that particular +application. + +5.1.2.2. Ticket Policy for PKTAPP Clients + +Application servers normally do not have access to a distributed +principal database. Therefore, they will have to find another means of +keeping track of the ticket policy information for PKTAPP clients. It is +recommended that this ticket policy be kept in a directory service (such +as LDAP). + +It is critical, however, that both read and write access to this ticket +policy is restricted with strong authentication and encryption to only +the correct application server. An unauthorized party should not have +the authority to modify the ticket policy. Disclosing the ticket policy +to a 3rd party may aid an adversary in determining the best way to +compromise the network. + +It is just as critical for the application server to authenticate the +directory service. Otherwise an adversary could use a man-in-the-middle +attack to substitute a false ticket policy with a false directory +service. + +5.1.2.3. LTGS Credentials + +Each LTGS (combined with an application service) will require public key +credentials in order to use the PKINIT protocol. These credentials can +be stored in a single file that is both encrypted with a password- +derived symmetric key and also secured by an operating system. This +symmetric key may be stashed somewhere on the machine for convenience, +although such practice potentially weakens the overall system security +and is strongly discouraged. + +For added security, it is recommended that the LTGS private keys are +stored inside a temper-resistant hardware module that requires a pin +code for access. + + +5.1.2.4. Compatibility With Standard Kerberos + +Even though an application server is combined with the LTGS, for +backward compatibility it should still accept service tickets that have +been issued by the KDC. This will allow Kerberos clients that do not +support PKTAPP to authenticate to the same application server (with the +help of a KDC). + +5.1.3. Cross-Realm Authentication + +According to the PKINIT draft, the client's realm is the X.500 name of +the Certification Authority that issued the client certificate. A +Kerberos application service will be in a standard Kerberos realm, which +implies that the LTGS will need to issue cross-realm end service +tickets. This is the only case, where cross-realm end service tickets +are issued. In a standard Kerberos model, a client first acquires a +cross-realm TGT, and then gets an end service ticket from the KDC that +is in the same realm as the application service. + +6. Protocol differences between PKINIT and PKDA + +Both PKINIT and PKDA will accomplish the same goal of issuing end +service tickets, based on initial public key authentication. A PKINIT- +based implementation and a PKDA implementation would be functionally +equivalent. The primary differences are that 1)PKDA requires the client +to create the symmetric key while PKINIT requires the server to create +the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes +in four messages. + +7. Summary + +The PKINIT protocol can be used, without modification to facilitate +client to server authentication without the use of a central KDC. The +approach described in this draft (and originally proposed in PKDA[1]) +is essentially a public key authentication protocol that retains the +advantages of Kerberos tickets. + +Given that PKINIT has progressed through the CAT working group of the +IETF, with plans for non-commercial distribution (via MITÆs v5 Kerberos) +as well as commercial support, it is worthwhile to provide PKDA +functionality, under the PKINIT umbrella. + +8. Security Considerations + +PKTAPP is based on the PKINIT protocol and all security considerations +already listed in [2] apply here. + +When the LTGS is implemented as part of each application server, the +secure storage of its public key credentials and of its ticket policy +are both a concern. The respective security considerations are already +covered in sections 5.1.2.3 and 5.1.2.2 of this document. + + +9. Bibliography + +[1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using +Public Key Cryptography. Symposium On Network and Distributed System +Security, 1997. + +[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, +J. Trostle. Public Key Cryptography for Initial Authentication in +Kerberos. Internet Draft, October 1999. +(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt) + +[3] C. Neuman, Proxy-Based Authorization and Accounting for +Distributed Systems. In Proceedings of the 13th International +Conference on Distributed Computing Systems, May 1993. + +[4] J. Kohl, C. Neuman. The Kerberos Network Authentication Service +(V5). Request for Comments 1510. + +10. Expiration Date + +This draft expires April 24, 2000. + +11. Authors + +Ari Medvinsky +Keen.com, Inc. +150 Independence Dr. +Menlo Park, CA 94025 +Phone +1 650 289 3134 +E-mail: ari@keen.com + +Matthew Hur +CyberSafe Corporation +1605 NW Sammamish Road +Issaquah, WA 98027-5378 +Phone: +1 425 391 6000 +E-mail: matt.hur@cybersafe.com + +Alexander Medvinsky +Motorola +6450 Sequence Dr. +San Diego, CA 92121 +Phone: +1 858 404 2367 +E-mail: smedvinsky@gi.com + +Clifford Neuman +USC Information Sciences Institute +4676 Admiralty Way Suite 1001 +Marina del Rey CA 90292-6695 +Phone: +1 310 822 1511 +E-mail: bcn@isi.edu diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt new file mode 100644 index 0000000..1592124 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt @@ -0,0 +1,6866 @@ +INTERNET-DRAFT Clifford Neuman + John Kohl + Theodore Ts'o + March 10, 2000 + Expires September 10, 2000 + +The Kerberos Network Authentication Service (V5) +draft-ietf-cat-kerberos-revisions-05.txt + +STATUS OF THIS MEMO + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC 2026. Internet-Drafts are working documents +of the Internet Engineering Task Force (IETF), its areas, and its working +groups. Note that other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months and +may be updated, replaced, or obsoleted by other documents at any time. It is +inappropriate to use Internet-Drafts as reference material or to cite them +other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +To learn the current status of any Internet-Draft, please check the +"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow +Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), +ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-revisions-05.txt, and expires September 10, 2000. +Please send comments to: krb-protocol@MIT.EDU + +ABSTRACT + +This document provides an overview and specification of Version 5 of the +Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol +and its intended use that require more detailed or clearer explanation than +was provided in RFC1510. This document is intended to provide a detailed +description of the protocol, suitable for implementation, together with +descriptions of the appropriate use of protocol messages and fields within +those messages. + +This document is not intended to describe Kerberos to the end user, system +administrator, or application developer. Higher level papers describing +Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], +are available elsewhere. + +OVERVIEW + +This INTERNET-DRAFT describes the concepts and model upon which the Kerberos +network authentication system is based. It also specifies Version 5 of the +Kerberos protocol. + +The motivations, goals, assumptions, and rationale behind most design +decisions are treated cursorily; they are more fully described in a paper + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +available in IEEE communications [NT94] and earlier in the Kerberos portion +of the Athena Technical Plan [MNSS87]. The protocols have been a proposed +standard and are being considered for advancement for draft standard through +the IETF standard process. Comments are encouraged on the presentation, but +only minor refinements to the protocol as implemented or extensions that fit +within current protocol framework will be considered at this time. + +Requests for addition to an electronic mailing list for discussion of +Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. +This mailing list is gatewayed onto the Usenet as the group +comp.protocols.kerberos. Requests for further information, including +documents and code availability, may be sent to info-kerberos@MIT.EDU. + +BACKGROUND + +The Kerberos model is based in part on Needham and Schroeder's trusted +third-party authentication protocol [NS78] and on modifications suggested by +Denning and Sacco [DS81]. The original design and implementation of Kerberos +Versions 1 through 4 was the work of two former Project Athena staff +members, Steve Miller of Digital Equipment Corporation and Clifford Neuman +(now at the Information Sciences Institute of the University of Southern +California), along with Jerome Saltzer, Technical Director of Project +Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members +of Project Athena have also contributed to the work on Kerberos. + +Version 5 of the Kerberos protocol (described in this document) has evolved +from Version 4 based on new requirements and desires for features not +available in Version 4. The design of Version 5 of the Kerberos protocol was +led by Clifford Neuman and John Kohl with much input from the community. The +development of the MIT reference implementation was led at MIT by John Kohl +and Theodore T'so, with help and contributed code from many others. Since +RFC1510 was issued, extensions and revisions to the protocol have been +proposed by many individuals. Some of these proposals are reflected in this +document. Where such changes involved significant effort, the document cites +the contribution of the proposer. + +Reference implementations of both version 4 and version 5 of Kerberos are +publicly available and commercial implementations have been developed and +are widely used. Details on the differences between Kerberos Versions 4 and +5 can be found in [KNT92]. + +1. Introduction + +Kerberos provides a means of verifying the identities of principals, (e.g. a +workstation user or a network server) on an open (unprotected) network. This +is accomplished without relying on assertions by the host operating system, +without basing trust on host addresses, without requiring physical security +of all the hosts on the network, and under the assumption that packets +traveling along the network can be read, modified, and inserted at will[1]. +Kerberos performs authentication under these conditions as a trusted +third-party authentication service by using conventional (shared secret key +[2] cryptography. Kerberos extensions have been proposed and implemented +that provide for the use of public key cryptography during certain phases of +the authentication protocol. These extensions provide for authentication of +users registered with public key certification authorities, and allow the +system to provide certain benefits of public key cryptography in situations +where they are needed. + +The basic Kerberos authentication process proceeds as follows: A client + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +sends a request to the authentication server (AS) requesting 'credentials' +for a given server. The AS responds with these credentials, encrypted in the +client's key. The credentials consist of 1) a 'ticket' for the server and 2) +a temporary encryption key (often called a "session key"). The client +transmits the ticket (which contains the client's identity and a copy of the +session key, all encrypted in the server's key) to the server. The session +key (now shared by the client and server) is used to authenticate the +client, and may optionally be used to authenticate the server. It may also +be used to encrypt further communication between the two parties or to +exchange a separate sub-session key to be used to encrypt further +communication. + +Implementation of the basic protocol consists of one or more authentication +servers running on physically secure hosts. The authentication servers +maintain a database of principals (i.e., users and servers) and their secret +keys. Code libraries provide encryption and implement the Kerberos protocol. +In order to add authentication to its transactions, a typical network +application adds one or two calls to the Kerberos library directly or +through the Generic Security Services Application Programming Interface, +GSSAPI, described in separate document. These calls result in the +transmission of the necessary messages to achieve authentication. + +The Kerberos protocol consists of several sub-protocols (or exchanges). +There are two basic methods by which a client can ask a Kerberos server for +credentials. In the first approach, the client sends a cleartext request for +a ticket for the desired server to the AS. The reply is sent encrypted in +the client's secret key. Usually this request is for a ticket-granting +ticket (TGT) which can later be used with the ticket-granting server (TGS). +In the second method, the client sends a request to the TGS. The client uses +the TGT to authenticate itself to the TGS in the same manner as if it were +contacting any other application server that requires Kerberos +authentication. The reply is encrypted in the session key from the TGT. +Though the protocol specification describes the AS and the TGS as separate +servers, they are implemented in practice as different protocol entry points +within a single Kerberos server. + +Once obtained, credentials may be used to verify the identity of the +principals in a transaction, to ensure the integrity of messages exchanged +between them, or to preserve privacy of the messages. The application is +free to choose whatever protection may be necessary. + +To verify the identities of the principals in a transaction, the client +transmits the ticket to the application server. Since the ticket is sent "in +the clear" (parts of it are encrypted, but this encryption doesn't thwart +replay) and might be intercepted and reused by an attacker, additional +information is sent to prove that the message originated with the principal +to whom the ticket was issued. This information (called the authenticator) +is encrypted in the session key, and includes a timestamp. The timestamp +proves that the message was recently generated and is not a replay. +Encrypting the authenticator in the session key proves that it was generated +by a party possessing the session key. Since no one except the requesting +principal and the server know the session key (it is never sent over the +network in the clear) this guarantees the identity of the client. + +The integrity of the messages exchanged between principals can also be +guaranteed using the session key (passed in the ticket and contained in the +credentials). This approach provides detection of both replay attacks and +message stream modification attacks. It is accomplished by generating and +transmitting a collision-proof checksum (elsewhere called a hash or digest + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +function) of the client's message, keyed with the session key. Privacy and +integrity of the messages exchanged between principals can be secured by +encrypting the data to be passed using the session key contained in the +ticket or the subsession key found in the authenticator. + +The authentication exchanges mentioned above require read-only access to the +Kerberos database. Sometimes, however, the entries in the database must be +modified, such as when adding new principals or changing a principal's key. +This is done using a protocol between a client and a third Kerberos server, +the Kerberos Administration Server (KADM). There is also a protocol for +maintaining multiple copies of the Kerberos database. Neither of these +protocols are described in this document. + +1.1. Cross-Realm Operation + +The Kerberos protocol is designed to operate across organizational +boundaries. A client in one organization can be authenticated to a server in +another. Each organization wishing to run a Kerberos server establishes its +own 'realm'. The name of the realm in which a client is registered is part +of the client's name, and can be used by the end-service to decide whether +to honor a request. + +By establishing 'inter-realm' keys, the administrators of two realms can +allow a client authenticated in the local realm to prove its identity to +servers in other realms[3]. The exchange of inter-realm keys (a separate key +may be used for each direction) registers the ticket-granting service of +each realm as a principal in the other realm. A client is then able to +obtain a ticket-granting ticket for the remote realm's ticket-granting +service from its local realm. When that ticket-granting ticket is used, the +remote ticket-granting service uses the inter-realm key (which usually +differs from its own normal TGS key) to decrypt the ticket-granting ticket, +and is thus certain that it was issued by the client's own TGS. Tickets +issued by the remote ticket-granting service will indicate to the +end-service that the client was authenticated from another realm. + +A realm is said to communicate with another realm if the two realms share an +inter-realm key, or if the local realm shares an inter-realm key with an +intermediate realm that communicates with the remote realm. An +authentication path is the sequence of intermediate realms that are +transited in communicating from one realm to another. + +Realms are typically organized hierarchically. Each realm shares a key with +its parent and a different key with each child. If an inter-realm key is not +directly shared by two realms, the hierarchical organization allows an +authentication path to be easily constructed. If a hierarchical organization +is not used, it may be necessary to consult a database in order to construct +an authentication path between realms. + +Although realms are typically hierarchical, intermediate realms may be +bypassed to achieve cross-realm authentication through alternate +authentication paths (these might be established to make communication +between two realms more efficient). It is important for the end-service to +know which realms were transited when deciding how much faith to place in +the authentication process. To facilitate this decision, a field in each +ticket contains the names of the realms that were involved in authenticating +the client. + +The application server is ultimately responsible for accepting or rejecting +authentication and should check the transited field. The application server + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +may choose to rely on the KDC for the application server's realm to check +the transited field. The application server's KDC will set the +TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate +realms may also check the transited field as they issue +ticket-granting-tickets for other realms, but they are encouraged not to do +so. A client may request that the KDC's not check the transited field by +setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not +required to honor this flag. + +1.2. Authorization + +As an authentication service, Kerberos provides a means of verifying the +identity of principals on a network. Authentication is usually useful +primarily as a first step in the process of authorization, determining +whether a client may use a service, which objects the client is allowed to +access, and the type of access allowed for each. Kerberos does not, by +itself, provide authorization. Possession of a client ticket for a service +provides only for authentication of the client to that service, and in the +absence of a separate authorization procedure, it should not be considered +by an application as authorizing the use of that service. + +Such separate authorization methods may be implemented as application +specific access control functions and may be based on files such as the +application server, or on separately issued authorization credentials such +as those based on proxies [Neu93], or on other authorization services. +Separately authenticated authorization credentials may be embedded in a +tickets authorization data when encapsulated by the kdc-issued authorization +data element. + +Applications should not be modified to accept the mere issuance of a service +ticket by the Kerberos server (even by a modified Kerberos server) as +granting authority to use the service, since such applications may become +vulnerable to the bypass of this authorization check in an environment if +they interoperate with other KDCs or where other options for application +authentication (e.g. the PKTAPP proposal) are provided. + +1.3. Environmental assumptions + +Kerberos imposes a few assumptions on the environment in which it can +properly function: + + * 'Denial of service' attacks are not solved with Kerberos. There are + places in these protocols where an intruder can prevent an application + from participating in the proper authentication steps. Detection and + solution of such attacks (some of which can appear to be nnot-uncommon + 'normal' failure modes for the system) is usually best left to the + human administrators and users. + * Principals must keep their secret keys secret. If an intruder somehow + steals a principal's key, it will be able to masquerade as that + principal or impersonate any server to the legitimate principal. + * 'Password guessing' attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to successfully + mount an offline dictionary attack by repeatedly attempting to decrypt, + with successive entries from a dictionary, messages obtained which are + encrypted under a key derived from the user's password. + * Each host on the network must have a clock which is 'loosely + synchronized' to the time of the other hosts; this synchronization is + used to reduce the bookkeeping needs of application servers when they + do replay detection. The degree of "looseness" can be configured on a + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + per-server basis, but is typically on the order of 5 minutes. If the + clocks are synchronized over the network, the clock synchronization + protocol must itself be secured from network attackers. + * Principal identifiers are not recycled on a short-term basis. A typical + mode of access control will use access control lists (ACLs) to grant + permissions to particular principals. If a stale ACL entry remains for + a deleted principal and the principal identifier is reused, the new + principal will inherit rights specified in the stale ACL entry. By not + re-using principal identifiers, the danger of inadvertent access is + removed. + +1.4. Glossary of terms + +Below is a list of terms used throughout this document. + +Authentication + Verifying the claimed identity of a principal. +Authentication header + A record containing a Ticket and an Authenticator to be presented to a + server as part of the authentication process. +Authentication path + A sequence of intermediate realms transited in the authentication + process when communicating from one realm to another. +Authenticator + A record containing information that can be shown to have been recently + generated using the session key known only by the client and server. +Authorization + The process of determining whether a client may use a service, which + objects the client is allowed to access, and the type of access allowed + for each. +Capability + A token that grants the bearer permission to access an object or + service. In Kerberos, this might be a ticket whose use is restricted by + the contents of the authorization data field, but which lists no + network addresses, together with the session key necessary to use the + ticket. +Ciphertext + The output of an encryption function. Encryption transforms plaintext + into ciphertext. +Client + A process that makes use of a network service on behalf of a user. Note + that in some cases a Server may itself be a client of some other server + (e.g. a print server may be a client of a file server). +Credentials + A ticket plus the secret session key necessary to successfully use that + ticket in an authentication exchange. +KDC + Key Distribution Center, a network service that supplies tickets and + temporary session keys; or an instance of that service or the host on + which it runs. The KDC services both initial ticket and ticket-granting + ticket requests. The initial ticket portion is sometimes referred to as + the Authentication Server (or service). The ticket-granting ticket + portion is sometimes referred to as the ticket-granting server (or + service). +Kerberos + Aside from the 3-headed dog guarding Hades, the name given to Project + Athena's authentication service, the protocol used by that service, or + the code used to implement the authentication service. +Plaintext + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The input to an encryption function or the output of a decryption + function. Decryption transforms ciphertext into plaintext. +Principal + A uniquely named client or server instance that participates in a + network communication. +Principal identifier + The name used to uniquely identify each different principal. +Seal + To encipher a record containing several fields in such a way that the + fields cannot be individually replaced without either knowledge of the + encryption key or leaving evidence of tampering. +Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the case of + a human user's principal, the secret key is derived from a password. +Server + A particular Principal which provides a resource to network clients. + The server is sometimes refered to as the Application Server. +Service + A resource provided to network clients; often provided by more than one + server (for example, remote file service). +Session key + A temporary encryption key used between two principals, with a lifetime + limited to the duration of a single login "session". +Sub-session key + A temporary encryption key used between two principals, selected and + exchanged by the principals using the session key, and with a lifetime + limited to the duration of a single association. +Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and other + information, all sealed using the server's secret key. It only serves + to authenticate a client when presented along with a fresh + Authenticator. + +2. Ticket flag uses and requests + +Each Kerberos ticket contains a set of flags which are used to indicate +various attributes of that ticket. Most flags may be requested by a client +when the ticket is obtained; some are automatically turned on and off by a +Kerberos server as required. The following sections explain what the various +flags mean, and gives examples of reasons to use such a flag. + +2.1. Initial and pre-authenticated tickets + +The INITIAL flag indicates that a ticket was issued using the AS protocol +and not issued based on a ticket-granting ticket. Application servers that +want to require the demonstrated knowledge of a client's secret key (e.g. a +password-changing program) can insist that this flag be set in any tickets +they accept, and thus be assured that the client's key was recently +presented to the application client. + +The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the +initial authentication, regardless of whether the current ticket was issued +directly (in which case INITIAL will also be set) or issued on the basis of +a ticket-granting ticket (in which case the INITIAL flag is clear, but the +PRE-AUTHENT and HW-AUTHENT flags are carried forward from the +ticket-granting ticket). + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +2.2. Invalid tickets + +The INVALID flag indicates that a ticket is invalid. Application servers +must reject tickets which have this flag set. A postdated ticket will +usually be issued in this form. Invalid tickets must be validated by the KDC +before use, by presenting them to the KDC in a TGS request with the VALIDATE +option specified. The KDC will only validate tickets after their starttime +has passed. The validation is required so that postdated tickets which have +been stolen before their starttime can be rendered permanently invalid +(through a hot-list mechanism) (see section 3.3.3.1). + +2.3. Renewable tickets + +Applications may desire to hold tickets which can be valid for long periods +of time. However, this can expose their credentials to potential theft for +equally long periods, and those stolen credentials would be valid until the +expiration time of the ticket(s). Simply using short-lived tickets and +obtaining new ones periodically would require the client to have long-term +access to its secret key, an even greater risk. Renewable tickets can be +used to mitigate the consequences of theft. Renewable tickets have two +"expiration times": the first is when the current instance of the ticket +expires, and the second is the latest permissible value for an individual +expiration time. An application client must periodically (i.e. before it +expires) present a renewable ticket to the KDC, with the RENEW option set in +the KDC request. The KDC will issue a new ticket with a new session key and +a later expiration time. All other fields of the ticket are left unmodified +by the renewal process. When the latest permissible expiration time arrives, +the ticket expires permanently. At each renewal, the KDC may consult a +hot-list to determine if the ticket had been reported stolen since its last +renewal; it will refuse to renew such stolen tickets, and thus the usable +lifetime of stolen tickets is reduced. + +The RENEWABLE flag in a ticket is normally only interpreted by the +ticket-granting service (discussed below in section 3.3). It can usually be +ignored by application servers. However, some particularly careful +application servers may wish to disallow renewable tickets. + +If a renewable ticket is not renewed by its expiration time, the KDC will +not renew the ticket. The RENEWABLE flag is reset by default, but a client +may request it be set by setting the RENEWABLE option in the KRB_AS_REQ +message. If it is set, then the renew-till field in the ticket contains the +time after which the ticket may not be renewed. + +2.4. Postdated tickets + +Applications may occasionally need to obtain tickets for use much later, +e.g. a batch submission system would need tickets to be valid at the time +the batch job is serviced. However, it is dangerous to hold valid tickets in +a batch queue, since they will be on-line longer and more prone to theft. +Postdated tickets provide a way to obtain these tickets from the KDC at job +submission time, but to leave them "dormant" until they are activated and +validated by a further request of the KDC. If a ticket theft were reported +in the interim, the KDC would refuse to validate the ticket, and the thief +would be foiled. + +The MAY-POSTDATE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. This flag +must be set in a ticket-granting ticket in order to issue a postdated ticket +based on the presented ticket. It is reset by default; it may be requested + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. +This flag does not allow a client to obtain a postdated ticket-granting +ticket; postdated ticket-granting tickets can only by obtained by requesting +the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a +postdated ticket will be the remaining life of the ticket-granting ticket at +the time of the request, unless the RENEWABLE option is also set, in which +case it can be the full life (endtime-starttime) of the ticket-granting +ticket. The KDC may limit how far in the future a ticket may be postdated. + +The POSTDATED flag indicates that a ticket has been postdated. The +application server can check the authtime field in the ticket to see when +the original authentication occurred. Some services may choose to reject +postdated tickets, or they may only accept them within a certain period +after the original authentication. When the KDC issues a POSTDATED ticket, +it will also be marked as INVALID, so that the application client must +present the ticket to the KDC to be validated before use. + +2.5. Proxiable and proxy tickets + +At times it may be necessary for a principal to allow a service to perform +an operation on its behalf. The service must be able to take on the identity +of the client, but only for a particular purpose. A principal can allow a +service to take on the principal's identity for a particular purpose by +granting it a proxy. + +The process of granting a proxy using the proxy and proxiable flags is used +to provide credentials for use with specific services. Though conceptually +also a proxy, user's wishing to delegate their identity for ANY purpose must +use the ticket forwarding mechanism described in the next section to forward +a ticket granting ticket. + +The PROXIABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. When set, +this flag tells the ticket-granting server that it is OK to issue a new +ticket (but not a ticket-granting ticket) with a different network address +based on this ticket. This flag is set if requested by the client on initial +authentication. By default, the client will request that it be set when +requesting a ticket granting ticket, and reset when requesting any other +ticket. + +This flag allows a client to pass a proxy to a server to perform a remote +request on its behalf, e.g. a print service client can give the print server +a proxy to access the client's files on a particular file server in order to +satisfy a print request. + +In order to complicate the use of stolen credentials, Kerberos tickets are +usually valid from only those network addresses specifically included in the +ticket[4]. When granting a proxy, the client must specify the new network +address from which the proxy is to be used, or indicate that the proxy is to +be issued for use from any address. + +The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. +Application servers may check this flag and at their option they may require +additional authentication from the agent presenting the proxy in order to +provide an audit trail. + +2.6. Forwardable tickets + +Authentication forwarding is an instance of a proxy where the service is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +granted complete use of the client's identity. An example where it might be +used is when a user logs in to a remote system and wants authentication to +work from that system as if the login were local. + +The FORWARDABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. The +FORWARDABLE flag has an interpretation similar to that of the PROXIABLE +flag, except ticket-granting tickets may also be issued with different +network addresses. This flag is reset by default, but users may request that +it be set by setting the FORWARDABLE option in the AS request when they +request their initial ticket- granting ticket. + +This flag allows for authentication forwarding without requiring the user to +enter a password again. If the flag is not set, then authentication +forwarding is not permitted, but the same result can still be achieved if +the user engages in the AS exchange specifying the requested network +addresses and supplies a password. + +The FORWARDED flag is set by the TGS when a client presents a ticket with +the FORWARDABLE flag set and requests a forwarded ticket by specifying the +FORWARDED KDC option and supplying a set of addresses for the new ticket. It +is also set in all tickets issued based on tickets with the FORWARDED flag +set. Application servers may choose to process FORWARDED tickets differently +than non-FORWARDED tickets. + +2.7. Other KDC options + +There are two additional options which may be set in a client's request of +the KDC. The RENEWABLE-OK option indicates that the client will accept a +renewable ticket if a ticket with the requested life cannot otherwise be +provided. If a ticket with the requested life cannot be provided, then the +KDC may issue a renewable ticket with a renew-till equal to the the +requested endtime. The value of the renew-till field may still be adjusted +by site-determined limits or limits imposed by the individual principal or +server. + +The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. +It indicates that the ticket to be issued for the end server is to be +encrypted in the session key from the a additional second ticket-granting +ticket provided with the request. See section 3.3.3 for specific details. + +3. Message Exchanges + +The following sections describe the interactions between network clients and +servers and the messages involved in those exchanges. + +3.1. The Authentication Service Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_AS_REQ 5.4.1 + 2. Kerberos to client KRB_AS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The Authentication Service (AS) Exchange between the client and the Kerberos +Authentication Server is initiated by a client when it wishes to obtain +authentication credentials for a given server but currently holds no +credentials. In its basic form, the client's secret key is used for +encryption and decryption. This exchange is typically used at the initiation + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +of a login session to obtain credentials for a Ticket-Granting Server which +will subsequently be used to obtain credentials for other servers (see +section 3.3) without requiring further use of the client's secret key. This +exchange is also used to request credentials for services which must not be +mediated through the Ticket-Granting Service, but rather require a +principal's secret key, such as the password-changing service[5]. This +exchange does not by itself provide any assurance of the the identity of the +user[6]. + +The exchange consists of two messages: KRB_AS_REQ from the client to +Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these +messages are described in sections 5.4.1, 5.4.2, and 5.9.1. + +In the request, the client sends (in cleartext) its own identity and the +identity of the server for which it is requesting credentials. The response, +KRB_AS_REP, contains a ticket for the client to present to the server, and a +session key that will be shared by the client and the server. The session +key and additional information are encrypted in the client's secret key. The +KRB_AS_REP message contains information which can be used to detect replays, +and to associate it with the message to which it replies. Various errors can +occur; these are indicated by an error response (KRB_ERROR) instead of the +KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR +message contains information which can be used to associate it with the +message to which it replies. The lack of encryption in the KRB_ERROR message +precludes the ability to detect replays, fabrications, or modifications of +such messages. + +Without preautentication, the authentication server does not know whether +the client is actually the principal named in the request. It simply sends a +reply without knowing or caring whether they are the same. This is +acceptable because nobody but the principal whose identity was given in the +request will be able to use the reply. Its critical information is encrypted +in that principal's key. The initial request supports an optional field that +can be used to pass additional information that might be needed for the +initial exchange. This field may be used for preauthentication as described +in section [hl<>]. + +3.1.1. Generation of KRB_AS_REQ message + +The client may specify a number of options in the initial request. Among +these options are whether pre-authentication is to be performed; whether the +requested ticket is to be renewable, proxiable, or forwardable; whether it +should be postdated or allow postdating of derivative tickets; and whether a +renewable ticket will be accepted in lieu of a non-renewable ticket if the +requested ticket expiration date cannot be satisfied by a non-renewable +ticket (due to configuration constraints; see section 4). See section A.1 +for pseudocode. + +The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ message + +If all goes well, processing the KRB_AS_REQ message will result in the +creation of a ticket for the client to present to the server. The format for +the ticket is described in section 5.3.1. The contents of the ticket are +determined as follows. + +3.1.3. Generation of KRB_AS_REP message + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +The authentication server looks up the client and server principals named in +the KRB_AS_REQ in its database, extracting their respective keys. If +required, the server pre-authenticates the request, and if the +pre-authentication check fails, an error message with the code +KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the +requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP +is returned. Otherwise it generates a 'random' session key[7]. + +If there are multiple encryption keys registered for a client in the +Kerberos database (or if the key registered supports multiple encryption +types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS +request is used by the KDC to select the encryption method to be used for +encrypting the response to the client. If there is more than one supported, +strong encryption type in the etype list, the first valid etype for which an +encryption key is available is used. The encryption method used to respond +to a TGS request is taken from the keytype of the session key found in the +ticket granting ticket. [***I will change the example keytypes to be 3DES +based examples 7/14***] + +When the etype field is present in a KDC request, whether an AS or TGS +request, the KDC will attempt to assign the type of the random session key +from the list of methods in the etype field. The KDC will select the +appropriate type using the list of methods provided together with +information from the Kerberos database indicating acceptable encryption +methods for the application server. The KDC will not issue tickets with a +weak session key encryption type. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise +the requested start time is checked against the policy of the local realm +(the administrator might decide to prohibit certain types or ranges of +postdated tickets), and if acceptable, the ticket's start time is set as +requested and the INVALID flag is set in the new ticket. The postdated +ticket must be validated before use by presenting it to the KDC after the +start time has been reached. + +The expiration time of the ticket will be set to the minimum of the +following: + + * The expiration time (endtime) requested in the KRB_AS_REQ message. + * The ticket's start time plus the maximum allowable lifetime associated + with the client principal (the authentication server's database + includes a maximum ticket lifetime field in each principal's record; + see section 4). + * The ticket's start time plus the maximum allowable lifetime associated + with the server principal. + * The ticket's start time plus the maximum lifetime set by the policy of + the local realm. + +If the requested expiration time minus the start time (as determined above) +is less than a site-determined minimum lifetime, an error message with code +KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the +ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' +option was requested, then the 'RENEWABLE' flag is set in the new ticket, +and the renew-till value is set as if the 'RENEWABLE' option were requested + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +(the field and option names are described fully in section 5.4.1). + +If the RENEWABLE option has been requested or if the RENEWABLE-OK option has +been set and a renewable ticket is to be issued, then the renew-till field +is set to the minimum of: + + * Its requested value. + * The start time of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database entries. + * The start time of the ticket plus the maximum renewable lifetime set by + the policy of the local realm. + +The flags field of the new ticket will have the following options set if +they have been requested and if the policy of the local realm allows: +FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new +ticket is post-dated (the start time is in the future), its INVALID flag +will also be set. + +If all of the above succeed, the server formats a KRB_AS_REP message (see +section 5.4.2), copying the addresses in the request into the caddr of the +response, placing any required pre-authentication data into the padata of +the response, and encrypts the ciphertext part in the client's key using the +requested encryption method, and sends it to the client. See section A.2 for +pseudocode. + +3.1.4. Generation of KRB_ERROR message + +Several errors can occur, and the Authentication Server responds by +returning an error message, KRB_ERROR, to the client, with the error-code +and e-text fields set to appropriate values. The error message contents and +details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP message + +If the reply message type is KRB_AS_REP, then the client verifies that the +cname and crealm fields in the cleartext portion of the reply match what it +requested. If any padata fields are present, they may be used to derive the +proper secret key to decrypt the message. The client decrypts the encrypted +part of the response using its secret key, verifies that the nonce in the +encrypted part matches the nonce it supplied in its request (to detect +replays). It also verifies that the sname and srealm in the response match +those in the request (or are otherwise expected values), and that the host +address field is also correct. It then stores the ticket, session key, start +and expiration times, and other information for later use. The +key-expiration field from the encrypted part of the response may be checked +to notify the user of impending key expiration (the client program could +then suggest remedial action, such as a password change). See section A.3 +for pseudocode. + +Proper decryption of the KRB_AS_REP message is not sufficient to verify the +identity of the user; the user and an attacker could cooperate to generate a +KRB_AS_REP format message which decrypts properly but is not from the proper +KDC. If the host wishes to verify the identity of the user, it must require +the user to present application credentials which can be verified using a +securely-stored secret key for the host. If those credentials can be +verified, then the identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR message + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +If the reply message type is KRB_ERROR, then the client interprets it as an +error and performs whatever application-specific tasks are necessary to +recover. + +3.2. The Client/Server Authentication Exchange + + Summary +Message direction Message type Section +Client to Application server KRB_AP_REQ 5.5.1 +[optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + +The client/server authentication (CS) exchange is used by network +applications to authenticate the client to the server and vice versa. The +client must have already acquired credentials for the server using the AS or +TGS exchange. + +3.2.1. The KRB_AP_REQ message + +The KRB_AP_REQ contains authentication information which should be part of +the first message in an authenticated transaction. It contains a ticket, an +authenticator, and some additional bookkeeping information (see section +5.5.1 for the exact format). The ticket by itself is insufficient to +authenticate a client, since tickets are passed across the network in +cleartext[DS90], so the authenticator is used to prevent invalid replay of +tickets by proving to the server that the client knows the session key of +the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is +referred to elsewhere as the 'authentication header.' + +3.2.2. Generation of a KRB_AP_REQ message + +When a client wishes to initiate authentication to a server, it obtains +(either through a credentials cache, the AS exchange, or the TGS exchange) a +ticket and session key for the desired service. The client may re-use any +tickets it holds until they expire. To use a ticket the client constructs a +new Authenticator from the the system time, its name, and optionally an +application specific checksum, an initial sequence number to be used in +KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in +negotiations for a session key unique to this particular session. +Authenticators may not be re-used and will be rejected if replayed to a +server[LGDSR87]. If a sequence number is to be included, it should be +randomly chosen so that even after many messages have been exchanged it is +not likely to collide with other sequence numbers in use. + +The client may indicate a requirement of mutual authentication or the use of +a session-key based ticket by setting the appropriate flag(s) in the +ap-options field of the message. + +The Authenticator is encrypted in the session key and combined with the +ticket to form the KRB_AP_REQ message which is then sent to the end server +along with any additional application-specific information. See section A.9 +for pseudocode. + +3.2.3. Receipt of KRB_AP_REQ message + +Authentication is based on the server's current time of day (clocks must be +loosely synchronized), the authenticator, and the ticket. Several errors are +possible. If an error occurs, the server is expected to reply to the client +with a KRB_ERROR message. This message may be encapsulated in the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +application protocol if its 'raw' form is not acceptable to the protocol. +The format of error messages is described in section 5.9.1. + +The algorithm for verifying authentication information is as follows. If the +message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE +error. If the key version indicated by the Ticket in the KRB_AP_REQ is not +one the server can use (e.g., it indicates an old key, and the server no +longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is +returned. If the USE-SESSION-KEY flag is set in the ap-options field, it +indicates to the server that the ticket is encrypted in the session key from +the server's ticket-granting ticket rather than its secret key[10]. Since it +is possible for the server to be registered in multiple realms, with +different keys in each, the srealm field in the unencrypted portion of the +ticket in the KRB_AP_REQ is used to specify which secret key the server +should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is +returned if the server doesn't have the proper key to decipher the ticket. + +The ticket is decrypted using the version of the server's key specified by +the ticket. If the decryption routines detect a modification of the ticket +(each encryption system must provide safeguards to detect modified +ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned +(chances are good that different keys were used to encrypt and decrypt). + +The authenticator is decrypted using the session key extracted from the +decrypted ticket. If decryption shows it to have been modified, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client +from the ticket are compared against the same fields in the authenticator. +If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might +not match, for example, if the wrong session key was used to encrypt the +authenticator). The addresses in the ticket (if any) are then searched for +an address matching the operating-system reported address of the client. If +no match is found or the server insists on ticket addresses but none are +present in the ticket, the KRB_AP_ERR_BADADDR error is returned. + +If the local (server) time and the client time in the authenticator differ +by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW +error is returned. If the server name, along with the client name, time and +microsecond fields from the Authenticator match any recently-seen such +tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must +remember any authenticator presented within the allowable clock skew, so +that a replay attempt is guaranteed to fail. If a server loses track of any +authenticator presented within the allowable clock skew, it must reject all +requests until the clock skew interval has passed. This assures that any +lost or re-played authenticators will fall outside the allowable clock skew +and can no longer be successfully replayed (If this is not done, an attacker +could conceivably record the ticket and authenticator sent over the network +to a server, then disable the client's host, pose as the disabled host, and +replay the ticket and authenticator to subvert the authentication.). If a +sequence number is provided in the authenticator, the server saves it for +later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is +present, the server either saves it for later use or uses it to help +generate its own choice for a subkey to be returned in a KRB_AP_REP message. + +The server computes the age of the ticket: local (server) time minus the +start time inside the Ticket. If the start time is later than the current +time by more than the allowable clock skew or if the INVALID flag is set in +the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the +current time is later than end time by more than the allowable clock skew, +the KRB_AP_ERR_TKT_EXPIRED error is returned. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + +If all these checks succeed without an error, the server is assured that the +client possesses the credentials of the principal named in the ticket and +thus, the client has been authenticated to the server. See section A.10 for +pseudocode. + +Passing these checks provides only authentication of the named principal; it +does not imply authorization to use the named service. Applications must +make a separate authorization decisions based upon the authenticated name of +the user, the requested operation, local acces control information such as +that contained in a .k5login or .k5users file, and possibly a separate +distributed authorization service. + +3.2.4. Generation of a KRB_AP_REP message + +Typically, a client's request will include both the authentication +information and its initial request in the same message, and the server need +not explicitly reply to the KRB_AP_REQ. However, if mutual authentication +(not only authenticating the client to the server, but also the server to +the client) is being performed, the KRB_AP_REQ message will have +MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is +required in response. As with the error message, this message may be +encapsulated in the application protocol if its "raw" form is not acceptable +to the application's protocol. The timestamp and microsecond field used in +the reply must be the client's timestamp and microsecond field (as provided +in the authenticator)[12]. If a sequence number is to be included, it should +be randomly chosen as described above for the authenticator. A subkey may be +included if the server desires to negotiate a different subkey. The +KRB_AP_REP message is encrypted in the session key extracted from the +ticket. See section A.11 for pseudocode. + +3.2.5. Receipt of KRB_AP_REP message + +If a KRB_AP_REP message is returned, the client uses the session key from +the credentials obtained for the server[13] to decrypt the message, and +verifies that the timestamp and microsecond fields match those in the +Authenticator it sent to the server. If they match, then the client is +assured that the server is genuine. The sequence number and subkey (if +present) are retained for later use. See section A.12 for pseudocode. + +3.2.6. Using the encryption key + +After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server +share an encryption key which can be used by the application. The 'true +session key' to be used for KRB_PRIV, KRB_SAFE, or other +application-specific uses may be chosen by the application based on the +subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases, +the use of this session key will be implicit in the protocol; in others the +method of use must be chosen from several alternatives. We leave the +protocol negotiations of how to use the key (e.g. selecting an encryption or +checksum type) to the application programmer; the Kerberos protocol does not +constrain the implementation options, but an example of how this might be +done follows. + +One way that an application may choose to negotiate a key to be used for +subequent integrity and privacy protection is for the client to propose a +key in the subkey field of the authenticator. The server can then choose a +key using the proposed key from the client as input, returning the new +subkey in the subkey field of the application reply. This key could then be + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +used for subsequent communication. To make this example more concrete, if +the encryption method in use required a 56 bit key, and for whatever reason, +one of the parties was prevented from using a key with more than 40 unknown +bits, this method would allow the the party which is prevented from using +more than 40 bits to either propose (if the client) an initial key with a +known quantity for 16 of those bits, or to mask 16 of the bits (if the +server) with the known quantity. The application implementor is warned, +however, that this is only an example, and that an analysis of the +particular crytosystem to be used, and the reasons for limiting the key +length, must be made before deciding whether it is acceptable to mask bits +of the key. + +With both the one-way and mutual authentication exchanges, the peers should +take care not to send sensitive information to each other without proper +assurances. In particular, applications that require privacy or integrity +should use the KRB_AP_REP response from the server to client to assure both +client and server of their peer's identity. If an application protocol +requires privacy of its messages, it can use the KRB_PRIV message (section +3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The TGS exchange between a client and the Kerberos Ticket-Granting Server is +initiated by a client when it wishes to obtain authentication credentials +for a given server (which might be registered in a remote realm), when it +wishes to renew or validate an existing ticket, or when it wishes to obtain +a proxy ticket. In the first case, the client must already have acquired a +ticket for the Ticket-Granting Service using the AS exchange (the +ticket-granting ticket is usually obtained when a client initially +authenticates to the system, such as when a user logs in). The message +format for the TGS exchange is almost identical to that for the AS exchange. +The primary difference is that encryption and decryption in the TGS exchange +does not take place under the client's key. Instead, the session key from +the ticket-granting ticket or renewable ticket, or sub-session key from an +Authenticator is used. As is the case for all application servers, expired +tickets are not accepted by the TGS, so once a renewable or ticket-granting +ticket expires, the client must use a separate exchange to obtain valid +tickets. + +The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the +client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or +KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the +client plus a request for credentials. The authentication information +consists of the authentication header (KRB_AP_REQ) which includes the +client's previously obtained ticket-granting, renewable, or invalid ticket. +In the ticket-granting ticket and proxy cases, the request may include one +or more of: a list of network addresses, a collection of typed authorization +data to be sealed in the ticket for authorization use by the application +server, or additional tickets (the use of which are described later). The +TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the +session key from the ticket-granting ticket or renewable ticket, or if +present, in the sub-session key from the Authenticator (part of the +authentication header). The KRB_ERROR message contains an error code and + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +text explaining what went wrong. The KRB_ERROR message is not encrypted. The +KRB_TGS_REP message contains information which can be used to detect +replays, and to associate it with the message to which it replies. The +KRB_ERROR message also contains information which can be used to associate +it with the message to which it replies, but the lack of encryption in the +KRB_ERROR message precludes the ability to detect replays or fabrications of +such messages. + +3.3.1. Generation of KRB_TGS_REQ message + +Before sending a request to the ticket-granting service, the client must +determine in which realm the application server is registered[15]. If the +client does not already possess a ticket-granting ticket for the appropriate +realm, then one must be obtained. This is first attempted by requesting a +ticket-granting ticket for the destination realm from a Kerberos server for +which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ +message recursively). The Kerberos server may return a TGT for the desired +realm in which case one can proceed. Alternatively, the Kerberos server may +return a TGT for a realm which is 'closer' to the desired realm (further +along the standard hierarchical path), in which case this step must be +repeated with a Kerberos server in the realm specified in the returned TGT. +If neither are returned, then the request must be retried with a Kerberos +server for a realm higher in the hierarchy. This request will itself require +a ticket-granting ticket for the higher realm which must be obtained by +recursively applying these directions. + +Once the client obtains a ticket-granting ticket for the appropriate realm, +it determines which Kerberos servers serve that realm, and contacts one. The +list might be obtained through a configuration file or network service or it +may be generated from the name of the realm; as long as the secret keys +exchanged by realms are kept secret, only denial of service results from +using a false Kerberos server. + +As in the AS exchange, the client may specify a number of options in the +KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing +an authentication header as an element of the padata field, and including +the same fields as used in the KRB_AS_REQ message along with several +optional fields: the enc-authorization-data field for application server use +and additional tickets required by some options. + +In preparing the authentication header, the client can select a sub-session +key under which the response from the Kerberos server will be encrypted[16]. +If the sub-session key is not specified, the session key from the +ticket-granting ticket will be used. If the enc-authorization-data is +present, it must be encrypted in the sub-session key, if present, from the +authenticator portion of the authentication header, or if not present, using +the session key from the ticket-granting ticket. + +Once prepared, the message is sent to a Kerberos server for the destination +realm. See section A.5 for pseudocode. + +3.3.2. Receipt of KRB_TGS_REQ message + +The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ +message, but there are many additional checks to be performed. First, the +Kerberos server must determine which server the accompanying ticket is for +and it must select the appropriate key to decrypt it. For a normal +KRB_TGS_REQ message, it will be for the ticket granting service, and the +TGS's key will be used. If the TGT was issued by another realm, then the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +appropriate inter-realm key must be used. If the accompanying ticket is not +a ticket granting ticket for the current realm, but is for an application +server in the current realm, the RENEW, VALIDATE, or PROXY options are +specified in the request, and the server for which a ticket is requested is +the server named in the accompanying ticket, then the KDC will decrypt the +ticket in the authentication header using the key of the server for which it +was issued. If no ticket can be found in the padata field, the +KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + +Once the accompanying ticket has been decrypted, the user-supplied checksum +in the Authenticator must be verified against the contents of the request, +and the message rejected if the checksums do not match (with an error code +of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not +collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the +checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is +returned. If the authorization-data are present, they are decrypted using +the sub-session key from the Authenticator. + +If any of the decryptions indicate failed integrity checks, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. + +3.3.3. Generation of KRB_TGS_REP message + +The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), +but with its type field set to KRB_TGS_REP. The detailed specification is in +section 5.4.2. + +The response will include a ticket for the requested server. The Kerberos +database is queried to retrieve the record for the requested server +(including the key with which the ticket will be encrypted). If the request +is for a ticket granting ticket for a remote realm, and if no key is shared +with the requested realm, then the Kerberos server will select the realm +"closest" to the requested realm with which it does share a key, and use +that realm instead. This is the only case where the response from the KDC +will be for a different server than that requested by the client. + +By default, the address field, the client's name and realm, the list of +transited realms, the time of initial authentication, the expiration time, +and the authorization data of the newly-issued ticket will be copied from +the ticket-granting ticket (TGT) or renewable ticket. If the transited field +needs to be updated, but the transited type is not supported, the +KDC_ERR_TRTYPE_NOSUPP error is returned. + +If the request specifies an endtime, then the endtime of the new ticket is +set to the minimum of (a) that request, (b) the endtime from the TGT, and +(c) the starttime of the TGT plus the minimum of the maximum life for the +application server and the maximum life for the local realm (the maximum +life for the requesting principal was already applied when the TGT was +issued). If the new ticket is to be a renewal, then the endtime above is +replaced by the minimum of (a) the value of the renew_till field of the +ticket and (b) the starttime for the new ticket plus the life +(endtime-starttime) of the old ticket. + +If the FORWARDED option has been requested, then the resulting ticket will +contain the addresses specified by the client. This option will only be +honored if the FORWARDABLE flag is set in the TGT. The PROXY option is +similar; the resulting ticket will contain the addresses specified by the +client. It will be honored only if the PROXIABLE flag in the TGT is set. The +PROXY option will not be honored on requests for additional ticket-granting + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +tickets. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified or the MAY-POSTDATE flag is not set in the TGT, then the +error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting +ticket has the MAY-POSTDATE flag set, then the resulting ticket will be +postdated and the requested starttime is checked against the policy of the +local realm. If acceptable, the ticket's start time is set as requested, and +the INVALID flag is set. The postdated ticket must be validated before use +by presenting it to the KDC after the starttime has been reached. However, +in no case may the starttime, endtime, or renew-till time of a newly-issued +postdated ticket extend beyond the renew-till time of the ticket-granting +ticket. + +If the ENC-TKT-IN-SKEY option has been specified and an additional ticket +has been included in the request, the KDC will decrypt the additional ticket +using the key for the server to which the additional ticket was issued and +verify that it is a ticket-granting ticket. If the name of the requested +server is missing from the request, the name of the client in the additional +ticket will be used. Otherwise the name of the requested server will be +compared to the name of the client in the additional ticket and if +different, the request will be rejected. If the request succeeds, the +session key from the additional ticket will be used to encrypt the new +ticket that is issued instead of using the key of the server for which the +new ticket will be used[17]. + +If the name of the server in the ticket that is presented to the KDC as part +of the authentication header is not that of the ticket-granting server +itself, the server is registered in the realm of the KDC, and the RENEW +option is requested, then the KDC will verify that the RENEWABLE flag is set +in the ticket, that the INVALID flag is not set in the ticket, and that the +renew_till time is still in the future. If the VALIDATE option is rqeuested, +the KDC will check that the starttime has passed and the INVALID flag is +set. If the PROXY option is requested, then the KDC will check that the +PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket +passes the hotlist check described in the next paragraph, the KDC will issue +the appropriate new ticket. + +3.3.3.1. Checking for revoked tickets + +Whenever a request is made to the ticket-granting server, the presented +ticket(s) is(are) checked against a hot-list of tickets which have been +canceled. This hot-list might be implemented by storing a range of issue +timestamps for 'suspect tickets'; if a presented ticket had an authtime in +that range, it would be rejected. In this way, a stolen ticket-granting +ticket or renewable ticket cannot be used to gain additional tickets +(renewals or otherwise) once the theft has been reported. Any normal ticket +obtained before it was reported stolen will still be valid (because they +require no interaction with the KDC), but only until their normal expiration +time. + +The ciphertext part of the response in the KRB_TGS_REP message is encrypted +in the sub-session key from the Authenticator, if present, or the session +key key from the ticket-granting ticket. It is not encrypted using the +client's secret key. Furthermore, the client's key's expiration date and the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +key version number fields are left out since these values are stored along +with the client's database record, and that record is not needed to satisfy +a request based on a ticket-granting ticket. See section A.6 for pseudocode. + +3.3.3.2. Encoding the transited field + +If the identity of the server in the TGT that is presented to the KDC as +part of the authentication header is that of the ticket-granting service, +but the TGT was issued from another realm, the KDC will look up the +inter-realm key shared with that realm and use that key to decrypt the +ticket. If the ticket is valid, then the KDC will honor the request, subject +to the constraints outlined above in the section describing the AS exchange. +The realm part of the client's identity will be taken from the +ticket-granting ticket. The name of the realm that issued the +ticket-granting ticket will be added to the transited field of the ticket to +be issued. This is accomplished by reading the transited field from the +ticket-granting ticket (which is treated as an unordered set of realm +names), adding the new realm to the set, then constructing and writing out +its encoded (shorthand) form (this may involve a rearrangement of the +existing encoding). + +Note that the ticket-granting service does not add the name of its own +realm. Instead, its responsibility is to add the name of the previous realm. +This prevents a malicious Kerberos server from intentionally leaving out its +own name (it could, however, omit other realms' names). + +The names of neither the local realm nor the principal's realm are to be +included in the transited field. They appear elsewhere in the ticket and +both are known to have taken part in authenticating the principal. Since the +endpoints are not included, both local and single-hop inter-realm +authentication result in a transited field that is empty. + +Because the name of each realm transited is added to this field, it might +potentially be very long. To decrease the length of this field, its contents +are encoded. The initially supported encoding is optimized for the normal +case of inter-realm communication: a hierarchical arrangement of realms +using either domain or X.500 style realm names. This encoding (called +DOMAIN-X500-COMPRESS) is now described. + +Realm names in the transited field are separated by a ",". The ",", "\", +trailing "."s, and leading spaces (" ") are special characters, and if they +are part of a realm name, they must be quoted in the transited field by +preced- ing them with a "\". + +A realm name ending with a "." is interpreted as being prepended to the +previous realm. For example, we can encode traversal of EDU, MIT.EDU, +ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + +Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they +would not be included in this field, and we would have: + + "EDU,MIT.,WASHINGTON.EDU" + +A realm name beginning with a "/" is interpreted as being appended to the +previous realm[18]. If it is to stand by itself, then it should be preceded +by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, +/COM/HP, /COM, and /COM/DEC as: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + "/COM,/HP,/APOLLO, /COM/DEC". + +Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they +they would not be included in this field, and we would have: + + "/COM,/HP" + +A null subfield preceding or following a "," indicates that all realms +between the previous realm and the next realm have been traversed[19]. Thus, +"," means that all realms along the path between the client and the server +have been traversed. ",EDU, /COM," means that that all realms from the +client's realm up to EDU (in a domain style hierarchy) have been traversed, +and that everything from /COM down to the server's realm in an X.500 style +has also been traversed. This could occur if the EDU realm in one hierarchy +shares an inter-realm key directly with the /COM realm in another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP message + +When the KRB_TGS_REP is received by the client, it is processed in the same +manner as the KRB_AS_REP processing described above. The primary difference +is that the ciphertext part of the response must be decrypted using the +session key from the ticket-granting ticket rather than the client's secret +key. See section A.7 for pseudocode. + +3.4. The KRB_SAFE Exchange + +The KRB_SAFE message may be used by clients requiring the ability to detect +modifications of messages they exchange. It achieves this by including a +keyed collision-proof checksum of the user data and some control +information. The checksum is keyed with an encryption key (usually the last +key negotiated via subkeys, or the session key if no negotiation has +occured). + +3.4.1. Generation of a KRB_SAFE message + +When an application wishes to send a KRB_SAFE message, it collects its data +and the appropriate control information and computes a checksum over them. +The checksum algorithm should be a keyed one-way hash function (such as the +RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), +generated using the sub-session key if present, or the session key. +Different algorithms may be selected by changing the checksum type in the +message. Unkeyed or non-collision-proof checksums are not suitable for this +use. + +The control information for the KRB_SAFE message includes both a timestamp +and a sequence number. The designer of an application using the KRB_SAFE +message must choose at least one of the two mechanisms. This choice should +be based on the needs of the application protocol. + +Sequence numbers are useful when all messages sent will be received by one's +peer. Connection state is presently required to maintain the session key, so +maintaining the next sequence number should not present an additional +problem. + +If the application protocol is expected to tolerate lost messages without +them being resent, the use of the timestamp is the appropriate replay +detection mechanism. Using timestamps is also the appropriate mechanism for +multi-cast protocols where all of one's peers share a common sub-session + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +key, but some messages will be sent to a subset of one's peers. + +After computing the checksum, the client then transmits the information and +checksum to the recipient in the message format specified in section 5.6.1. + +3.4.2. Receipt of KRB_SAFE message + +When an application receives a KRB_SAFE message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + +The message is first checked by verifying that the protocol version and type +fields match the current version and KRB_SAFE, respectively. A mismatch +generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The +application verifies that the checksum used is a collision-proof keyed +checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If +the sender's address was included in the control information, the recipient +verifies that the operating system's report of the sender's address matches +the sender's address in the message, and (if a recipient address is +specified or the recipient requires an address) that one of the recipient's +addresses appears as the recipient's address in the message. A failed match +for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and +usec and/or the sequence number fields are checked. If timestamp and usec +are expected and not present, or they are present but not current, the +KRB_AP_ERR_SKEW error is generated. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT +error is generated. If an incorrect sequence number is included, or a +sequence number is expected but not present, the KRB_AP_ERR_BADORDER error +is generated. If neither a time-stamp and usec or a sequence number is +present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is +computed over the data and control information, and if it doesn't match the +received checksum, a KRB_AP_ERR_MODIFIED error is generated. + +If all the checks succeed, the application is assured that the message was +generated by its peer and was not modi- fied in transit. + +3.5. The KRB_PRIV Exchange + +The KRB_PRIV message may be used by clients requiring confidentiality and +the ability to detect modifications of exchanged messages. It achieves this +by encrypting the messages and adding control information. + +3.5.1. Generation of a KRB_PRIV message + +When an application wishes to send a KRB_PRIV message, it collects its data +and the appropriate control information (specified in section 5.7.1) and +encrypts them under an encryption key (usually the last key negotiated via +subkeys, or the session key if no negotiation has occured). As part of the +control information, the client must choose to use either a timestamp or a +sequence number (or both); see the discussion in section 3.4.1 for +guidelines on which to use. After the user data and control information are +encrypted, the client transmits the ciphertext and some 'envelope' +information to the recipient. + +3.5.2. Receipt of KRB_PRIV message + +When an application receives a KRB_PRIV message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +The message is first checked by verifying that the protocol version and type +fields match the current version and KRB_PRIV, respectively. A mismatch +generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The +application then decrypts the ciphertext and processes the resultant +plaintext. If decryption shows the data to have been modified, a +KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was +included in the control information, the recipient verifies that the +operating system's report of the sender's address matches the sender's +address in the message, and (if a recipient address is specified or the +recipient requires an address) that one of the recipient's addresses appears +as the recipient's address in the message. A failed match for either case +generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the +sequence number fields are checked. If timestamp and usec are expected and +not present, or they are present but not current, the KRB_AP_ERR_SKEW error +is generated. If the server name, along with the client name, time and +microsecond fields from the Authenticator match any recently-seen such +tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence +number is included, or a sequence number is expected but not present, the +KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or +a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. + +If all the checks succeed, the application can assume the message was +generated by its peer, and was securely transmitted (without intruders able +to see the unencrypted contents). + +3.6. The KRB_CRED Exchange + +The KRB_CRED message may be used by clients requiring the ability to send +Kerberos credentials from one host to another. It achieves this by sending +the tickets together with encrypted data containing the session keys and +other information associated with the tickets. + +3.6.1. Generation of a KRB_CRED message + +When an application wishes to send a KRB_CRED message it first (using the +KRB_TGS exchange) obtains credentials to be sent to the remote host. It then +constructs a KRB_CRED message using the ticket or tickets so obtained, +placing the session key needed to use each ticket in the key field of the +corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED +message. + +Other information associated with each ticket and obtained during the +KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in +the encrypted part of the KRB_CRED message. The current time and, if +specifically required by the application the nonce, s-address, and r-address +fields, are placed in the encrypted part of the KRB_CRED message which is +then encrypted under an encryption key previosuly exchanged in the KRB_AP +exchange (usually the last key negotiated via subkeys, or the session key if +no negotiation has occured). + +3.6.2. Receipt of KRB_CRED message + +When an application receives a KRB_CRED message, it verifies it. If any +error occurs, an error code is reported for use by the application. The +message is verified by checking that the protocol version and type fields +match the current version and KRB_CRED, respectively. A mismatch generates a +KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then +decrypts the ciphertext and processes the resultant plaintext. If decryption +shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +generated. + +If present or required, the recipient verifies that the operating system's +report of the sender's address matches the sender's address in the message, +and that one of the recipient's addresses appears as the recipient's address +in the message. A failed match for either case generates a +KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field +if required) are checked next. If the timestamp and usec are not present, or +they are present but not current, the KRB_AP_ERR_SKEW error is generated. + +If all the checks succeed, the application stores each of the new tickets in +its ticket cache together with the session key and other information in the +corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED +message. + +4. The Kerberos Database + +The Kerberos server must have access to a database containing the principal +identifiers and secret keys of principals to be authenticated[21]. + +4.1. Database contents + +A database entry should contain at least the following fields: + +Field Value + +name Principal's identifier +key Principal's secret key +p_kvno Principal's key version +max_life Maximum lifetime for Tickets +max_renewable_life Maximum total lifetime for renewable Tickets + +The name field is an encoding of the principal's identifier. The key field +contains an encryption key. This key is the principal's secret key. (The key +can be encrypted before storage under a Kerberos "master key" to protect it +in case the database is compromised but the master key is not. In that case, +an extra field must be added to indicate the master key version used, see +below.) The p_kvno field is the key version number of the principal's secret +key. The max_life field contains the maximum allowable lifetime (endtime - +starttime) for any Ticket issued for this principal. The max_renewable_life +field contains the maximum allowable total lifetime for any renewable Ticket +issued for this principal. (See section 3.1 for a description of how these +lifetimes are used in determining the lifetime of a given Ticket.) + +A server may provide KDC service to several realms, as long as the database +representation provides a mechanism to distinguish between principal records +with identifiers which differ only in the realm name. + +When an application server's key changes, if the change is routine (i.e. not +the result of disclosure of the old key), the old key should be retained by +the server until all tickets that had been issued using that key have +expired. Because of this, it is possible for several keys to be active for a +single principal. Ciphertext encrypted in a principal's key is always tagged +with the version of the key that was used for encryption, to help the +recipient find the proper key for decryption. + +When more than one key is active for a particular principal, the principal +will have more than one record in the Kerberos database. The keys and key +version numbers will differ between the records (the rest of the fields may + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +or may not be the same). Whenever Kerberos issues a ticket, or responds to a +request for initial authentication, the most recent key (known by the +Kerberos server) will be used for encryption. This is the key with the +highest key version number. + +4.2. Additional fields + +Project Athena's KDC implementation uses additional fields in its database: + +Field Value + +K_kvno Kerberos' key version +expiration Expiration date for entry +attributes Bit field of attributes +mod_date Timestamp of last modification +mod_name Modifying principal's identifier + +The K_kvno field indicates the key version of the Kerberos master key under +which the principal's secret key is encrypted. + +After an entry's expiration date has passed, the KDC will return an error to +any client attempting to gain tickets as or for the principal. (A database +may want to maintain two expiration dates: one for the principal, and one +for the principal's current key. This allows password aging to work +independently of the principal's expiration date. However, due to the +limited space in the responses, the KDC must combine the key expiration and +principal expiration date into a single value called 'key_exp', which is +used as a hint to the user to take administrative action.) + +The attributes field is a bitfield used to govern the operations involving +the principal. This field might be useful in conjunction with user +registration procedures, for site-specific policy implementations (Project +Athena currently uses it for their user registration process controlled by +the system-wide database service, Moira [LGDSR87]), to identify whether a +principal can play the role of a client or server or both, to note whether a +server is appropriate trusted to recieve credentials delegated by a client, +or to identify the 'string to key' conversion algorithm used for a +principal's key[22]. Other bits are used to indicate that certain ticket +options should not be allowed in tickets encrypted under a principal's key +(one bit each): Disallow issuing postdated tickets, disallow issuing +forwardable tickets, disallow issuing tickets based on TGT authentication, +disallow issuing renewable tickets, disallow issuing proxiable tickets, and +disallow issuing tickets for which the principal is the server. + +The mod_date field contains the time of last modification of the entry, and +the mod_name field contains the name of the principal which last modified +the entry. + +4.3. Frequently Changing Fields + +Some KDC implementations may wish to maintain the last time that a request +was made by a particular principal. Information that might be maintained +includes the time of the last request, the time of the last request for a +ticket-granting ticket, the time of the last use of a ticket-granting +ticket, or other times. This information can then be returned to the user in +the last-req field (see section 5.2). + +Other frequently changing information that can be maintained is the latest +expiration time for any tickets that have been issued using each key. This + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +field would be used to indicate how long old keys must remain valid to allow +the continued use of outstanding tickets. + +4.4. Site Constants + +The KDC implementation should have the following configurable constants or +options, to allow an administrator to make and enforce policy decisions: + + * The minimum supported lifetime (used to determine whether the + KDC_ERR_NEVER_VALID error should be returned). This constant should + reflect reasonable expectations of round-trip time to the KDC, + encryption/decryption time, and processing time by the client and + target server, and it should allow for a minimum 'useful' lifetime. + * The maximum allowable total (renewable) lifetime of a ticket + (renew_till - starttime). + * The maximum allowable lifetime of a ticket (endtime - starttime). + * Whether to allow the issue of tickets with empty address fields + (including the ability to specify that such tickets may only be issued + if the request specifies some authorization_data). + * Whether proxiable, forwardable, renewable or post-datable tickets are + to be issued. + +5. Message Specifications + +The following sections describe the exact contents and encoding of protocol +messages and objects. The ASN.1 base definitions are presented in the first +subsection. The remaining subsections specify the protocol objects (tickets +and authenticators) and messages. Specification of encryption and checksum +techniques, and the fields related to them, appear in section 6. + +Optional field in ASN.1 sequences + +For optional integer value and date fields in ASN.1 sequences where a +default value has been specified, certain default values will not be allowed +in the encoding because these values will always be represented through +defaulting by the absence of the optional field. For example, one will not +send a microsecond zero value because one must make sure that there is only +one way to encode this value. + +Additional fields in ASN.1 sequences + +Implementations receiving Kerberos messages with additional fields present +in ASN.1 sequences should carry the those fields through, unmodified, when +the message is forwarded. Implementations should not drop such fields if the +sequence is reencoded. + +5.1. ASN.1 Distinguished Encoding Representation + +All uses of ASN.1 in Kerberos shall use the Distinguished Encoding +Representation of the data elements as described in the X.509 specification, +section 8.7 [X509-88]. + +5.3. ASN.1 Base Definitions + +The following ASN.1 base definitions are used in the rest of this section. +Note that since the underscore character (_) is not permitted in ASN.1 +names, the hyphen (-) is used in its place for the purposes of ASN.1 names. + +Realm ::= GeneralString + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString +} + +Kerberos realms are encoded as GeneralStrings. Realms shall not contain a +character with the code 0 (the ASCII NUL). Most realms will usually consist +of several components separated by periods (.), in the style of Internet +Domain Names, or separated by slashes (/) in the style of X.500 names. +Acceptable forms for realm names are specified in section 7. A PrincipalName +is a typed sequence of components consisting of the following sub-fields: + +name-type + This field specifies the type of name that follows. Pre-defined values + for this field are specified in section 7.2. The name-type should be + treated as a hint. Ignoring the name type, no two names can be the same + (i.e. at least one of the components, or the realm, must be different). + This constraint may be eliminated in the future. +name-string + This field encodes a sequence of components that form a name, each + component encoded as a GeneralString. Taken together, a PrincipalName + and a Realm form a principal identifier. Most PrincipalNames will have + only a few components (typically one or two). + +KerberosTime ::= GeneralizedTime + -- Specifying UTC time zone (Z) + +The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding +shall specify the UTC time zone (Z) and shall not include any fractional +portions of the seconds. It further shall not include any separators. +Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm +on 6 November 1985 is 19851106210627Z. + +HostAddress ::= SEQUENCE { + addr-type[0] INTEGER, + address[1] OCTET STRING +} + +HostAddresses ::= SEQUENCE OF HostAddress + +The host adddress encodings consists of two fields: + +addr-type + This field specifies the type of address that follows. Pre-defined + values for this field are specified in section 8.1. +address + This field encodes a single address of type addr-type. + +The two forms differ slightly. HostAddress contains exactly one address; +HostAddresses contains a sequence of possibly many addresses. + +AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type[0] INTEGER, + ad-data[1] OCTET STRING +} + +ad-data + This field contains authorization data to be interpreted according to + the value of the corresponding ad-type field. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +ad-type + This field specifies the format for the ad-data subfield. All negative + values are reserved for local use. Non-negative values are reserved for + registered use. + +Each sequence of type and data is refered to as an authorization element. +Elements may be application specific, however, there is a common set of +recursive elements that should be understood by all implementations. These +elements contain other elements embedded within them, and the interpretation +of the encapsulating element determines which of the embedded elements must +be interpreted, and which may be ignored. Definitions for these common +elements may be found in Appendix B. + +TicketExtensions ::= SEQUENCE OF SEQUENCE { + te-type[0] INTEGER, + te-data[1] OCTET STRING +} + + + +te-data + This field contains opaque data that must be caried with the ticket to + support extensions to the Kerberos protocol including but not limited + to some forms of inter-realm key exchange and plaintext authorization + data. See appendix C for some common uses of this field. +te-type + This field specifies the format for the te-data subfield. All negative + values are reserved for local use. Non-negative values are reserved for + registered use. + +APOptions ::= BIT STRING + -- reserved(0), + -- use-session-key(1), + -- mutual-required(2) + +TicketFlags ::= BIT STRING + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), + -- transited-policy-checked(12), + -- ok-as-delegate(13) + +KDCOptions ::= BIT STRING + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + -- unused7(7), + -- renewable(8), + -- unused9(9), + -- unused10(10), + -- unused11(11), + -- unused12(12), + -- unused13(13), + -- disable-transited-check(26), + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + +ASN.1 Bit strings have a length and a value. When used in Kerberos for the +APOptions, TicketFlags, and KDCOptions, the length of the bit string on +generated values should be the smallest number of bits needed to include the +highest order bit that is set (1), but in no case less than 32 bits. The +ASN.1 representation of the bit strings uses unnamed bits, with the meaning +of the individual bits defined by the comments in the specification above. +Implementations should accept values of bit strings of any length and treat +the value of flags corresponding to bits beyond the end of the bit string as +if the bit were reset (0). Comparison of bit strings of different length +should treat the smaller string as if it were padded with zeros beyond the +high order bits to the length of the longer string[23]. + +LastReq ::= SEQUENCE OF SEQUENCE { + lr-type[0] INTEGER, + lr-value[1] KerberosTime +} + +lr-type + This field indicates how the following lr-value field is to be + interpreted. Negative values indicate that the information pertains + only to the responding server. Non-negative values pertain to all + servers for the realm. If the lr-type field is zero (0), then no + information is conveyed by the lr-value subfield. If the absolute value + of the lr-type field is one (1), then the lr-value subfield is the time + of last initial request for a TGT. If it is two (2), then the lr-value + subfield is the time of last initial request. If it is three (3), then + the lr-value subfield is the time of issue for the newest + ticket-granting ticket used. If it is four (4), then the lr-value + subfield is the time of the last renewal. If it is five (5), then the + lr-value subfield is the time of last request (of any type). If it is + (6), then the lr-value subfield is the time when the password will + expire. +lr-value + This field contains the time of the last request. the time must be + interpreted according to the contents of the accompanying lr-type + subfield. + +See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, +EncryptionKey, EncryptionType, and KeyType. + +5.3. Tickets and Authenticators + +This section describes the format and encryption parameters for tickets and +authenticators. When a ticket or authenticator is included in a protocol +message it is treated as an opaque object. + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +5.3.1. Tickets + +A ticket is a record that helps a client authenticate to a service. A Ticket +contains the following information: + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno[0] INTEGER, + realm[1] Realm, + sname[2] PrincipalName, + enc-part[3] EncryptedData, + extensions[4] TicketExtensions OPTIONAL +} + +-- Encrypted part of ticket +EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags[0] TicketFlags, + key[1] EncryptionKey, + crealm[2] Realm, + cname[3] PrincipalName, + transited[4] TransitedEncoding, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + caddr[9] HostAddresses OPTIONAL, + authorization-data[10] AuthorizationData OPTIONAL +} +-- encoded Transited field +TransitedEncoding ::= SEQUENCE { + tr-type[0] INTEGER, -- must be registered + contents[1] OCTET STRING +} + +The encoding of EncTicketPart is encrypted in the key shared by Kerberos and +the end server (the server's secret key). See section 6 for the format of +the ciphertext. + +tkt-vno + This field specifies the version number for the ticket format. This + document describes version number 5. +realm + This field specifies the realm that issued a ticket. It also serves to + identify the realm part of the server's principal identifier. Since a + Kerberos server can only issue tickets for servers within its realm, + the two will always be identical. +sname + This field specifies all components of the name part of the server's + identity, including those parts that identify a specific instance of a + service. +enc-part + This field holds the encrypted encoding of the EncTicketPart sequence. +extensions + This optional field contains a sequence of extentions that may be used + to carry information that must be carried with the ticket to support + several extensions, including but not limited to plaintext + authorization data, tokens for exchanging inter-realm keys, and other + information that must be associated with a ticket for use by the + application server. See Appendix C for definitions of some common + extensions. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + Note that some older versions of Kerberos did not support this field. + Because this is an optional field it will not break older clients, but + older clients might strip this field from the ticket before sending it + to the application server. This limits the usefulness of this ticket + field to environments where the ticket will not be parsed and + reconstructed by these older Kerberos clients. + + If it is known that the client will strip this field from the ticket, + as an interim measure the KDC may append this field to the end of the + enc-part of the ticket and append a traler indicating the lenght of the + appended extensions field. (this paragraph is open for discussion, + including the form of the traler). +flags + This field indicates which of various options were used or requested + when the ticket was issued. It is a bit-field, where the selected + options are indicated by the bit being set (1), and the unselected + options and reserved fields being reset (0). Bit 0 is the most + significant bit. The encoding of the bits is specified in section 5.2. + The flags are described in more detail above in section 2. The meanings + of the flags are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. When set, this + flag tells the ticket-granting server + that it is OK to issue a new ticket- + granting ticket with a different network + address based on the presented ticket. + + 2 FORWARDED + When set, this flag indicates that the + ticket has either been forwarded or was + issued based on authentication involving + a forwarded ticket-granting ticket. + + 3 PROXIABLE + The PROXIABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. The PROXIABLE + flag has an interpretation identical to + that of the FORWARDABLE flag, except + that the PROXIABLE flag tells the + ticket-granting server that only non- + ticket-granting tickets may be issued + with different network addresses. + + 4 PROXY + When set, this flag indicates that a + ticket is a proxy. + + 5 MAY-POSTDATE + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. This flag tells + the ticket-granting server that a post- + dated ticket may be issued based on this + ticket-granting ticket. + + 6 POSTDATED + This flag indicates that this ticket has + been postdated. The end-service can + check the authtime field to see when the + original authentication occurred. + + 7 INVALID + This flag indicates that a ticket is + invalid, and it must be validated by the + KDC before use. Application servers + must reject tickets which have this flag + set. + + 8 RENEWABLE + The RENEWABLE flag is normally only + interpreted by the TGS, and can usually + be ignored by end servers (some particu- + larly careful servers may wish to disal- + low renewable tickets). A renewable + ticket can be used to obtain a replace- + ment ticket that expires at a later + date. + + 9 INITIAL + This flag indicates that this ticket was + issued using the AS protocol, and not + issued based on a ticket-granting + ticket. + + 10 PRE-AUTHENT + This flag indicates that during initial + authentication, the client was authenti- + cated by the KDC before a ticket was + issued. The strength of the pre- + authentication method is not indicated, + but is acceptable to the KDC. + + 11 HW-AUTHENT + This flag indicates that the protocol + employed for initial authentication + required the use of hardware expected to + be possessed solely by the named client. + The hardware authentication method is + selected by the KDC and the strength of + the method is not indicated. + + 12 TRANSITED This flag indicates that the KDC for the + POLICY-CHECKED realm has checked the transited field + against a realm defined policy for + trusted certifiers. If this flag is + reset (0), then the application server + must check the transited field itself, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + and if unable to do so it must reject + the authentication. If the flag is set + (1) then the application server may skip + its own validation of the transited + field, relying on the validation + performed by the KDC. At its option the + application server may still apply its + own validation based on a separate + policy for acceptance. + + 13 OK-AS-DELEGATE This flag indicates that the server (not + the client) specified in the ticket has + been determined by policy of the realm + to be a suitable recipient of + delegation. A client can use the + presence of this flag to help it make a + decision whether to delegate credentials + (either grant a proxy or a forwarded + ticket granting ticket) to this server. + The client is free to ignore the value + of this flag. When setting this flag, + an administrator should consider the + Security and placement of the server on + which the service will run, as well as + whether the service requires the use of + delegated credentials. + + 14 ANONYMOUS + This flag indicates that the principal + named in the ticket is a generic princi- + pal for the realm and does not identify + the individual using the ticket. The + purpose of the ticket is only to + securely distribute a session key, and + not to identify the user. Subsequent + requests using the same ticket and ses- + sion may be considered as originating + from the same user, but requests with + the same username but a different ticket + are likely to originate from different + users. + + 15-31 RESERVED + Reserved for future use. + +key + This field exists in the ticket and the KDC response and is used to + pass the session key from Kerberos to the application server and the + client. The field's encoding is described in section 6.2. +crealm + This field contains the name of the realm in which the client is + registered and in which initial authentication took place. +cname + This field contains the name part of the client's principal identifier. +transited + This field lists the names of the Kerberos realms that took part in + authenticating the user to whom this ticket was issued. It does not + specify the order in which the realms were transited. See section + 3.3.3.2 for details on how this field encodes the traversed realms. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + When the names of CA's are to be embedded inthe transited field (as + specified for some extentions to the protocol), the X.500 names of the + CA's should be mapped into items in the transited field using the + mapping defined by RFC2253. +authtime + This field indicates the time of initial authentication for the named + principal. It is the time of issue for the original ticket on which + this ticket is based. It is included in the ticket to provide + additional information to the end service, and to provide the necessary + information for implementation of a `hot list' service at the KDC. An + end service that is particularly paranoid could refuse to accept + tickets for which the initial authentication occurred "too far" in the + past. This field is also returned as part of the response from the KDC. + When returned as part of the response to initial authentication + (KRB_AS_REP), this is the current time on the Kerberos server[24]. +starttime + This field in the ticket specifies the time after which the ticket is + valid. Together with endtime, this field specifies the life of the + ticket. If it is absent from the ticket, its value should be treated as + that of the authtime field. +endtime + This field contains the time after which the ticket will not be honored + (its expiration time). Note that individual services may place their + own limits on the life of a ticket and may reject tickets which have + not yet expired. As such, this is really an upper bound on the + expiration time for the ticket. +renew-till + This field is only present in tickets that have the RENEWABLE flag set + in the flags field. It indicates the maximum endtime that may be + included in a renewal. It can be thought of as the absolute expiration + time for the ticket, including all renewals. +caddr + This field in a ticket contains zero (if omitted) or more (if present) + host addresses. These are the addresses from which the ticket can be + used. If there are no addresses, the ticket can be used from any + location. The decision by the KDC to issue or by the end server to + accept zero-address tickets is a policy decision and is left to the + Kerberos and end-service administrators; they may refuse to issue or + accept such tickets. The suggested and default policy, however, is that + such tickets will only be issued or accepted when additional + information that can be used to restrict the use of the ticket is + included in the authorization_data field. Such a ticket is a + capability. + + Network addresses are included in the ticket to make it harder for an + attacker to use stolen credentials. Because the session key is not sent + over the network in cleartext, credentials can't be stolen simply by + listening to the network; an attacker has to gain access to the session + key (perhaps through operating system security breaches or a careless + user's unattended session) to make use of stolen tickets. + + It is important to note that the network address from which a + connection is received cannot be reliably determined. Even if it could + be, an attacker who has compromised the client's workstation could use + the credentials from there. Including the network addresses only makes + it more difficult, not impossible, for an attacker to walk off with + stolen credentials and then use them from a "safe" location. +authorization-data + The authorization-data field is used to pass authorization data from + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the principal on whose behalf a ticket was issued to the application + service. If no authorization data is included, this field will be left + out. Experience has shown that the name of this field is confusing, and + that a better name for this field would be restrictions. Unfortunately, + it is not possible to change the name of this field at this time. + + This field contains restrictions on any authority obtained on the basis + of authentication using the ticket. It is possible for any principal in + posession of credentials to add entries to the authorization data field + since these entries further restrict what can be done with the ticket. + Such additions can be made by specifying the additional entries when a + new ticket is obtained during the TGS exchange, or they may be added + during chained delegation using the authorization data field of the + authenticator. + + Because entries may be added to this field by the holder of + credentials, except when an entry is separately authenticated by + encapulation in the kdc-issued element, it is not allowable for the + presence of an entry in the authorization data field of a ticket to + amplify the priveleges one would obtain from using a ticket. + + The data in this field may be specific to the end service; the field + will contain the names of service specific objects, and the rights to + those objects. The format for this field is described in section 5.2. + Although Kerberos is not concerned with the format of the contents of + the sub-fields, it does carry type information (ad-type). + + By using the authorization_data field, a principal is able to issue a + proxy that is valid for a specific purpose. For example, a client + wishing to print a file can obtain a file server proxy to be passed to + the print server. By specifying the name of the file in the + authorization_data field, the file server knows that the print server + can only use the client's rights when accessing the particular file to + be printed. + + A separate service providing authorization or certifying group + membership may be built using the authorization-data field. In this + case, the entity granting authorization (not the authorized entity), + may obtain a ticket in its own name (e.g. the ticket is issued in the + name of a privelege server), and this entity adds restrictions on its + own authority and delegates the restricted authority through a proxy to + the client. The client would then present this authorization credential + to the application server separately from the authentication exchange. + Alternatively, such authorization credentials may be embedded in the + ticket authenticating the authorized entity, when the authorization is + separately authenticated using the kdc-issued authorization data + element (see B.4). + + Similarly, if one specifies the authorization-data field of a proxy and + leaves the host addresses blank, the resulting ticket and session key + can be treated as a capability. See [Neu93] for some suggested uses of + this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +5.3.2. Authenticators + +An authenticator is a record sent with a ticket to a server to certify the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +client's knowledge of the encryption key in the ticket, to help the server +detect replays, and to help choose a "true session key" to use with the +particular session. The encoding is encrypted in the ticket's session key +shared by the client and the server: + +-- Unencrypted authenticator +Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno[0] INTEGER, + crealm[1] Realm, + cname[2] PrincipalName, + cksum[3] Checksum OPTIONAL, + cusec[4] INTEGER, + ctime[5] KerberosTime, + subkey[6] EncryptionKey OPTIONAL, + seq-number[7] INTEGER OPTIONAL, + authorization-data[8] AuthorizationData OPTIONAL +} + + +authenticator-vno + This field specifies the version number for the format of the + authenticator. This document specifies version 5. +crealm and cname + These fields are the same as those described for the ticket in section + 5.3.1. +cksum + This field contains a checksum of the the applica- tion data that + accompanies the KRB_AP_REQ. +cusec + This field contains the microsecond part of the client's timestamp. Its + value (before encryption) ranges from 0 to 999999. It often appears + along with ctime. The two fields are used together to specify a + reasonably accurate timestamp. +ctime + This field contains the current time on the client's host. +subkey + This field contains the client's choice for an encryption key which is + to be used to protect this specific application session. Unless an + application specifies otherwise, if this field is left out the session + key from the ticket will be used. +seq-number + This optional field includes the initial sequence number to be used by + the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to + detect replays (It may also be used by application specific messages). + When included in the authenticator this field specifies the initial + sequence number for messages from the client to the server. When + included in the AP-REP message, the initial sequence number is that for + messages from the server to the client. When used in KRB_PRIV or + KRB_SAFE messages, it is incremented by one after each message is sent. + Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to + zero following the value 2^32 - 1. + + For sequence numbers to adequately support the detection of replays + they should be non-repeating, even across connection boundaries. The + initial sequence number should be random and uniformly distributed + across the full space of possible sequence numbers, so that it cannot + be guessed by an attacker and so that it and the successive sequence + numbers do not repeat other sequences. +authorization-data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + This field is the same as described for the ticket in section 5.3.1. It + is optional and will only appear when additional restrictions are to be + placed on the use of a ticket, beyond those carried in the ticket + itself. + +5.4. Specifications for the AS and TGS exchanges + +This section specifies the format of the messages used in the exchange +between the client and the Kerberos server. The format of possible error +messages appears in section 5.9.1. + +5.4.1. KRB_KDC_REQ definition + +The KRB_KDC_REQ message has no type of its own. Instead, its type is one of +KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial +ticket or an additional ticket. In either case, the message is sent from the +client to the Authentication Server to request credentials for a service. + +The message fields are: + +AS-REQ ::= [APPLICATION 10] KDC-REQ +TGS-REQ ::= [APPLICATION 12] KDC-REQ + +KDC-REQ ::= SEQUENCE { + pvno[1] INTEGER, + msg-type[2] INTEGER, + padata[3] SEQUENCE OF PA-DATA OPTIONAL, + req-body[4] KDC-REQ-BODY +} + +PA-DATA ::= SEQUENCE { + padata-type[1] INTEGER, + padata-value[2] OCTET STRING, + -- might be encoded AP-REQ +} + +KDC-REQ-BODY ::= SEQUENCE { + kdc-options[0] KDCOptions, + cname[1] PrincipalName OPTIONAL, + -- Used only in AS-REQ + realm[2] Realm, -- Server's realm + -- Also client's in AS-REQ + sname[3] PrincipalName OPTIONAL, + from[4] KerberosTime OPTIONAL, + till[5] KerberosTime OPTIONAL, + rtime[6] KerberosTime OPTIONAL, + nonce[7] INTEGER, + etype[8] SEQUENCE OF INTEGER, + -- EncryptionType, + -- in preference order + addresses[9] HostAddresses OPTIONAL, + enc-authorization-data[10] EncryptedData OPTIONAL, + -- Encrypted AuthorizationData + -- encoding + additional-tickets[11] SEQUENCE OF Ticket OPTIONAL +} + +The fields in this message are: + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +pvno + This field is included in each message, and specifies the protocol + version number. This document specifies protocol version 5. +msg-type + This field indicates the type of a protocol message. It will almost + always be the same as the application identifier associated with a + message. It is included to make the identifier more readily accessible + to the application. For the KDC-REQ message, this type will be + KRB_AS_REQ or KRB_TGS_REQ. +padata + The padata (pre-authentication data) field contains a sequence of + authentication information which may be needed before credentials can + be issued or decrypted. In the case of requests for additional tickets + (KRB_TGS_REQ), this field will include an element with padata-type of + PA-TGS-REQ and data of an authentication header (ticket-granting ticket + and authenticator). The checksum in the authenticator (which must be + collision-proof) is to be computed over the KDC-REQ-BODY encoding. In + most requests for initial authentication (KRB_AS_REQ) and most replies + (KDC-REP), the padata field will be left out. + + This field may also contain information needed by certain extensions to + the Kerberos protocol. For example, it might be used to initially + verify the identity of a client before any response is returned. This + is accomplished with a padata field with padata-type equal to + PA-ENC-TIMESTAMP and padata-value defined as follows: + + padata-type ::= PA-ENC-TIMESTAMP + padata-value ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp[0] KerberosTime, -- client's time + pausec[1] INTEGER OPTIONAL + } + + with patimestamp containing the client's time and pausec containing the + microseconds which may be omitted if a client will not generate more + than one request per second. The ciphertext (padata-value) consists of + the PA-ENC-TS-ENC sequence, encrypted using the client's secret key. + + [use-specified-kvno item is here for discussion and may be removed] It + may also be used by the client to specify the version of a key that is + being used for accompanying preauthentication, and/or which should be + used to encrypt the reply from the KDC. + + PA-USE-SPECIFIED-KVNO ::= Integer + + The KDC should only accept and abide by the value of the + use-specified-kvno preauthentication data field when the specified key + is still valid and until use of a new key is confirmed. This situation + is likely to occur primarily during the period during which an updated + key is propagating to other KDC's in a realm. + + The padata field can also contain information needed to help the KDC or + the client select the key needed for generating or decrypting the + response. This form of the padata is useful for supporting the use of + certain token cards with Kerberos. The details of such extensions are + specified in separate documents. See [Pat92] for additional uses of + this field. +padata-type + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The padata-type element of the padata field indicates the way that the + padata-value element is to be interpreted. Negative values of + padata-type are reserved for unregistered use; non-negative values are + used for a registered interpretation of the element type. +req-body + This field is a placeholder delimiting the extent of the remaining + fields. If a checksum is to be calculated over the request, it is + calculated over an encoding of the KDC-REQ-BODY sequence which is + enclosed within the req-body field. +kdc-options + This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the + KDC and indicates the flags that the client wants set on the tickets as + well as other information that is to modify the behavior of the KDC. + Where appropriate, the name of an option may be the same as the flag + that is set by that option. Although in most case, the bit in the + options field will be the same as that in the flags field, this is not + guaranteed, so it is not acceptable to simply copy the options field to + the flags field. There are various checks that must be made before + honoring an option anyway. + + The kdc_options field is a bit-field, where the selected options are + indicated by the bit being set (1), and the unselected options and + reserved fields being reset (0). The encoding of the bits is specified + in section 5.2. The options are described in more detail above in + section 2. The meanings of the options are: + + Bit(s) Name Description + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE option indicates that + the ticket to be issued is to have its + forwardable flag set. It may only be + set on the initial request, or in a sub- + sequent request if the ticket-granting + ticket on which it is based is also for- + wardable. + + 2 FORWARDED + The FORWARDED option is only specified + in a request to the ticket-granting + server and will only be honored if the + ticket-granting ticket in the request + has its FORWARDABLE bit set. This + option indicates that this is a request + for forwarding. The address(es) of the + host from which the resulting ticket is + to be valid are included in the + addresses field of the request. + + 3 PROXIABLE + The PROXIABLE option indicates that the + ticket to be issued is to have its prox- + iable flag set. It may only be set on + the initial request, or in a subsequent + request if the ticket-granting ticket on + which it is based is also proxiable. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + 4 PROXY + The PROXY option indicates that this is + a request for a proxy. This option will + only be honored if the ticket-granting + ticket in the request has its PROXIABLE + bit set. The address(es) of the host + from which the resulting ticket is to be + valid are included in the addresses + field of the request. + + 5 ALLOW-POSTDATE + The ALLOW-POSTDATE option indicates that + the ticket to be issued is to have its + MAY-POSTDATE flag set. It may only be + set on the initial request, or in a sub- + sequent request if the ticket-granting + ticket on which it is based also has its + MAY-POSTDATE flag set. + + 6 POSTDATED + The POSTDATED option indicates that this + is a request for a postdated ticket. + This option will only be honored if the + ticket-granting ticket on which it is + based has its MAY-POSTDATE flag set. + The resulting ticket will also have its + INVALID flag set, and that flag may be + reset by a subsequent request to the KDC + after the starttime in the ticket has + been reached. + + 7 UNUSED + This option is presently unused. + + 8 RENEWABLE + The RENEWABLE option indicates that the + ticket to be issued is to have its + RENEWABLE flag set. It may only be set + on the initial request, or when the + ticket-granting ticket on which the + request is based is also renewable. If + this option is requested, then the rtime + field in the request contains the + desired absolute expiration time for the + ticket. + + 9-13 UNUSED + These options are presently unused. + + 14 REQUEST-ANONYMOUS + The REQUEST-ANONYMOUS option indicates + that the ticket to be issued is not to + identify the user to which it was + issued. Instead, the principal identif- + ier is to be generic, as specified by + the policy of the realm (e.g. usually + anonymous@realm). The purpose of the + ticket is only to securely distribute a + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + session key, and not to identify the + user. The ANONYMOUS flag on the ticket + to be returned should be set. If the + local realms policy does not permit + anonymous credentials, the request is to + be rejected. + + 15-25 RESERVED + Reserved for future use. + + 26 DISABLE-TRANSITED-CHECK + By default the KDC will check the + transited field of a ticket-granting- + ticket against the policy of the local + realm before it will issue derivative + tickets based on the ticket granting + ticket. If this flag is set in the + request, checking of the transited field + is disabled. Tickets issued without the + performance of this check will be noted + by the reset (0) value of the + TRANSITED-POLICY-CHECKED flag, + indicating to the application server + that the tranisted field must be checked + locally. KDC's are encouraged but not + required to honor the + DISABLE-TRANSITED-CHECK option. + + 27 RENEWABLE-OK + The RENEWABLE-OK option indicates that a + renewable ticket will be acceptable if a + ticket with the requested life cannot + otherwise be provided. If a ticket with + the requested life cannot be provided, + then a renewable ticket may be issued + with a renew-till equal to the the + requested endtime. The value of the + renew-till field may still be limited by + local limits, or limits selected by the + individual principal or server. + + 28 ENC-TKT-IN-SKEY + This option is used only by the ticket- + granting service. The ENC-TKT-IN-SKEY + option indicates that the ticket for the + end server is to be encrypted in the + session key from the additional ticket- + granting ticket provided. + + 29 RESERVED + Reserved for future use. + + 30 RENEW + This option is used only by the ticket- + granting service. The RENEW option + indicates that the present request is + for a renewal. The ticket provided is + encrypted in the secret key for the + server on which it is valid. This + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + option will only be honored if the + ticket to be renewed has its RENEWABLE + flag set and if the time in its renew- + till field has not passed. The ticket + to be renewed is passed in the padata + field as part of the authentication + header. + + 31 VALIDATE + This option is used only by the ticket- + granting service. The VALIDATE option + indicates that the request is to vali- + date a postdated ticket. It will only + be honored if the ticket presented is + postdated, presently has its INVALID + flag set, and would be otherwise usable + at this time. A ticket cannot be vali- + dated before its starttime. The ticket + presented for validation is encrypted in + the key of the server for which it is + valid and is passed in the padata field + as part of the authentication header. + +cname and sname + These fields are the same as those described for the ticket in section + 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is + specified. If absent, the name of the server is taken from the name of + the client in the ticket passed as additional-tickets. +enc-authorization-data + The enc-authorization-data, if present (and it can only be present in + the TGS_REQ form), is an encoding of the desired authorization-data + encrypted under the sub-session key if present in the Authenticator, or + alternatively from the session key in the ticket-granting ticket, both + from the padata field in the KRB_AP_REQ. +realm + This field specifies the realm part of the server's principal + identifier. In the AS exchange, this is also the realm part of the + client's principal identifier. +from + This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket + requests when the requested ticket is to be postdated. It specifies the + desired start time for the requested ticket. If this field is omitted + then the KDC should use the current time instead. +till + This field contains the expiration date requested by the client in a + ticket request. It is optional and if omitted the requested ticket is + to have the maximum endtime permitted according to KDC policy for the + parties to the authentication exchange as limited by expiration date of + the ticket granting ticket or other preauthentication credentials. +rtime + This field is the requested renew-till time sent from a client to the + KDC in a ticket request. It is optional. +nonce + This field is part of the KDC request and response. It it intended to + hold a random number generated by the client. If the same number is + included in the encrypted response from the KDC, it provides evidence + that the response is fresh and has not been replayed by an attacker. + Nonces must never be re-used. Ideally, it should be generated randomly, + but if the correct time is known, it may suffice[25]. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +etype + This field specifies the desired encryption algorithm to be used in the + response. +addresses + This field is included in the initial request for tickets, and + optionally included in requests for additional tickets from the + ticket-granting server. It specifies the addresses from which the + requested ticket is to be valid. Normally it includes the addresses for + the client's host. If a proxy is requested, this field will contain + other addresses. The contents of this field are usually copied by the + KDC into the caddr field of the resulting ticket. +additional-tickets + Additional tickets may be optionally included in a request to the + ticket-granting server. If the ENC-TKT-IN-SKEY option has been + specified, then the session key from the additional ticket will be used + in place of the server's key to encrypt the new ticket. If more than + one option which requires additional tickets has been specified, then + the additional tickets are used in the order specified by the ordering + of the options bits (see kdc-options, above). + +The application code will be either ten (10) or twelve (12) depending on +whether the request is for an initial ticket (AS-REQ) or for an additional +ticket (TGS-REQ). + +The optional fields (addresses, authorization-data and additional-tickets) +are only included if necessary to perform the operation specified in the +kdc-options field. + +It should be noted that in KRB_TGS_REQ, the protocol version number appears +twice and two different message types appear: the KRB_TGS_REQ message +contains these fields as does the authentication header (KRB_AP_REQ) that is +passed in the padata field. + +5.4.2. KRB_KDC_REP definition + +The KRB_KDC_REP message format is used for the reply from the KDC for either +an initial (AS) request or a subsequent (TGS) request. There is no message +type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or +KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply +depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in +the client's secret key, and the client's key version number is included in +the key version number for the encrypted data. For KRB_TGS_REP, the +ciphertext is encrypted in the sub-session key from the Authenticator, or if +absent, the session key from the ticket-granting ticket used in the request. +In that case, no version number will be present in the EncryptedData +sequence. + +The KRB_KDC_REP message contains the following fields: + +AS-REP ::= [APPLICATION 11] KDC-REP +TGS-REP ::= [APPLICATION 13] KDC-REP + +KDC-REP ::= SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + padata[2] SEQUENCE OF PA-DATA OPTIONAL, + crealm[3] Realm, + cname[4] PrincipalName, + ticket[5] Ticket, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + enc-part[6] EncryptedData +} + +EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart +EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + +EncKDCRepPart ::= SEQUENCE { + key[0] EncryptionKey, + last-req[1] LastReq, + nonce[2] INTEGER, + key-expiration[3] KerberosTime OPTIONAL, + flags[4] TicketFlags, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + srealm[9] Realm, + sname[10] PrincipalName, + caddr[11] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is either + KRB_AS_REP or KRB_TGS_REP. +padata + This field is described in detail in section 5.4.1. One possible use + for this field is to encode an alternate "mix-in" string to be used + with a string-to-key algorithm (such as is described in section 6.3.2). + This ability is useful to ease transitions if a realm name needs to + change (e.g. when a company is acquired); in such a case all existing + password-derived entries in the KDC database would be flagged as + needing a special mix-in string until the next password change. +crealm, cname, srealm and sname + These fields are the same as those described for the ticket in section + 5.3.1. +ticket + The newly-issued ticket, from section 5.3.1. +enc-part + This field is a place holder for the ciphertext and related information + that forms the encrypted part of a message. The description of the + encrypted part of the message follows each appearance of this field. + The encrypted part is encoded as described in section 6.1. +key + This field is the same as described for the ticket in section 5.3.1. +last-req + This field is returned by the KDC and specifies the time(s) of the last + request by a principal. Depending on what information is available, + this might be the last time that a request for a ticket-granting ticket + was made, or the last time that a request based on a ticket-granting + ticket was successful. It also might cover all servers for a realm, or + just the particular server. Some implementations may display this + information to the user to aid in discovering unauthorized use of one's + identity. It is similar in spirit to the last login time displayed when + logging into timesharing systems. +nonce + This field is described above in section 5.4.1. +key-expiration + The key-expiration field is part of the response from the KDC and + specifies the time that the client's secret key is due to expire. The + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + expiration might be the result of password aging or an account + expiration. This field will usually be left out of the TGS reply since + the response to the TGS request is encrypted in a session key and no + client information need be retrieved from the KDC database. It is up to + the application client (usually the login program) to take appropriate + action (such as notifying the user) if the expiration time is imminent. +flags, authtime, starttime, endtime, renew-till and caddr + These fields are duplicates of those found in the encrypted portion of + the attached ticket (see section 5.3.1), provided so the client may + verify they match the intended request and to assist in proper ticket + caching. If the message is of type KRB_TGS_REP, the caddr field will + only be filled in if the request was for a proxy or forwarded ticket, + or if the user is substituting a subset of the addresses from the + ticket granting ticket. If the client-requested addresses are not + present or not used, then the addresses contained in the ticket will be + the same as those included in the ticket-granting ticket. + +5.5. Client/Server (CS) message specifications + +This section specifies the format of the messages used for the +authentication of the client to the application server. + +5.5.1. KRB_AP_REQ definition + +The KRB_AP_REQ message contains the Kerberos protocol version number, the +message type KRB_AP_REQ, an options field to indicate any options in use, +and the ticket and authenticator themselves. The KRB_AP_REQ message is often +referred to as the 'authentication header'. + +AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ap-options[2] APOptions, + ticket[3] Ticket, + authenticator[4] EncryptedData +} + +APOptions ::= BIT STRING { + reserved(0), + use-session-key(1), + mutual-required(2) +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REQ. +ap-options + This field appears in the application request (KRB_AP_REQ) and affects + the way the request is processed. It is a bit-field, where the selected + options are indicated by the bit being set (1), and the unselected + options and reserved fields being reset (0). The encoding of the bits + is specified in section 5.2. The meanings of the options are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + field. + + 1 USE-SESSION-KEY + The USE-SESSION-KEY option indicates + that the ticket the client is presenting + to a server is encrypted in the session + key from the server's ticket-granting + ticket. When this option is not speci- + fied, the ticket is encrypted in the + server's secret key. + + 2 MUTUAL-REQUIRED + The MUTUAL-REQUIRED option tells the + server that the client requires mutual + authentication, and that it must respond + with a KRB_AP_REP message. + + 3-31 RESERVED + Reserved for future use. + +ticket + This field is a ticket authenticating the client to the server. +authenticator + This contains the authenticator, which includes the client's choice of + a subkey. Its encoding is described in section 5.3.2. + +5.5.2. KRB_AP_REP definition + +The KRB_AP_REP message contains the Kerberos protocol version number, the +message type, and an encrypted time- stamp. The message is sent in in +response to an application request (KRB_AP_REQ) where the mutual +authentication option has been selected in the ap-options field. + +AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[2] EncryptedData +} + +EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { + ctime[0] KerberosTime, + cusec[1] INTEGER, + subkey[2] EncryptionKey OPTIONAL, + seq-number[3] INTEGER OPTIONAL +} + +The encoded EncAPRepPart is encrypted in the shared session key of the +ticket. The optional subkey field can be used in an application-arranged +negotiation to choose a per association session key. + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REP. +enc-part + This field is described above in section 5.4.2. +ctime + This field contains the current time on the client's host. +cusec + This field contains the microsecond part of the client's timestamp. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +subkey + This field contains an encryption key which is to be used to protect + this specific application session. See section 3.2.6 for specifics on + how this field is used to negotiate a key. Unless an application + specifies otherwise, if this field is left out, the sub-session key + from the authenticator, or if also left out, the session key from the + ticket will be used. + +5.5.3. Error message reply + +If an error occurs while processing the application request, the KRB_ERROR +message will be sent in response. See section 5.9.1 for the format of the +error message. The cname and crealm fields may be left out if the server +cannot determine their appropriate values from the corresponding KRB_AP_REQ +message. If the authenticator was decipherable, the ctime and cusec fields +will contain the values from it. + +5.6. KRB_SAFE message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to send a tamper-proof message to +its peer. It presumes that a session key has previously been exchanged (for +example, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.6.1. KRB_SAFE definition + +The KRB_SAFE message contains user data along with a collision-proof +checksum keyed with the last encryption key negotiated via subkeys, or the +session key if no negotiation has occured. The message fields are: + +KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + safe-body[2] KRB-SAFE-BODY, + cksum[3] Checksum +} + +KRB-SAFE-BODY ::= SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_SAFE. +safe-body + This field is a placeholder for the body of the KRB-SAFE message. +cksum + This field contains the checksum of the application data. Checksum + details are described in section 6.4. The checksum is computed over the + encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the + checksum is computed over the encoding of the KRB-SAFE sequence, then + the checksum is set to the result of that computation, and finally the + KRB-SAFE sequence is encoded again. +user-data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + This field is part of the KRB_SAFE and KRB_PRIV messages and contain + the application specific data that is being passed from the sender to + the recipient. +timestamp + This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents + are the current time as known by the sender of the message. By checking + the timestamp, the recipient of the message is able to make sure that + it was recently generated, and is not a replay. +usec + This field is part of the KRB_SAFE and KRB_PRIV headers. It contains + the microsecond part of the timestamp. +seq-number + This field is described above in section 5.3.2. +s-address + This field specifies the address in use by the sender of the message. + It may be omitted if not required by the application protocol. The + application designer considering omission of this field is warned, that + the inclusion of this address prevents some kinds of replay attacks + (e.g., reflection attacks) and that it is only acceptable to omit this + address if there is sufficient information in the integrity protected + part of the application message for the recipient to unambiguously + determine if it was the intended recipient. +r-address + This field specifies the address in use by the recipient of the + message. It may be omitted for some uses (such as broadcast protocols), + but the recipient may arbitrarily reject such messages. This field + along with s-address can be used to help detect messages which have + been incorrectly or maliciously delivered to the wrong recipient. + +5.7. KRB_PRIV message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to securely and privately send a +message to its peer. It presumes that a session key has previously been +exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV definition + +The KRB_PRIV message contains user data encrypted in the Session Key. The +message fields are: + +KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[3] EncryptedData +} + +EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, -- sender's addr + r-address[5] HostAddress OPTIONAL -- recip's addr +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_PRIV. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +enc-part + This field holds an encoding of the EncKrbPrivPart sequence encrypted + under the session key[32]. This encrypted encoding is used for the + enc-part field of the KRB-PRIV message. See section 6 for the format of + the ciphertext. +user-data, timestamp, usec, s-address and r-address + These fields are described above in section 5.6.1. +seq-number + This field is described above in section 5.3.2. + +5.8. KRB_CRED message specification + +This section specifies the format of a message that can be used to send +Kerberos credentials from one principal to another. It is presented here to +encourage a common mechanism to be used by applications when forwarding +tickets or providing proxies to subordinate servers. It presumes that a +session key has already been exchanged perhaps by using the +KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED definition + +The KRB_CRED message contains a sequence of tickets to be sent and +information needed to use the tickets, including the session key from each. +The information needed to use the tickets is encrypted under an encryption +key previously exchanged or transferred alongside the KRB_CRED message. The +message fields are: + +KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, -- KRB_CRED + tickets[2] SEQUENCE OF Ticket, + enc-part[3] EncryptedData +} + +EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info[0] SEQUENCE OF KrbCredInfo, + nonce[1] INTEGER OPTIONAL, + timestamp[2] KerberosTime OPTIONAL, + usec[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +KrbCredInfo ::= SEQUENCE { + key[0] EncryptionKey, + prealm[1] Realm OPTIONAL, + pname[2] PrincipalName OPTIONAL, + flags[3] TicketFlags OPTIONAL, + authtime[4] KerberosTime OPTIONAL, + starttime[5] KerberosTime OPTIONAL, + endtime[6] KerberosTime OPTIONAL + renew-till[7] KerberosTime OPTIONAL, + srealm[8] Realm OPTIONAL, + sname[9] PrincipalName OPTIONAL, + caddr[10] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + KRB_CRED. +tickets + These are the tickets obtained from the KDC specifically for use by the + intended recipient. Successive tickets are paired with the + corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED + message. +enc-part + This field holds an encoding of the EncKrbCredPart sequence encrypted + under the session key shared between the sender and the intended + recipient. This encrypted encoding is used for the enc-part field of + the KRB-CRED message. See section 6 for the format of the ciphertext. +nonce + If practical, an application may require the inclusion of a nonce + generated by the recipient of the message. If the same value is + included as the nonce in the message, it provides evidence that the + message is fresh and has not been replayed by an attacker. A nonce must + never be re-used; it should be generated randomly by the recipient of + the message and provided to the sender of the message in an application + specific manner. +timestamp and usec + These fields specify the time that the KRB-CRED message was generated. + The time is used to provide assurance that the message is fresh. +s-address and r-address + These fields are described above in section 5.6.1. They are used + optionally to provide additional assurance of the integrity of the + KRB-CRED message. +key + This field exists in the corresponding ticket passed by the KRB-CRED + message and is used to pass the session key from the sender to the + intended recipient. The field's encoding is described in section 6.2. + +The following fields are optional. If present, they can be associated with +the credentials in the remote ticket file. If left out, then it is assumed +that the recipient of the credentials already knows their value. + +prealm and pname + The name and realm of the delegated principal identity. +flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr + These fields contain the values of the correspond- ing fields from the + ticket found in the ticket field. Descriptions of the fields are + identical to the descriptions in the KDC-REP message. + +5.9. Error message specification + +This section specifies the format for the KRB_ERROR message. The fields +included in the message are intended to return as much information as +possible about an error. It is not expected that all the information +required by the fields will be available for all types of errors. If the +appropriate information is not available when the message is composed, the +corresponding field will be left out of the message. + +Note that since the KRB_ERROR message is only optionally integrity +protected, it is quite possible for an intruder to synthesize or modify such +a message. In particular, this means that unless appropriate integrity +protection mechanisms have been applied to the KRB_ERROR message, the client +should not use any fields in this message for security-critical purposes, +such as setting a system clock or generating a fresh authenticator. The +message can be useful, however, for advising a user on the reason for some +failure. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + +5.9.1. KRB_ERROR definition + +The KRB_ERROR message consists of the following fields: + +KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ctime[2] KerberosTime OPTIONAL, + cusec[3] INTEGER OPTIONAL, + stime[4] KerberosTime, + susec[5] INTEGER, + error-code[6] INTEGER, + crealm[7] Realm OPTIONAL, + cname[8] PrincipalName OPTIONAL, + realm[9] Realm, -- Correct realm + sname[10] PrincipalName, -- Correct name + e-text[11] GeneralString OPTIONAL, + e-data[12] OCTET STRING OPTIONAL, + e-cksum[13] Checksum OPTIONAL, +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_ERROR. +ctime + This field is described above in section 5.4.1. +cusec + This field is described above in section 5.5.2. +stime + This field contains the current time on the server. It is of type + KerberosTime. +susec + This field contains the microsecond part of the server's timestamp. Its + value ranges from 0 to 999999. It appears along with stime. The two + fields are used in conjunction to specify a reasonably accurate + timestamp. +error-code + This field contains the error code returned by Kerberos or the server + when a request fails. To interpret the value of this field see the list + of error codes in section 8. Implementations are encouraged to provide + for national language support in the display of error messages. +crealm, cname, srealm and sname + These fields are described above in section 5.3.1. +e-text + This field contains additional text to help explain the error code + associated with the failed request (for example, it might include a + principal name which was unknown). +e-data + This field contains additional data about the error for use by the + application to help it recover from or handle the error. If present, + this field will contain the encoding of a sequence of TypedData + (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, + in which case it will contain the encoding of a sequence of of padata + fields (METHOD-DATA below), each corresponding to an acceptable + pre-authentication method and optionally containing data for the + method: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + TYPED-DATA ::= SEQUENCE of TypeData + METHOD-DATA ::= SEQUENCE of PA-DATA + + TypedData ::= SEQUENCE { + data-type[0] INTEGER, + data-value[1] OCTET STRING OPTIONAL + } + + Note that e-data-types have been reserved for all PA data types defined + prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when + using new PA data types defined in July 1999 or later, the METHOD-DATA + sequence must itself be encapsulated in an TypedData element of type + TD-PADATA. All new implementations interpreting the METHOD-DATA field + for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of + TD-PADATA, extract the typed data field and interpret the use any + elements encapsulated in the TD-PADATA elements as if they were present + in the METHOD-DATA sequence. +e-cksum + This field contains an optional checksum for the KRB-ERROR message. The + checksum is calculated over the Kerberos ASN.1 encoding of the + KRB-ERROR message with the checksum absent. The checksum is then added + to the KRB-ERROR structure and the message is re-encoded. The Checksum + should be calculated using the session key from the ticket granting + ticket or service ticket, where available. If the error is in response + to a TGS or AP request, the checksum should be calculated uing the the + session key from the client's ticket. If the error is in response to an + AS request, then the checksum should be calulated using the client's + secret key ONLY if there has been suitable preauthentication to prove + knowledge of the secret key by the client[33]. If a checksum can not be + computed because the key to be used is not available, no checksum will + be included. + + 6. Encryption and Checksum Specifications + + The Kerberos protocols described in this document are designed to use + stream encryption ciphers, which can be simulated using commonly + available block encryption ciphers, such as the Data Encryption + Standard [DES77], and triple DES variants, in conjunction with block + chaining and checksum methods [DESM80]. Encryption is used to prove the + identities of the network entities participating in message exchanges. + The Key Distribution Center for each realm is trusted by all principals + registered in that realm to store a secret key in confidence. Proof of + knowledge of this secret key is used to verify the authenticity of a + principal. + + The KDC uses the principal's secret key (in the AS exchange) or a + shared session key (in the TGS exchange) to encrypt responses to ticket + requests; the ability to obtain the secret key or session key implies + the knowledge of the appropriate keys and the identity of the KDC. The + ability of a principal to decrypt the KDC response and present a Ticket + and a properly formed Authenticator (generated with the session key + from the KDC response) to a service verifies the identity of the + principal; likewise the ability of the service to extract the session + key from the Ticket and prove its knowledge thereof in a response + verifies the identity of the service. + + The Kerberos protocols generally assume that the encryption used is + secure from cryptanalysis; however, in some cases, the order of fields + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + in the encrypted portions of messages are arranged to minimize the + effects of poorly chosen keys. It is still important to choose good + keys. If keys are derived from user-typed passwords, those passwords + need to be well chosen to make brute force attacks more difficult. + Poorly chosen keys still make easy targets for intruders. + + The following sections specify the encryption and checksum mechanisms + currently defined for Kerberos. The encodings, chaining, and padding + requirements for each are described. For encryption methods, it is + often desirable to place random information (often referred to as a + confounder) at the start of the message. The requirements for a + confounder are specified with each encryption mechanism. + + Some encryption systems use a block-chaining method to improve the the + security characteristics of the ciphertext. However, these chaining + methods often don't provide an integrity check upon decryption. Such + systems (such as DES in CBC mode) must be augmented with a checksum of + the plain-text which can be verified at decryption and used to detect + any tampering or damage. Such checksums should be good at detecting + burst errors in the input. If any damage is detected, the decryption + routine is expected to return an error indicating the failure of an + integrity check. Each encryption type is expected to provide and verify + an appropriate checksum. The specification of each encryption method + sets out its checksum requirements. + + Finally, where a key is to be derived from a user's password, an + algorithm for converting the password to a key of the appropriate type + is included. It is desirable for the string to key function to be + one-way, and for the mapping to be different in different realms. This + is important because users who are registered in more than one realm + will often use the same password in each, and it is desirable that an + attacker compromising the Kerberos server in one realm not obtain or + derive the user's key in another. + + For an discussion of the integrity characteristics of the candidate + encryption and checksum methods considered for Kerberos, the reader is + referred to [SG92]. + + 6.1. Encryption Specifications + + The following ASN.1 definition describes all encrypted messages. The + enc-part field which appears in the unencrypted part of messages in + section 5 is a sequence consisting of an encryption type, an optional + key version number, and the ciphertext. + + EncryptedData ::= SEQUENCE { + etype[0] INTEGER, -- EncryptionType + kvno[1] INTEGER OPTIONAL, + cipher[2] OCTET STRING -- ciphertext + } + + + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. Detailed specifications for selected + encryption types appear later in this section. + kvno + This field contains the version number of the key under which data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + is encrypted. It is only present in messages encrypted under long + lasting keys, such as principals' secret keys. + cipher + This field contains the enciphered text, encoded as an OCTET + STRING. + The cipher field is generated by applying the specified encryption + algorithm to data composed of the message and algorithm-specific + inputs. Encryption mechanisms defined for use with Kerberos must take + sufficient measures to guarantee the integrity of the plaintext, and we + recommend they also take measures to protect against precomputed + dictionary attacks. If the encryption algorithm is not itself capable + of doing so, the protections can often be enhanced by adding a checksum + and a confounder. + + The suggested format for the data to be encrypted includes a + confounder, a checksum, the encoded plaintext, and any necessary + padding. The msg-seq field contains the part of the protocol message + described in section 5 which is to be encrypted. The confounder, + checksum, and padding are all untagged and untyped, and their length is + exactly sufficient to hold the appropriate item. The type and length is + implicit and specified by the particular encryption type being used + (etype). The format for the data to be encrypted for some methods is + described in the following diagram, but other methods may deviate from + this layour - so long as the definition of the method defines the + layout actually in use. + + +-----------+----------+-------------+-----+ + |confounder | check | msg-seq | pad | + +-----------+----------+-------------+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + CipherText ::= ENCRYPTED SEQUENCE { + confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, + check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, + msg-seq[2] MsgSequence, + pad UNTAGGED OCTET STRING(pad_length) OPTIONAL + } + + One generates a random confounder of the appropriate length, placing it + in confounder; zeroes out check; calculates the appropriate checksum + over confounder, check, and msg-seq, placing the result in check; adds + the necessary padding; then encrypts using the specified encryption + type and the appropriate key. + + Unless otherwise specified, a definition of an encryption algorithm + that specifies a checksum, a length for the confounder field, or an + octet boundary for padding uses this ciphertext format[36]. Those + fields which are not specified will be omitted. + + In the interest of allowing all implementations using a particular + encryption type to communicate with all others using that type, the + specification of an encryption type defines any checksum that is needed + as part of the encryption process. If an alternative checksum is to be + used, a new encryption type must be defined. + + Some cryptosystems require additional information beyond the key and + the data to be encrypted. For example, DES, when used in + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + cipher-block-chaining mode, requires an initialization vector. If + required, the description for each encryption type must specify the + source of such additional information. 6.2. Encryption Keys + + The sequence below shows the encoding of an encryption key: + + EncryptionKey ::= SEQUENCE { + keytype[0] INTEGER, + keyvalue[1] OCTET STRING + } + + keytype + This field specifies the type of encryption that is to be + performed using the key that follows in the keyvalue field. It + will always correspond to the etype to be used to generate or + decode the EncryptedData. In cases when multiple algorithms use a + common kind of key (e.g., if the encryption algorithm uses an + alternate checksum algorithm for an integrity check, or a + different chaining mechanism), the keytype provides information + needed to determine which algorithm is to be used. + keyvalue + This field contains the key itself, encoded as an octet string. + All negative values for the encryption key type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpreta- tions. + + 6.3. Encryption Systems + + 6.3.1. The NULL Encryption System (null) + + If no encryption is in use, the encryption system is said to be the + NULL encryption system. In the NULL encryption system there is no + checksum, confounder or padding. The ciphertext is simply the + plaintext. The NULL Key is used by the null encryption system and is + zero octets in length, with keytype zero (0). + + 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) + + The des-cbc-crc encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is + applied to the confounder and message sequence (msg-seq) and placed in + the cksum field. DES blocks are 8 bytes. As a result, the data to be + encrypted (the concatenation of confounder, checksum, and message) must + be padded to an 8 byte boundary before encryption. The details of the + encryption of this data are identical to those for the des-cbc-md5 + encryption mode. + + Note that, since the CRC-32 checksum is not collision-proof, an + attacker could use a probabilistic chosen-plaintext attack to generate + a valid message even if a confounder is used [SG92]. The use of + collision-proof checksums is recommended for environments where such + attacks represent a significant threat. The use of the CRC-32 as the + checksum for ticket or authenticator is no longer mandated as an + interoperability requirement for Kerberos Version 5 Specification 1 + (See section 9.1 for specific details). + + 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The des-cbc-md4 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD4 checksum (described in [MD492]) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be padded + to an 8 byte boundary before encryption. The details of the encryption + of this data are identical to those for the des-cbc-md5 encryption + mode. + + 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) + + The des-cbc-md5 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be padded + to an 8 byte boundary before encryption. + + Plaintext and DES ciphtertext are encoded as blocks of 8 octets which + are concatenated to make the 64-bit inputs for the DES algorithms. The + first octet supplies the 8 most significant bits (with the octet's + MSbit used as the DES input block's MSbit, etc.), the second octet the + next 8 bits, ..., and the eighth octet supplies the 8 least significant + bits. + + Encryption under DES using cipher block chaining requires an additional + input in the form of an initialization vector. Unless otherwise + specified, zero should be used as the initialization vector. Kerberos' + use of DES requires an 8 octet confounder. + + The DES specifications identify some 'weak' and 'semi-weak' keys; those + keys shall not be used for encrypting messages for use in Kerberos. + Additionally, because of the way that keys are derived for the + encryption of checksums, keys shall not be used that yield 'weak' or + 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant + F0F0F0F0F0F0F0F0. + + A DES key is 8 octets of data, with keytype one (1). This consists of + 56 bits of key, and 8 parity bits (one per octet). The key is encoded + as a series of 8 octets written in MSB-first order. The bits within the + key are also encoded in MSB order. For example, if the encryption key + is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where + B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the + parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with + B1 as the MSbit). [See the FIPS 81 introduction for reference.] + + String to key transformation + + To generate a DES key from a text string (password), a "salt" is + concatenated to the text string, and then padded with ASCII nulls to an + 8 byte boundary. This "salt" is normally the realm and each component + of the principal's name appended. However, sometimes different salts + are used --- for example, when a realm is renamed, or if a user changes + her username, or for compatibility with Kerberos V4 (whose + string-to-key algorithm uses a null string for the salt). This string + is then fan-folded and eXclusive-ORed with itself to form an 8 byte DES + key. Before eXclusive-ORing a block, every byte is shifted one bit to + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the left to leave the lowest bit zero. The key is the "corrected" by + correcting the parity on the key, and if the key matches a 'weak' or + 'semi-weak' key as described in the DES specification, it is + eXclusive-ORed with the constant 00000000000000F0. This key is then + used to generate a DES CBC checksum on the initial string (with the + salt appended). The result of the CBC checksum is the "corrected" as + described above to form the result which is return as the key. + Pseudocode follows: + + name_to_default_salt(realm, name) { + s = realm + for(each component in name) { + s = s + component; + } + return s; + } + + key_correction(key) { + fixparity(key); + if (is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + + string_to_key(string,salt) { + + odd = 1; + s = string + salt; + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + left shift every byte in 8byteblock one bit; + tempkey = tempkey XOR 8byteblock; + } + tempkey = key_correction(tempkey); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + + 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and + without Key Derivation [Original draft by Marc Horowitz, revisions by + David Miller] + + This encryption type is based on the Triple DES cryptosystem, the + HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key + derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may not + be used in conjunction with the use of Triple DES keys. + + Algorithm Identifiers + + The des3-cbc-hmac-sha1 encryption type has been assigned the value 7. + The des3-cbc-hmac-sha1-kd encryption type, specifying the key + derivation variant of the encryption type, has been assigned the value + 16. The hmac-sha1-des3 checksum type has been assigned the value 13. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The hmac-sha1-des3-kd checksum type, specifying the key derivation + variant of the checksum, has been assigned the value 12. + + Triple DES Key Production + + The EncryptionKey value is 24 octets long. The 7 most significant bits + of each octet contain key bits, and the least significant bit is the + inverse of the xor of the key bits. + + For the purposes of key derivation, the block size is 64 bits, and the + key size is 168 bits. The 168 bits output by key derivation are + converted to an EncryptionKey value as follows. First, the 168 bits are + divided into three groups of 56 bits, which are expanded individually + into 64 bits as follows: + + 1 2 3 4 5 6 7 p + 9 10 11 12 13 14 15 p + 17 18 19 20 21 22 23 p + 25 26 27 28 29 30 31 p + 33 34 35 36 37 38 39 p + 41 42 43 44 45 46 47 p + 49 50 51 52 53 54 55 p + 56 48 40 32 24 16 8 p + + The "p" bits are parity bits computed over the data bits. The output of + the three expansions are concatenated to form the EncryptionKey value. + + When the HMAC-SHA1 of a string is computed, the key is used in the + EncryptedKey form. + + The string-to-key function is used to tranform UNICODE passwords into + DES3 keys. The DES3 string-to-key function relies on the "N-fold" + algorithm, which is detailed in [9]. The description of the N-fold + algorithm in that document is as follows: + o To n-fold a number X, replicate the input value to a length that + is the least common multiple of n and the length of X. Before each + repetition, the input is rotated to the right by 13 bit positions. + The successive n-bit chunks are added together using + 1's-complement addition (that is, addition with end-around carry) + to yield an n-bit result" + o The n-fold algorithm, as with DES string-to-key, is applied to the + password string concatenated with a salt value. The salt value is + derived in the same was as for the DES string-to-key algorithm. + For 3-key triple DES then, the operation will involve a 168-fold + of the input password string. The remainder of the string-to-key + function for DES3 is shown here in pseudocode: + + DES3string-to-key(passwordString, key) + + salt = name_to_default_salt(realm, name) + s = passwordString + salt + tmpKey1 = 168-fold(s) + parityFix(tmpKey1); + if not weakKey(tmpKey1) + /* + * Encrypt temp key in itself with a + * zero initialization vector + * + * Function signature is DES3encrypt(plain, key, iv) + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + * with cipher as the return value + */ + tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec) + /* + * Encrypt resultant temp key in itself with third component + * of first temp key as initialization vector + */ + key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2]) + parityFix(key) + if not weakKey(key) + return SUCCESS + else + return FAILURE + else + return FAILURE + + The weakKey function above is the same weakKey function used with DES + keys, but applied to each of the three single DES keys that comprise + the triple DES key. + + The lengths of UNICODE encoded character strings include the trailing + terminator character (0). + + Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd + + EncryptedData using this type must be generated as described in + [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. + The checksum algorithm is HMAC-SHA1. If the key derivation variant of + the encryption type is used, encryption key values are modified + according to the method under the Key Derivation section below. + + Unless otherwise specified, a zero IV must be used. + + If the length of the input data is not a multiple of the block size, + zero octets must be used to pad the plaintext to the next eight-octet + boundary. The counfounder must be eight random octets (one block). + + Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd + + Checksums using this type must be generated as described in + [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key + derivation variant of the checksum type is used, checksum key values + are modified according to the method under the Key Derivation section + below. + + Key Derivation + + In the Kerberos protocol, cryptographic keys are used in a number of + places. In order to minimize the effect of compromising a key, it is + desirable to use a different key for each of these places. Key + derivation [Horowitz96] can be used to construct different keys for + each operation from the keys transported on the network. For this to be + possible, a small change to the specification is necessary. + + This section specifies a profile for the use of key derivation + [Horowitz96] with Kerberos. For each place where a key is used, a ``key + usage'' must is specified for that purpose. The key, key usage, and + encryption/checksum type together describe the transformation from + plaintext to ciphertext, or plaintext to checksum. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + Key Usage Values + + This is a complete list of places keys are used in the kerberos + protocol, with key usage values and RFC 1510 section numbers: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the + client key (section 5.4.1) + 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or + application session key), encrypted with the service key + (section 5.4.2) + 3. AS-REP encrypted part (includes tgs session key or application + session key), encrypted with the client key (section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + session key (section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + authenticator subkey (section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed + with the tgs session key (sections 5.3.2, 5.4.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs + authenticator subkey), encrypted with the tgs session key + (section 5.3.2) + 8. TGS-REP encrypted part (includes application session key), + encrypted with the tgs session key (section 5.4.2) + 9. TGS-REP encrypted part (includes application session key), + encrypted with the tgs authenticator subkey (section 5.4.2) + 10. AP-REQ Authenticator cksum, keyed with the application session + key (section 5.3.2) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (section + 5.3.2) + 12. AP-REP encrypted part (includes application session subkey), + encrypted with the application session key (section 5.5.2) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by the + application (section 5.7.1) + 14. KRB-CRED encrypted part, encrypted with a key chosen by the + application (section 5.6.1) + 15. KRB-SAVE cksum, keyed with a key chosen by the application + (section 5.8.1) + 18. KRB-ERROR checksum (e-cksum in section 5.9.1) + 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) + 20. Checksum for Mandatory Ticket Extensions (appendix B.6) + 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) + + Key usage values between 1024 and 2047 (inclusive) are reserved for + application use. Applications should use even values for encryption and + odd values for checksums within this range. + + A few of these key usages need a little clarification. A service which + receives an AP-REQ has no way to know if the enclosed Ticket was part + of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for + generating a Ticket, whether it is in response to an AS- REQ or + TGS-REQ. + + There might exist other documents which define protocols in terms of + the RFC1510 encryption types or checksum types. Such documents would + not know about key usages. In order that these documents continue to be + meaningful until they are updated, key usages 1024 and 1025 must be + used to derive keys for encryption and checksums, respectively. New + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + protocols defined in terms of the Kerberos encryption and checksum + types should use their own key usages. Key usages may be registered + with IANA to avoid conflicts. Key usages must be unsigned 32 bit + integers. Zero is not permitted. + + Defining Cryptosystems Using Key Derivation + + Kerberos requires that the ciphertext component of EncryptedData be + tamper-resistant as well as confidential. This implies encryption and + integrity functions, which must each use their own separate keys. So, + for each key usage, two keys must be generated, one for encryption + (Ke), and one for integrity (Ki): + + Ke = DK(protocol key, key usage | 0xAA) + Ki = DK(protocol key, key usage | 0x55) + + where the protocol key is from the EncryptionKey from the wire + protocol, and the key usage is represented as a 32 bit integer in + network byte order. The ciphertest must be generated from the plaintext + as follows: + + ciphertext = E(Ke, confounder | plaintext | padding) | + H(Ki, confounder | plaintext | padding) + + The confounder and padding are specific to the encryption algorithm E. + + When generating a checksum only, there is no need for a confounder or + padding. Again, a new key (Kc) must be used. Checksums must be + generated from the plaintext as follows: + + Kc = DK(protocol key, key usage | 0x99) + MAC = H(Kc, plaintext) + + Note that each enctype is described by an encryption algorithm E and a + keyed hash algorithm H, and each checksum type is described by a keyed + hash algorithm H. HMAC, with an appropriate hash, is required for use + as H. + + Key Derivation from Passwords + + The well-known constant for password key derivation must be the byte + string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values + correspond to the ASCII encoding for the string "kerberos". + + 6.4. Checksums + + The following is the ASN.1 definition used for a checksum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + checksum[1] OCTET STRING + } + + cksumtype + This field indicates the algorithm used to generate the + accompanying checksum. + checksum + This field contains the checksum itself, encoded as an octet + string. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + Detailed specification of selected checksum types appear later in this + section. Negative values for the checksum type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + Checksums used by Kerberos can be classified by two properties: whether + they are collision-proof, and whether they are keyed. It is infeasible + to find two plaintexts which generate the same checksum value for a + collision-proof checksum. A key is required to perturb or initialize + the algorithm in a keyed checksum. To prevent message-stream + modification by an active attacker, unkeyed checksums should only be + used when the checksum and message will be subsequently encrypted (e.g. + the checksums defined as part of the encryption algorithms covered + earlier in this section). + + Collision-proof checksums can be made tamper-proof if the checksum + value is encrypted before inclusion in a message. In such cases, the + composition of the checksum and the encryption algorithm must be + considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using + DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed + checksums, as well as for the encrypted forms of unkeyed + collision-proof checksums, Kerberos prepends a confounder before the + checksum is calculated. + + 6.4.1. The CRC-32 Checksum (crc32) + + The CRC-32 checksum calculates a checksum based on a cyclic redundancy + check as described in ISO 3309 [ISO3309]. The resulting checksum is + four (4) octets in length. The CRC-32 is neither keyed nor + collision-proof. The use of this checksum is not recommended. An + attacker using a probabilistic chosen-plaintext attack as described in + [SG92] might be able to generate an alternative message that satisfies + the checksum. The use of collision-proof checksums is recommended for + environments where such attacks represent a significant threat. + + 6.4.2. The RSA MD4 Checksum (rsa-md4) + + The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm + [MD4-92]. The algorithm takes as input an input message of arbitrary + length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is + believed to be collision-proof. + + 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) + + The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by + prepending an 8 octet confounder before the text, applying the RSA MD4 + checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be + zero. The resulting checksum is 24 octets long (8 octets of which are + redundant). This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some weak keys' and 'semi-weak keys'; + those keys shall not be used for generating RSA-MD4 checksums for use + in Kerberos. + + The format for the checksum is described in the follow- ing diagram: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.4. The RSA MD5 Checksum (rsa-md5) + + The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm. + [MD5-92]. The algorithm takes as input an input message of arbitrary + length and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is + believed to be collision-proof. + + 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) + + The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by + prepending an 8 octet confounder before the text, applying the RSA MD5 + checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should + be zero. The resulting checksum is 24 octets long (8 octets of which + are redundant). This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some 'weak keys' and 'semi-weak keys'; + those keys shall not be used for encrypting RSA-MD5 checksums for use + in Kerberos. + + The format for the checksum is described in the following diagram: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.6. DES cipher-block chained checksum (des-mac) + + The DES-MAC checksum is computed by prepending an 8 octet confounder to + the plaintext, performing a DES CBC-mode encryption on the result using + the key and an initialization vector of zero, taking the last block of + the ciphertext, prepending the same confounder and encrypting the pair + using DES in cipher-block-chaining (CBC) mode using a a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + be zero. The resulting checksum is 128 bits (16 octets) long, 64 bits + of which are redundant. This checksum is tamper-proof and + collision-proof. + + The format for the checksum is described in the following diagram: + + +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(8) + } + + The DES specifications identify some 'weak' and 'semi-weak' keys; those + keys shall not be used for generating DES-MAC checksums for use in + Kerberos, nor shall a key be used whose variant is 'weak' or + 'semi-weak'. + + 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative + (rsa-md4-des-k) + + The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum + by applying the RSA MD4 checksum algorithm and encrypting the results + using DES in cipher-block-chaining (CBC) mode using a DES key as both + key and initialization vector. The resulting checksum is 16 octets + long. This checksum is tamper-proof and believed to be collision-proof. + Note that this checksum type is the old method for encoding the + RSA-MD4-DES checksum and it is no longer recommended. + + 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, and using the last block of the ciphertext + as the checksum value. It is keyed with an encryption key and an + initialization vector; any uses which do not specify an additional + initialization vector will use the key as both key and initialization + vector. The resulting checksum is 64 bits (8 octets) long. This + checksum is tamper-proof and collision-proof. Note that this checksum + type is the old method for encoding the DES-MAC checksum and it is no + longer recommended. The DES specifications identify some 'weak keys' + and 'semi-weak keys'; those keys shall not be used for generating + DES-MAC checksums for use in Kerberos. + + 7. Naming Constraints + + 7.1. Realm Names + + Although realm names are encoded as GeneralStrings and although a realm + can technically select any name it chooses, interoperability across + realm boundaries requires agreement on how realm names are to be + assigned, and what information they imply. + + To enforce these conventions, each realm must conform to the + conventions itself, and it must require that any realms with which + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + inter-realm keys are shared also conform to the conventions and require + the same from its neighbors. + + Kerberos realm names are case sensitive. Realm names that differ only + in the case of the characters are not equivalent. There are presently + four styles of realm names: domain, X500, other, and reserved. Examples + of each style follow: + + domain: ATHENA.MIT.EDU (example) + X500: C=US/O=OSF (example) + other: NAMETYPE:rest/of.name=without-restrictions (example) + reserved: reserved, but will not conflict with above + + Domain names must look like domain names: they consist of components + separated by periods (.) and they contain neither colons (:) nor + slashes (/). Domain names must be converted to upper case when used as + realm names. + + X.500 names contain an equal (=) and cannot contain a colon (:) before + the equal. The realm names for X.500 names will be string + representations of the names with components separated by slashes. + Leading and trailing slashes will not be included. + + Names that fall into the other category must begin with a prefix that + contains no equal (=) or period (.) and the prefix must be followed by + a colon (:) and the rest of the name. All prefixes must be assigned + before they may be used. Presently none are assigned. + + The reserved category includes strings which do not fall into the first + three categories. All names in this category are reserved. It is + unlikely that names will be assigned to this category unless there is a + very strong argument for not using the 'other' category. + + These rules guarantee that there will be no conflicts between the + various name styles. The following additional constraints apply to the + assignment of realm names in the domain and X.500 categories: the name + of a realm for the domain or X.500 formats must either be used by the + organization owning (to whom it was assigned) an Internet domain name + or X.500 name, or in the case that no such names are registered, + authority to use a realm name may be derived from the authority of the + parent realm. For example, if there is no domain name for E40.MIT.EDU, + then the administrator of the MIT.EDU realm can authorize the creation + of a realm with that name. + + This is acceptable because the organization to which the parent is + assigned is presumably the organization authorized to assign names to + its children in the X.500 and domain name systems as well. If the + parent assigns a realm name without also registering it in the domain + name or X.500 hierarchy, it is the parent's responsibility to make sure + that there will not in the future exists a name identical to the realm + name of the child unless it is assigned to the same entity as the realm + name. + + 7.2. Principal Names + + As was the case for realm names, conventions are needed to ensure that + all agree on what information is implied by a principal name. The + name-type field that is part of the principal name indicates the kind + of information implied by the name. The name-type should be treated as + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + a hint. Ignoring the name type, no two names can be the same (i.e. at + least one of the components, or the realm, must be different). The + following name types are defined: + + name-type value meaning + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) + NT-SRV-INST 2 Service and other unique instance (krbtgt) + NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) + NT-SRV-XHST 4 Service with slash-separated host name components + NT-UID 5 Unique ID + NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] + + When a name implies no information other than its uniqueness at a + particular time the name type PRINCIPAL should be used. The principal + name type should be used for users, and it might also be used for a + unique server. If the name is a unique machine generated ID that is + guaranteed never to be reassigned then the name type of UID should be + used (note that it is generally a bad idea to reassign names of any + type since stale entries might remain in access control lists). + + If the first component of a name identifies a service and the remaining + components identify an instance of the service in a server specified + manner, then the name type of SRV-INST should be used. An example of + this name type is the Kerberos ticket-granting service whose name has a + first component of krbtgt and a second component identifying the realm + for which the ticket is valid. + + If instance is a single component following the service name and the + instance identifies the host on which the server is running, then the + name type SRV-HST should be used. This type is typically used for + Internet services such as telnet and the Berkeley R commands. If the + separate components of the host name appear as successive components + following the name of the service, then the name type SRV-XHST should + be used. This type might be used to identify servers on hosts with + X.500 names where the slash (/) might otherwise be ambiguous. + + A name type of NT-X500-PRINCIPAL should be used when a name from an + X.509 certificiate is translated into a Kerberos name. The encoding of + the X.509 name as a Kerberos principal shall conform to the encoding + rules specified in RFC 2253. + + A name type of UNKNOWN should be used when the form of the name is not + known. When comparing names, a name of type UNKNOWN will match + principals authenticated with names of any type. A principal + authenticated with a name of type UNKNOWN, however, will only match + other names of type UNKNOWN. + + Names of any type with an initial component of 'krbtgt' are reserved + for the Kerberos ticket granting service. See section 8.2.3 for the + form of such names. + + 7.2.1. Name of server principals + + The principal identifier for a server on a host will generally be + composed of two parts: (1) the realm of the KDC with which the server + is registered, and (2) a two-component name of type NT-SRV-HST if the + host name is an Internet domain name or a multi-component name of type + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + NT-SRV-XHST if the name of the host is of a form such as X.500 that + allows slash (/) separators. The first component of the two- or + multi-component name will identify the service and the latter + components will identify the host. Where the name of the host is not + case sensitive (for example, with Internet domain names) the name of + the host must be lower case. If specified by the application protocol + for services such as telnet and the Berkeley R commands which run with + system privileges, the first component may be the string 'host' instead + of a service specific identifier. When a host has an official name and + one or more aliases, the official name of the host must be used when + constructing the name of the server principal. + + 8. Constants and other defined values + + 8.1. Host address types + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + The values of the types for the following addresses are chosen to match + the defined address family constants in the Berkeley Standard + Distributions of Unix. They can be found in with symbolic names AF_xxx + (where xxx is an abbreviation of the address family name). + + Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in + MSB order. The type of IPv4 addresses is two (2). + + Internet (IPv6) Addresses [Westerlund] + + IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. + The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. + The following addresses (see [RFC1884]) MUST not appear in any Kerberos + packet: + o the Unspecified Address + o the Loopback Address + o Link-Local addresses + IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. + + CHAOSnet addresses + + CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB + order. The type of CHAOSnet addresses is five (5). + + ISO addresses + + ISO addresses are variable-length. The type of ISO addresses is seven + (7). + + Xerox Network Services (XNS) addresses + + XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. + The type of XNS addresses is six (6). + + AppleTalk Datagram Delivery Protocol (DDP) addresses + + AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + network number. The first octet of the address is the node number; the + remaining two octets encode the network number in MSB order. The type + of AppleTalk DDP addresses is sixteen (16). + + DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. + The type of DECnet Phase IV addresses is twelve (12). + + Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 to 15 + characters, trailing blank (ascii char 20) filled, with a 16th octet of + 0x0. The type of Netbios addresses is 20 (0x14). + + 8.2. KDC messages + + 8.2.1. UDP/IP transport + + When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using + UDP IP transport, the client shall send a UDP datagram containing only + an encoding of the request to port 88 (decimal) at the KDC's IP + address; the KDC will respond with a reply datagram containing only an + encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to + the sending port at the sender's IP address. Kerberos servers + supporting IP transport must accept UDP requests on port 88 (decimal). + The response to a request made through UDP/IP transport must also use + UDP/IP transport. + + 8.2.2. TCP/IP transport [Westerlund,Danielsson] + + Kerberos servers (KDC's) should accept TCP requests on port 88 + (decimal) and clients should support the sending of TCP requests on + port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC over + a TCP stream, a new connection will be established for each + authentication exchange (request and response). The KRB_KDC_REP or + KRB_ERROR message will be returned to the client on the same TCP stream + that was established for the request. The response to a request made + through TCP/IP transport must also use TCP/IP transport. Implementors + should note that some extentions to the Kerberos protocol will not work + if any implementation not supporting the TCP transport is involved + (client or KDC). Implementors are strongly urged to support the TCP + transport on both the client and server and are advised that the + current notation of "should" support will likely change in the future + to must support. The KDC may close the TCP stream after sending a + response, but may leave the stream open if it expects a followup - in + which case it may close the stream at any time if resource constratints + or other factors make it desirable to do so. Care must be taken in + managing TCP/IP connections with the KDC to prevent denial of service + attacks based on the number of TCP/IP connections with the KDC that + remain open. If multiple exchanges with the KDC are needed for certain + forms of preauthentication, multiple TCP connections may be required. A + client may close the stream after receiving response, and should close + the stream if it does not expect to send followup messages. The client + must be prepared to have the stream closed by the KDC at anytime, in + which case it must simply connect again when it is ready to send + subsequent messages. + + The first four octets of the TCP stream used to transmit the request + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + request will encode in network byte order the length of the request + (KRB_KDC_REQ), and the length will be followed by the request itself. + The response will similarly be preceeded by a 4 octet encoding in + network byte order of the length of the KRB_KDC_REP or the KRB_ERROR + message and will be followed by the KRB_KDC_REP or the KRB_ERROR + response. If the sign bit is set on the integer represented by the + first 4 octets, then the next 4 octets will be read, extending the + length of the field by another 4 octets (less the sign bit which is + reserved for future expansion). + + 8.2.3. OSI transport + + During authentication of an OSI client to an OSI server, the mutual + authentication of an OSI server to an OSI client, the transfer of + credentials from an OSI client to an OSI server, or during exchange of + private or integrity checked messages, Kerberos protocol messages may + be treated as opaque objects and the type of the authentication + mechanism will be: + + OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} + + Depending on the situation, the opaque object will be an authentication + header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe + message (KRB_SAFE), a private message (KRB_PRIV), or a credentials + message (KRB_CRED). The opaque data contains an application code as + specified in the ASN.1 description for each message. The application + code may be used by Kerberos to determine the message type. + + 8.2.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: (1) the realm of the KDC issuing the TGS + ticket (2) a two-part name of type NT-SRV-INST, with the first part + "krbtgt" and the second part the name of the realm which will accept + the ticket-granting ticket. For example, a ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" + (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), + ("krbtgt", "MIT.EDU") (name). + + 8.3. Protocol constants and associated values + + The following tables list constants used in the protocol and defines + their meanings. Ranges are specified in the "specification" section + that limit the values of constants for which values are defined here. + This allows implementations to make assumptions about the maximum + values that will be received for these constants. Implementation + receiving values outside the range specified in the "specification" + section may reject the request, but they must recover cleanly. + + Encryption type etype value block size minimum pad size confounder size + NULL 0 1 0 0 + des-cbc-crc 1 8 4 8 + des-cbc-md4 2 8 0 8 + des-cbc-md5 3 8 0 8 + <reserved> 4 + des3-cbc-md5 5 8 0 8 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + <reserved> 6 + des3-cbc-sha1 7 8 0 8 + dsaWithSHA1-CmsOID 9 (pkinit) + md5WithRSAEncryption-CmsOID 10 (pkinit) + sha1WithRSAEncryption-CmsOID 11 (pkinit) + rc2CBC-EnvOID 12 (pkinit) + rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) + rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) + des-ede3-cbc-Env-OID 15 (pkinit) + des3-cbc-sha1-kd 16 (Tom Yu) + rc4-hmac 23 (swift) + rc4-hmac-exp 24 (swift) + + ENCTYPE_PK_CROSS 48 (reserved for pkcross) + <reserved> 0x8003 + + Checksum type sumtype value checksum size + CRC32 1 4 + rsa-md4 2 16 + rsa-md4-des 3 24 + des-mac 4 16 + des-mac-k 5 8 + rsa-md4-des-k 6 16 (drop rsa ?) + rsa-md5 7 16 (drop rsa ?) + rsa-md5-des 8 24 (drop rsa ?) + rsa-md5-des3 9 24 (drop rsa ?) + hmac-sha1-des3-kd 12 20 + hmac-sha1-des3 13 20 + + padata type padata-type value + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + <reserved> 4 + PA-ENC-UNIX-TIME 5 (depricated) + PA-SANDIA-SECUREID 6 + PA-SESAME 7 + PA-OSF-DCE 8 + PA-CYBERSAFE-SECUREID 9 + PA-AFS3-SALT 10 + PA-ETYPE-INFO 11 + PA-SAM-CHALLENGE 12 (sam/otp) + PA-SAM-RESPONSE 13 (sam/otp) + PA-PK-AS-REQ 14 (pkinit) + PA-PK-AS-REP 15 (pkinit) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 + PA-SAM-ETYPE-INFO 23 (sam/otp) + +data-type value form of typed-data + +<reserved> 1-21 +TD-PADATA 22 +TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS +TD-KRB-PRINCIPAL 102 +TD-KRB-REALM 103 +TD-TRUSTED-CERTIFIERS 104 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +TD-CERTIFICATE-INDEX 105 + +authorization data type ad-type value +AD-IF-RELEVANT 1 +AD-INTENDED-FOR-SERVER 2 +AD-INTENDED-FOR-APPLICATION-CLASS 3 +AD-KDC-ISSUED 4 +AD-OR 5 +AD-MANDATORY-TICKET-EXTENSIONS 6 +AD-IN-TICKET-EXTENSIONS 7 +reserved values 8-63 +OSF-DCE 64 +SESAME 65 +AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) + +Ticket Extension Types + +TE-TYPE-NULL 0 Null ticket extension +TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data +<reserved> 2 TE-TYPE-PKCROSS-KDC (I have reservations) +TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket +TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp +<reserved> 5 TE-TYPE-DEST-HOST (I have reservations) + +alternate authentication type method-type value +reserved values 0-63 +ATT-CHALLENGE-RESPONSE 64 + +transited encoding type tr-type value +DOMAIN-X500-COMPRESS 1 +reserved values all others + +Label Value Meaning or MIT code + +pvno 5 current Kerberos protocol version number + +message types + +KRB_AS_REQ 10 Request for initial authentication +KRB_AS_REP 11 Response to KRB_AS_REQ request +KRB_TGS_REQ 12 Request for authentication based on TGT +KRB_TGS_REP 13 Response to KRB_TGS_REQ request +KRB_AP_REQ 14 application request to server +KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL +KRB_SAFE 20 Safe (checksummed) application message +KRB_PRIV 21 Private (encrypted) application message +KRB_CRED 22 Private (encrypted) message to forward credentials +KRB_ERROR 30 Error response + +name types + +KRB_NT_UNKNOWN 0 Name type not known +KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users +KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) +KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) +KRB_NT_SRV_XHST 4 Service with host as remaining components +KRB_NT_UID 5 Unique ID +KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +error codes + +KDC_ERR_NONE 0 No error +KDC_ERR_NAME_EXP 1 Client's entry in database has expired +KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired +KDC_ERR_BAD_PVNO 3 Requested prot vers number not supported +KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key +KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key +KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database +KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database +KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database +KDC_ERR_NULL_KEY 9 The client or server has a null key +KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating +KDC_ERR_NEVER_VALID 11 Requested start time is later than end time +KDC_ERR_POLICY 12 KDC policy rejects request +KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option +KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type +KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type +KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type +KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type +KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked +KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked +KDC_ERR_TGT_REVOKED 20 TGT has been revoked +KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later +KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later +KDC_ERR_KEY_EXPIRED 23 Password has expired - change password +KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid +KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] +KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match +KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only +KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path +KDC_ERR_SVC_UNAVAILABLE 29 A service is not available +KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed +KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired +KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid +KRB_AP_ERR_REPEAT 34 Request is a replay +KRB_AP_ERR_NOT_US 35 The ticket isn't for us +KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match +KRB_AP_ERR_SKEW 37 Clock skew too great +KRB_AP_ERR_BADADDR 38 Incorrect net address +KRB_AP_ERR_BADVERSION 39 Protocol version mismatch +KRB_AP_ERR_MSG_TYPE 40 Invalid msg type +KRB_AP_ERR_MODIFIED 41 Message stream modified +KRB_AP_ERR_BADORDER 42 Message out of order +KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available +KRB_AP_ERR_NOKEY 45 Service key not available +KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed +KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction +KRB_AP_ERR_METHOD 48 Alternative authentication method required +KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message +KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message +KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path +KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP +KRB_ERR_GENERIC 60 Generic error (description in e-text) +KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation +KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) +KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) +KDC_ERROR_INVALID_SIG 64 (pkinit) +KDC_ERR_KEY_TOO_WEAK 65 (pkinit) + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + +KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) +KRB_AP_ERR_NO_TGT 67 (user-to-user) +KDC_ERR_WRONG_REALM 68 (user-to-user) +KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) +KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) +KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) +KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) +KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) +KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) +KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) +KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) + + 9. Interoperability requirements + + Version 5 of the Kerberos protocol supports a myriad of options. Among + these are multiple encryption and checksum types, alternative encoding + schemes for the transited field, optional mechanisms for + pre-authentication, the handling of tickets with no addresses, options + for mutual authentication, user to user authentication, support for + proxies, forwarding, postdating, and renewing tickets, the format of + realm names, and the handling of authorization data. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration which must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + + 9.1. Specification 2 + + This section defines the second specification of these options. + Implementations which are configured in this way can be said to support + Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) + may be found in RFC1510. + + Transport + + TCP/IP and UDP/IP transport must be supported by KDCs claiming + conformance to specification 2. Kerberos clients claiming conformance + to specification 2 must support UDP/IP transport for messages with the + KDC and should support TCP/IP transport. + + Encryption and checksum methods + + The following encryption and checksum mechanisms must be supported. + Implementations may support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them: This list is to be determined. + + Encryption: DES-CBC-MD5, one triple des variant (tbd) + Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd) + + Realm Names + + All implementations must understand hierarchical realms in both the + Internet Domain and the X.500 style. When a ticket granting ticket for + an unknown realm is requested, the KDC must be able to determine the + names of the intermediate realms between the KDCs realm and the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + requested realm. + + Transited field encoding + + DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. + Alternative encodings may be supported, but they may be used only when + that encoding is supported by ALL intermediate realms. + + Pre-authentication methods + + The TGS-REQ method must be supported. The TGS-REQ method is not used on + the initial request. The PA-ENC-TIMESTAMP method must be supported by + clients but whether it is enabled by default may be determined on a + realm by realm basis. If not used in the initial request and the error + KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an + acceptable method, the client should retry the initial request using + the PA-ENC-TIMESTAMP preauthentication method. Servers need not support + the PA-ENC-TIMESTAMP method, but if not supported the server should + ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a + request. + + Mutual authentication + + Mutual authentication (via the KRB_AP_REP message) must be supported. + + Ticket addresses and flags + + All KDC's must pass on tickets that carry no addresses (i.e. if a TGT + contains no addresses, the KDC will return derivative tickets), but + each realm may set its own policy for issuing such tickets, and each + application server will set its own policy with respect to accepting + them. + + Proxies and forwarded tickets must be supported. Individual realms and + application servers can set their own policy on when such tickets will + be accepted. + + All implementations must recognize renewable and postdated tickets, but + need not actually implement them. If these options are not supported, + the starttime and endtime in the ticket shall specify a ticket's entire + useful life. When a postdated ticket is decoded by a server, all + implementations shall make the presence of the postdated flag visible + to the calling server. + + User-to-user authentication + + Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC + option) must be provided by implementations, but individual realms may + decide as a matter of policy to reject such requests on a per-principal + or realm-wide basis. + + Authorization data + + Implementations must pass all authorization data subfields from + ticket-granting tickets to any derivative tickets unless directed to + suppress a subfield as part of the definition of that registered + subfield type (it is never incorrect to pass on a subfield, and no + registered subfield types presently specify suppression at the KDC). + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + Implementations must make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + + Constant ranges + + All protocol constants are constrained to 32 bit (signed) values unless + further constrained by the protocol definition. This limit is provided + to allow implementations to make assumptions about the maximum values + that will be received for these constants. Implementation receiving + values outside this range may reject the request, but they must recover + cleanly. + + 9.2. Recommended KDC values + + Following is a list of recommended values for a KDC implementation, + based on the list of suggested configuration constants (see section + 4.4). + + minimum lifetime 5 minutes + maximum renewable lifetime 1 week + maximum ticket lifetime 1 day + empty addresses only when suitable restrictions appear + in authorization data + proxiable, etc. Allowed. + + 10. REFERENCES + + [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- + cation Service for Computer Networks," IEEE Communica- + tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). + + [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. + Saltzer, Section E.2.1: Kerberos Authentication and + Authorization System, M.I.T. Project Athena, Cambridge, + Massachusetts (December 21, 1987). + + [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- + beros: An Authentication Service for Open Network Sys- + tems," pp. 191-202 in Usenix Conference Proceedings, + Dallas, Texas (February, 1988). + + [NS78] Roger M. Needham and Michael D. Schroeder, "Using + Encryption for Authentication in Large Networks of Com- + puters," Communications of the ACM, Vol. 21(12), + pp. 993-999 (December, 1978). + + [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- + stamps in Key Distribution Protocols," Communications + of the ACM, Vol. 24(8), pp. 533-536 (August 1981). + + [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, + "The Evolution of the Kerberos Authentication Service," + in an IEEE Computer Society Text soon to be published + (June 1992). + + [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in Proceedings of + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the 13th International Conference on Distributed Com- + puting Systems, Pittsburgh, PA (May, 1993). + + [DS90] Don Davis and Ralph Swick, "Workstation Services and + Kerberos Authentication at Project Athena," Technical + Memorandum TM-424, MIT Laboratory for Computer Science + (February 1990). + + [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- + merfeld, and K. Raeburn, Section E.1: Service Manage- + ment System, M.I.T. Project Athena, Cambridge, Mas- + sachusetts (1987). + + [X509-88] CCITT, Recommendation X.509: The Directory Authentica- + tion Framework, December 1988. + + [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password + Guessing Attacks, Open Software Foundation DCE Request + for Comments 26 (December 1992). + + [DES77] National Bureau of Standards, U.S. Department of Com- + merce, "Data Encryption Standard," Federal Information + Processing Standards Publication 46, Washington, DC + (1977). + + [DESM80] National Bureau of Standards, U.S. Department of Com- + merce, "DES Modes of Operation," Federal Information + Processing Standards Publication 81, Springfield, VA + (December 1980). + + [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message + Integrity in Cryptographic Protocols," in Proceedings + of the IEEE Symposium on Research in Security and + Privacy, Oakland, California (May 1992). + + [IS3309] International Organization for Standardization, "ISO + Information Processing Systems - Data Communication - + High-Level Data Link Control Procedure - Frame Struc- + ture," IS 3309 (October 1984). 3rd Edition. + + [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC + 1320, MIT Laboratory for Computer Science (April + 1992). + + [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC + 1321, MIT Laboratory for Computer Science (April + 1992). + + [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication," Working Draft + draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). + + [Horowitz96] Horowitz, M., "Key Derivation for Authentication, + Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, + August 1998. + + [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- + horowitz-kerb-key-derivation-01.txt, September 1998. + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac- + md5-01.txt, August, 1996. + + A. Pseudo-code for protocol processing + + This appendix provides pseudo-code describing how the messages are to + be constructed and interpreted by clients and servers. + + A.1. KRB_AS_REQ generation + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_AS_REQ */ + + if(pa_enc_timestamp_required) then + request.padata.padata-type = PA-ENC-TIMESTAMP; + get system_time; + padata-body.patimestamp,pausec = system_time; + encrypt padata-body into request.padata.padata-value + using client.key; /* derived from password */ + endif + + body.kdc-options := users's preferences; + body.cname := user's name; + body.realm := user's realm; + body.sname := service's name; /* usually "krbtgt", + "localrealm" */ + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + omit body.enc-authorization-data; + request.req-body := body; + + kerberos := lookup(name of local kerberos server (or servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.2. KRB_AS_REQ verification and KRB_AS_REP generation + + decode message into req; + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + client := lookup(req.cname,req.realm); + server := lookup(req.sname,req.realm); + + get system_time; + kdc_time := system_time.seconds; + + if (!client) then + /* no client in Database */ + error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); + endif + if (!server) then + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + + if(client.pa_enc_timestamp_required and + pa_enc_timestamp not present) then + error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); + endif + + if(pa_enc_timestamp present) then + decrypt req.padata-value into decrypted_enc_timestamp + using client.key; + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + if(decrypted_enc_timestamp is not within allowable skew) + then + error_out(KDC_ERR_PREAUTH_FAILED); + endif + if(decrypted_enc_timestamp and usec is replay) + error_out(KDC_ERR_PREAUTH_FAILED); + endif + add decrypted_enc_timestamp and usec to replay cache; + endif + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := req.srealm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + if (req.kdc-options.FORWARDABLE is set) then + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.PROXIABLE is set) then + set new_tkt.flags.PROXIABLE; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + set new_tkt.flags.MAY-POSTDATE; + endif + if ((req.kdc-options.RENEW is set) or + (req.kdc-options.VALIDATE is set) or + (req.kdc-options.PROXY is set) or + (req.kdc-options.FORWARDED is set) or + (req.kdc-options.ENC-TKT-IN-SKEY is set)) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.session := random_session_key(); + new_tkt.cname := req.cname; + new_tkt.crealm := req.crealm; + new_tkt.transited := empty_transited_field(); + + new_tkt.authtime := kdc_time; + + if (req.kdc-options.POSTDATED is set) then + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + new_tkt.starttime := req.from; + else + omit new_tkt.starttime; /* treated as authtime when omitted */ + endif + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till)) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := req.till; + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if (req.kdc-options.RENEWABLE is set) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm); + else + omit new_tkt.renew-till; /* only present if RENEWABLE */ + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + endif + + if (req.addresses) then + new_tkt.caddr := req.addresses; + else + omit new_tkt.caddr; + endif + + new_tkt.authorization_data := empty_authorization_data(); + + encode to-be-encrypted part of ticket into OCTET STRING; + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, server.p_kvno; + + /* Start processing the response */ + + resp.pvno := 5; + resp.msg-type := KRB_AS_REP; + resp.cname := req.cname; + resp.crealm := req.realm; + resp.ticket := new_tkt; + + resp.key := new_tkt.session; + resp.last-req := fetch_last_request_info(client); + resp.nonce := req.nonce; + resp.key-expiration := client.expiration; + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + resp.realm := new_tkt.realm; + resp.sname := new_tkt.sname; + + resp.caddr := new_tkt.caddr; + + encode body of reply into OCTET STRING; + + resp.enc-part := encrypt OCTET STRING + using use_etype, client.key, client.p_kvno; + send(resp); + + A.3. KRB_AS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then + set pa_enc_timestamp_required; + goto KRB_AS_REQ; + endif + process_error(resp); + return; + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + /* On error, discard the response, and zero the session key */ + /* from the response immediately */ + + key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, + resp.padata); + unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and key; + zero(key); + + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + if near(resp.princ_exp) then + print(warning message); + endif + save_for_later(ticket,session,client,server,times,flags); + + A.4. KRB_AS_REP and KRB_TGS_REP common checks + + if (decryption_error() or + (req.cname != resp.cname) or + (req.realm != resp.crealm) or + (req.sname != resp.sname) or + (req.realm != resp.realm) or + (req.nonce != resp.nonce) or + (req.addresses != resp.caddr)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + /* make sure no flags are set that shouldn't be, and that all that */ + /* should be are set */ + if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.from = 0) and + (resp.starttime is not within allowable skew)) then + destroy resp.key; + return KRB_AP_ERR_SKEW; + endif + if ((req.from != 0) and (req.from != resp.starttime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.till != 0) and (resp.endtime > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (req.rtime != 0) and (resp.renew-till > req.rtime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if ((req.kdc-options.RENEWABLE-OK is set) and + (resp.flags.RENEWABLE) and + (req.till != 0) and + (resp.renew-till > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + A.5. KRB_TGS_REQ generation + + /* Note that make_application_request might have to recursivly */ + /* call this routine to get the appropriate ticket-granting ticket */ + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_TGS_REQ */ + + body.kdc-options := users's preferences; + /* If the TGT is not for the realm of the end-server */ + /* then the sname will be for a TGT for the end-realm */ + /* and the realm of the requested ticket (body.realm) */ + /* will be that of the TGS to which the TGT we are */ + /* sending applies */ + body.sname := service's name; + body.realm := service's realm; + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + + body.enc-authorization-data := user-supplied data; + if (body.kdc-options.ENC-TKT-IN-SKEY) then + body.additional-tickets_ticket := second TGT; + endif + + request.req-body := body; + check := generate_checksum (req.body,checksumtype); + + request.padata[0].padata-type := PA-TGS-REQ; + request.padata[0].padata-value := create a KRB_AP_REQ using + the TGT and checksum + + /* add in any other padata as required/supplied */ + + kerberos := lookup(name of local kerberose server (or servers)); + send(packet,kerberos); + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation + + /* note that reading the application request requires first + determining the server for which a ticket was issued, and + choosing the correct key for decryption. The name of the + server appears in the plaintext part of the ticket. */ + + if (no KRB_AP_REQ in req.padata) then + error_out(KDC_ERR_PADATA_TYPE_NOSUPP); + endif + verify KRB_AP_REQ in req.padata; + + /* Note that the realm in which the Kerberos server is + operating is determined by the instance from the + ticket-granting ticket. The realm in the ticket-granting + ticket is the realm under which the ticket granting + ticket was issued. It is possible for a single Kerberos + server to support more than one realm. */ + + auth_hdr := KRB_AP_REQ; + tgt := auth_hdr.ticket; + + if (tgt.sname is not a TGT for local realm and is not req.sname) + then + error_out(KRB_AP_ERR_NOT_US); + + realm := realm_tgt_is_for(tgt); + + decode remainder of request; + + if (auth_hdr.authenticator.cksum is missing) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + if (auth_hdr.authenticator.cksum type is not supported) then + error_out(KDC_ERR_SUMTYPE_NOSUPP); + endif + if (auth_hdr.authenticator.cksum is not both collision-proof + and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + set computed_checksum := checksum(req); + if (computed_checksum != auth_hdr.authenticatory.cksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + server := lookup(req.sname,realm); + + if (!server) then + if (is_foreign_tgt_name(req.sname)) then + server := best_intermediate_tgs(req.sname); + else + /* no server in Database */ + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + endif + + session := generate_random_session_key(); + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := realm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + new_tkt.caddr := tgt.caddr; + resp.caddr := NULL; /* We only include this if they change */ + if (req.kdc-options.FORWARDABLE is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.FORWARDED is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDED; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + if (tgt.flags.FORWARDED is set) then + set new_tkt.flags.FORWARDED; + endif + + if (req.kdc-options.PROXIABLE is set) then + if (tgt.flags.PROXIABLE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXIABLE; + endif + if (req.kdc-options.PROXY is set) then + if (tgt.flags.PROXIABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXY; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + if (tgt.flags.MAY-POSTDATE is reset) + error_out(KDC_ERR_BADOPTION); + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + endif + set new_tkt.flags.MAY-POSTDATE; + endif + if (req.kdc-options.POSTDATED is set) then + if (tgt.flags.MAY-POSTDATE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + new_tkt.starttime := req.from; + endif + + if (req.kdc-options.VALIDATE is set) then + if (tgt.flags.INVALID is reset) then + error_out(KDC_ERR_POLICY); + endif + if (tgt.starttime > kdc_time) then + error_out(KRB_AP_ERR_NYV); + endif + if (check_hot_list(tgt)) then + error_out(KRB_AP_ERR_REPEAT); + endif + tkt := tgt; + reset new_tkt.flags.INVALID; + endif + + if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, + and those already processed) is set) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.authtime := tgt.authtime; + + if (req.kdc-options.RENEW is set) then + /* Note that if the endtime has already passed, the ticket would */ + /* have been rejected in the initial authentication stage, so */ + /* there is no need to check again here */ + if (tgt.flags.RENEWABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + if (tgt.renew-till < kdc_time) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + tkt := tgt; + new_tkt.starttime := kdc_time; + old_life := tgt.endttime - tgt.starttime; + new_tkt.endtime := min(tgt.renew-till, + new_tkt.starttime + old_life); + else + new_tkt.starttime := kdc_time; + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + new_tkt.endtime := min(till, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm, + tgt.endtime); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till) and + (tgt.flags.RENEWABLE is set) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := min(req.till, tgt.renew-till); + endif + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (tgt.flags.RENEWABLE is set)) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm, + tgt.renew-till); + else + new_tkt.renew-till := OMIT; /* leave the + renew-till field out */ + endif + if (req.enc-authorization-data is present) then + decrypt req.enc-authorization-data into + decrypted_authorization_data + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + endif + new_tkt.authorization_data := + req.auth_hdr.ticket.authorization_data + + decrypted_authorization_data; + + new_tkt.key := session; + new_tkt.crealm := tgt.crealm; + new_tkt.cname := req.auth_hdr.ticket.cname; + + if (realm_tgt_is_for(tgt) := tgt.realm) then + /* tgt issued by local realm */ + new_tkt.transited := tgt.transited; + else + /* was issued for this realm by some other realm */ + if (tgt.transited.tr-type not supported) then + error_out(KDC_ERR_TRTYPE_NOSUPP); + endif + new_tkt.transited := + compress_transited(tgt.transited + tgt.realm) + /* Don't check tranited field if TGT for foreign realm, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + * or requested not to check */ + if (is_not_foreign_tgt_name(new_tkt.server) + && req.kdc-options.DISABLE-TRANSITED-CHECK not + set) then + /* Check it, so end-server does not have to + * but don't fail, end-server may still accept it */ + if (check_transited_field(new_tkt.transited) == OK) + set new_tkt.flags.TRANSITED-POLICY-CHECKED; + endif + endif + endif + + encode encrypted part of new_tkt into OCTET STRING; + if (req.kdc-options.ENC-TKT-IN-SKEY is set) then + if (server not specified) then + server = req.second_ticket.client; + endif + if ((req.second_ticket is not a TGT) or + (req.second_ticket.client != server)) then + error_out(KDC_ERR_POLICY); + endif + + new_tkt.enc-part := encrypt OCTET STRING using + using etype_for_key(second-ticket.key), + second-ticket.key; + else + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), + server.key, server.p_kvno; + endif + + resp.pvno := 5; + resp.msg-type := KRB_TGS_REP; + resp.crealm := tgt.crealm; + resp.cname := tgt.cname; + resp.ticket := new_tkt; + + resp.key := session; + resp.nonce := req.nonce; + resp.last-req := fetch_last_request_info(client); + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + omit resp.key-expiration; + + resp.sname := new_tkt.sname; + resp.realm := new_tkt.realm; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + encode body of reply into OCTET STRING; + + if (req.padata.authenticator.subkey) + resp.enc-part := encrypt OCTET STRING using use_etype, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + req.padata.authenticator.subkey; + else resp.enc-part := encrypt OCTET STRING using + use_etype, tgt.key; + + send(resp); + + A.7. KRB_TGS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key from + the response immediately */ + + if (req.padata.authenticator.subkey) + unencrypted part of resp := decode of decrypt of + resp.enc-part + using resp.enc-part.etype and subkey; + else unencrypted part of resp := decode of decrypt of + resp.enc-part + using resp.enc-part.etype and + tgt's session key; + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + check authorization_data as necessary; + save_for_later(ticket,session,client,server,times,flags); + + A.8. Authenticator generation + + body.authenticator-vno := authenticator vno; /* = 5 */ + body.cname, body.crealm := client name; + if (supplying checksum) then + body.cksum := checksum; + endif + get system_time; + body.ctime, body.cusec := system_time; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + A.9. KRB_AP_REQ generation + + obtain ticket and session_key from cache; + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REQ */ + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (desired(MUTUAL_AUTHENTICATION)) then + set packet.ap-options.MUTUAL-REQUIRED; + else + reset packet.ap-options.MUTUAL-REQUIRED; + endif + if (using session key for ticket) then + set packet.ap-options.USE-SESSION-KEY; + else + reset packet.ap-options.USE-SESSION-KEY; + endif + packet.ticket := ticket; /* ticket */ + generate authenticator; + encode authenticator into OCTET STRING; + encrypt OCTET STRING into packet.authenticator using session_key; + + A.10. KRB_AP_REQ verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REQ) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.ticket.tkt_vno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.ap_options.USE-SESSION-KEY is set) then + retrieve session key from ticket-granting ticket for + packet.ticket.{sname,srealm,enc-part.etype}; + else + retrieve service key for + packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; + endif + if (no_key_available) then + if (cannot_find_specified_skvno) then + error_out(KRB_AP_ERR_BADKEYVER); + else + error_out(KRB_AP_ERR_NOKEY); + endif + endif + decrypt packet.ticket.enc-part into decr_ticket using + retrieved key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + decrypt packet.authenticator into decr_authenticator + using decr_ticket.key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (decr_authenticator.{cname,crealm} != + decr_ticket.{cname,crealm}) then + error_out(KRB_AP_ERR_BADMATCH); + endif + if (decr_ticket.caddr is present) then + if (sender_address(packet) is not in + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + decr_ticket.caddr) then + error_out(KRB_AP_ERR_BADADDR); + endif + elseif (application requires addresses) then + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(decr_authenticator.ctime, + decr_authenticator.cusec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then + error_out(KRB_AP_ERR_REPEAT); + endif + save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); + get system_time; + if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or + (decr_ticket.flags.INVALID is set)) then + /* it hasn't yet become valid */ + error_out(KRB_AP_ERR_TKT_NYV); + endif + if (system_time-decr_ticket.endtime > CLOCK_SKEW) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + if (decr_ticket.transited) then + /* caller may ignore the TRANSITED-POLICY-CHECKED and do + * check anyway */ + if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then + if (check_transited_field(decr_ticket.transited) then + error_out(KDC_AP_PATH_NOT_ACCPETED); + endif + endif + endif + /* caller must check decr_ticket.flags for any pertinent details */ + return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); + + A.11. KRB_AP_REP generation + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REP */ + + body.ctime := packet.ctime; + body.cusec := packet.cusec; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part; + + A.12. KRB_AP_REP verification + + receive packet; + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REP) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + cleartext := decrypt(packet.enc-part) using ticket's session key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (cleartext.ctime != authenticator.ctime) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.cusec != authenticator.cusec) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.subkey is present) then + save cleartext.subkey for future use; + endif + if (cleartext.seq-number is present) then + save cleartext.seq-number for future verifications; + endif + return(AUTHENTICATION_SUCCEEDED); + + A.13. KRB_SAFE generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_SAFE */ + + body.user-data := buffer; /* DATA */ + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + checksum.cksumtype := checksum type; + compute checksum over body; + checksum.checksum := checksum value; /* checksum.checksum */ + packet.cksum := checksum; + packet.safe-body := body; + + A.14. KRB_SAFE verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_SAFE) then + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.checksum.cksumtype is not both collision-proof + and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + if (safe_priv_common_checks_ok(packet)) then + set computed_checksum := checksum(packet.body); + if (computed_checksum != packet.checksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + return (packet, PACKET_IS_GENUINE); + else + return common_checks_error; + endif + + A.15. KRB_SAFE and KRB_PRIV common checks + + if (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (((packet.timestamp is present) and + (not in_clock_skew(packet.timestamp,packet.usec))) or + (packet.timestamp is not present and timestamp expected)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + + if (((packet.seq-number is present) and + ((not in_sequence(packet.seq-number)))) or + (packet.seq-number is not present and sequence expected)) then + error_out(KRB_AP_ERR_BADORDER); + endif + if (packet.timestamp not present and packet.seq-number + not present) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + save_identifier(packet.{timestamp,usec,s-address}, + sender_principal(packet)); + + return PACKET_IS_OK; + + A.16. KRB_PRIV generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_PRIV */ + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + packet.enc-part.etype := encryption type; + + body.user-data := buffer; + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher; + + A.17. KRB_PRIV verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_PRIV) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + + if (safe_priv_common_checks_ok(cleartext)) then + return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); + else + return common_checks_error; + endif + + A.18. KRB_CRED generation + + invoke KRB_TGS; /* obtain tickets to be provided to peer */ + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_CRED */ + + for (tickets[n] in tickets to be forwarded) do + packet.tickets[n] = tickets[n].ticket; + done + + packet.enc-part.etype := encryption type; + + for (ticket[n] in tickets to be forwarded) do + body.ticket-info[n].key = tickets[n].session; + body.ticket-info[n].prealm = tickets[n].crealm; + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + body.ticket-info[n].pname = tickets[n].cname; + body.ticket-info[n].flags = tickets[n].flags; + body.ticket-info[n].authtime = tickets[n].authtime; + body.ticket-info[n].starttime = tickets[n].starttime; + body.ticket-info[n].endtime = tickets[n].endtime; + body.ticket-info[n].renew-till = tickets[n].renew-till; + body.ticket-info[n].srealm = tickets[n].srealm; + body.ticket-info[n].sname = tickets[n].sname; + body.ticket-info[n].caddr = tickets[n].caddr; + done + + get system_time; + body.timestamp, body.usec := system_time; + + if (using nonce) then + body.nonce := nonce; + endif + + if (using s-address) then + body.s-address := sender host addresses; + endif + if (limited recipients) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher + using negotiated encryption key; + + A.19. KRB_CRED verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_CRED) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if ((packet.r-address is present or required) and + (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(packet.timestamp,packet.usec)) then + error_out(KRB_AP_ERR_SKEW); + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + if (packet.nonce is required or present) and + (packet.nonce != expected-nonce) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + for (ticket[n] in tickets that were forwarded) do + save_for_later(ticket[n],key[n],principal[n], + server[n],times[n],flags[n]); + return + + A.20. KRB_ERROR generation + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_ERROR */ + + get system_time; + packet.stime, packet.susec := system_time; + packet.realm, packet.sname := server name; + + if (client time available) then + packet.ctime, packet.cusec := client_time; + endif + packet.error-code := error code; + if (client name available) then + packet.cname, packet.crealm := client name; + endif + if (error text available) then + packet.e-text := error text; + endif + if (error data available) then + packet.e-data := error data; + endif + + B. Definition of common authorization data elements + + This appendix contains the definitions of common authorization data + elements. These common authorization data elements are recursivly + defined, meaning the ad-data for these types will itself contain a + sequence of authorization data whose interpretation is affected by the + encapsulating element. Depending on the meaning of the encapsulating + element, the encapsulated elements may be ignored, might be interpreted + as issued directly by the KDC, or they might be stored in a separate + plaintext part of the ticket. The types of the encapsulating elements + are specified as part of the Kerberos specification because the + behavior based on these values should be understood across + implementations whereas other elements need only be understood by the + applications which they affect. + + In the definitions that follow, the value of the ad-type for the + element will be specified in the subsection number, and the value of + the ad-data will be as shown in the ASN.1 structure that follows the + subsection heading. + + B.1. If relevant + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + AD-IF-RELEVANT AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that do + not understand the type of an element embedded within the if-relevant + element may ignore the uninterpretable element. This element promotes + interoperability across implementations which may have local extensions + for authorization. + + B.2. Intended for server + + AD-INTENDED-FOR-SERVER SEQUENCE { + intended-server[0] SEQUENCE OF PrincipalName + elements[1] AuthorizationData + } + + AD elements encapsulated within the intended-for-server element may be + ignored if the application server is not in the list of principal names + of intended servers. Further, a KDC issuing a ticket for an application + server can remove this element if the application server is not in the + list of intended servers. + + Application servers should check for their principal name in the + intended-server field of this element. If their principal name is not + found, this element should be ignored. If found, then the encapsulated + elements should be evaluated in the same manner as if they were present + in the top level authorization data field. Applications and application + servers that do not implement this element should reject tickets that + contain authorization data elements of this type. + + B.3. Intended for application class + + AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { + intended-application-class[0] SEQUENCE OF GeneralString elements[1] + AuthorizationData } AD elements encapsulated within the + intended-for-application-class element may be ignored if the + application server is not in one of the named classes of application + servers. Examples of application server classes include "FILESYSTEM", + and other kinds of servers. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.4. KDC Issued + + AD-KDCIssued SEQUENCE { + ad-checksum[0] Checksum, + i-realm[1] Realm OPTIONAL, + i-sname[2] PrincipalName OPTIONAL, + elements[3] AuthorizationData. + } + + ad-checksum + A checksum over the elements field using a cryptographic checksum + method that is identical to the checksum used to protect the + ticket itself (i.e. using the same hash function and the same + encryption algorithm used to encrypt the ticket) and using a key + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + derived from the same key used to protect the ticket. + i-realm, i-sname + The name of the issuing principal if different from the KDC + itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal and it + allows this KDC to notify the application server of the validity + of those elements. + elements + A sequence of authorization data elements issued by the KDC. + The KDC-issued ad-data field is intended to provide a means for + Kerberos principal credentials to embed within themselves privilege + attributes and other mechanisms for positive authorization, amplifying + the priveleges of the principal beyond what can be done using a + credentials without such an a-data element. + + This can not be provided without this element because the definition of + the authorization-data field allows elements to be added at will by the + bearer of a TGT at the time that they request service tickets and + elements may also be added to a delegated ticket by inclusion in the + authenticator. + + For KDC-issued elements this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the server's + key (the same key used to encrypt the ticket - or a key derived from + that key). Elements encapsulated with in the KDC-issued element will be + ignored by the application server if this "signature" is not present. + Further, elements encapsulated within this element from a ticket + granting ticket may be interpreted by the KDC, and used as a basis + according to policy for including new signed elements within derivative + tickets, but they will not be copied to a derivative ticket directly. + If they are copied directly to a derivative ticket by a KDC that is not + aware of this element, the signature will not be correct for the + application ticket elements, and the field will be ignored by the + application server. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.5. And-Or + + AD-AND-OR SEQUENCE { + condition-count[0] INTEGER, + elements[1] AuthorizationData + } + + When restrictive AD elements encapsulated within the and-or element are + encountered, only the number specified in condition-count of the + encapsulated conditions must be met in order to satisfy this element. + This element may be used to implement an "or" operation by setting the + condition-count field to 1, and it may specify an "and" operation by + setting the condition count to the number of embedded elements. + Application servers that do not implement this element must reject + tickets that contain authorization data elements of this type. + + B.6. Mandatory ticket extensions + + AD-Mandatory-Ticket-Extensions Checksum + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + An authorization data element of type mandatory-ticket-extensions + specifies a collision-proof checksum using the same hash algorithm used + to protect the integrity of the ticket itself. This checksum will be + calculated over an individual extension field. If there are more than + one extension, multiple Mandatory-Ticket-Extensions authorization data + elements may be present, each with a checksum for a different extension + field. This restriction indicates that the ticket should not be + accepted if a ticket extension is not present in the ticket for which + the checksum does not match that checksum specified in the + authorization data element. Application servers that do not implement + this element must reject tickets that contain authorization data + elements of this type. + + B.7. Authorization Data in ticket extensions + + AD-IN-Ticket-Extensions Checksum + + An authorization data element of type in-ticket-extensions specifies a + collision-proof checksum using the same hash algorithm used to protect + the integrity of the ticket itself. This checksum is calculated over a + separate external AuthorizationData field carried in the ticket + extensions. Application servers that do not implement this element must + reject tickets that contain authorization data elements of this type. + Application servers that do implement this element will search the + ticket extensions for authorization data fields, calculate the + specified checksum over each authorization data field and look for one + matching the checksum in this in-ticket-extensions element. If not + found, then the ticket must be rejected. If found, the corresponding + authorization data elements will be interpreted in the same manner as + if they were contained in the top level authorization data field. + + Note that if multiple external authorization data fields are present in + a ticket, each will have a corresponding element of type + in-ticket-extensions in the top level authorization data field, and the + external entries will be linked to the corresponding element by their + checksums. + + C. Definition of common ticket extensions + + This appendix contains the definitions of common ticket extensions. + Support for these extensions is optional. However, certain extensions + have associated authorization data elements that may require rejection + of a ticket containing an extension by application servers that do not + implement the particular extension. Other extensions have been defined + beyond those described in this specification. Such extensions are + described elswhere and for some of those extensions the reserved number + may be found in the list of constants. + + It is known that older versions of Kerberos did not support this field, + and that some clients will strip this field from a ticket when they + parse and then reassemble a ticket as it is passed to the application + servers. The presence of the extension will not break such clients, but + any functionaly dependent on the extensions will not work when such + tickets are handled by old clients. In such situations, some + implementation may use alternate methods to transmit the information in + the extensions field. + + C.1. Null ticket extension + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + TE-NullExtension OctetString -- The empty Octet String + + The te-data field in the null ticket extension is an octet string of + lenght zero. This extension may be included in a ticket granting ticket + so that the KDC can determine on presentation of the ticket granting + ticket whether the client software will strip the extensions field. + + C.2. External Authorization Data + + TE-ExternalAuthorizationData AuthorizationData + + The te-data field in the external authorization data ticket extension + is field of type AuthorizationData containing one or more authorization + data elements. If present, a corresponding authorization data element + will be present in the primary authorization data for the ticket and + that element will contain a checksum of the external authorization data + ticket extension. + ----------------------------------------------------------------------- + [TM] Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). No commercial use of these + trademarks may be made without prior written permission of MIT. + + [1] Note, however, that many applications use Kerberos' functions only + upon the initiation of a stream-based network connection. Unless an + application subsequently provides integrity protection for the data + stream, the identity verification applies only to the initiation of the + connection, and does not guarantee that subsequent messages on the + connection originate from the same principal. + + [2] Secret and private are often used interchangeably in the + literature. In our usage, it takes two (or more) to share a secret, + thus a shared DES key is a secret key. Something is only private when + no one but its owner knows it. Thus, in public key cryptosystems, one + has a public and a private key. + + [3] Of course, with appropriate permission the client could arrange + registration of a separately-named prin- cipal in a remote realm, and + engage in normal exchanges with that realm's services. However, for + even small numbers of clients this becomes cumbersome, and more + automatic methods as described here are necessary. + + [4] Though it is permissible to request or issue tick- ets with no + network addresses specified. + + [5] The password-changing request must not be honored unless the + requester can provide the old password (the user's current secret key). + Otherwise, it would be possible for someone to walk up to an unattended + ses- sion and change another user's password. + + [6] To authenticate a user logging on to a local system, the + credentials obtained in the AS exchange may first be used in a TGS + exchange to obtain credentials for a local server. Those credentials + must then be verified by a local server through successful completion + of the Client/Server exchange. + + [7] "Random" means that, among other things, it should be impossible to + guess the next session key based on knowledge of past session keys. + This can only be achieved in a pseudo-random number generator if it is + based on cryptographic principles. It is more desirable to use a truly + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + random number generator, such as one based on measurements of random + physical phenomena. + + [8] Tickets contain both an encrypted and unencrypted portion, so + cleartext here refers to the entire unit, which can be copied from one + message and replayed in another without any cryptographic skill. + + [9] Note that this can make applications based on unreliable transports + difficult to code correctly. If the transport might deliver duplicated + messages, either a new authenticator must be generated for each retry, + or the application server must match requests and replies and replay + the first reply in response to a detected duplicate. + + [10] This is used for user-to-user authentication as described in [8]. + + [11] Note that the rejection here is restricted to authenticators from + the same principal to the same server. Other client principals + communicating with the same server principal should not be have their + authenticators rejected if the time and microsecond fields happen to + match some other client's authenticator. + + [12] In the Kerberos version 4 protocol, the timestamp in the reply was + the client's timestamp plus one. This is not necessary in version 5 + because version 5 messages are formatted in such a way that it is not + possible to create the reply by judicious message surgery (even in + encrypted form) without knowledge of the appropriate encryption keys. + + [13] Note that for encrypting the KRB_AP_REP message, the sub-session + key is not used, even if present in the Authenticator. + + [14] Implementations of the protocol may wish to provide routines to + choose subkeys based on session keys and random numbers and to generate + a negotiated key to be returned in the KRB_AP_REP message. + + [15]This can be accomplished in several ways. It might be known + beforehand (since the realm is part of the principal identifier), it + might be stored in a nameserver, or it might be obtained from a + configura- tion file. If the realm to be used is obtained from a + nameserver, there is a danger of being spoofed if the nameservice + providing the realm name is not authenti- cated. This might result in + the use of a realm which has been compromised, and would result in an + attacker's ability to compromise the authentication of the application + server to the client. + + [16] If the client selects a sub-session key, care must be taken to + ensure the randomness of the selected sub- session key. One approach + would be to generate a random number and XOR it with the session key + from the ticket-granting ticket. + + [17] This allows easy implementation of user-to-user authentication + [8], which uses ticket-granting ticket session keys in lieu of secret + server keys in situa- tions where such secret keys could be easily + comprom- ised. + + [18] For the purpose of appending, the realm preceding the first listed + realm is considered to be the null realm (""). + + [19] For the purpose of interpreting null subfields, the client's realm + is considered to precede those in the transited field, and the server's + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + realm is considered to follow them. + + [20] This means that a client and server running on the same host and + communicating with one another using the KRB_SAFE messages should not + share a common replay cache to detect KRB_SAFE replays. + + [21] The implementation of the Kerberos server need not combine the + database and the server on the same machine; it is feasible to store + the principal database in, say, a network name service, as long as the + entries stored therein are protected from disclosure to and + modification by unauthorized parties. However, we recommend against + such strategies, as they can make system management and threat analysis + quite complex. + + [22] See the discussion of the padata field in section 5.4.2 for + details on why this can be useful. + + [23] Warning for implementations that unpack and repack data structures + during the generation and verification of embedded checksums: Because + any checksums applied to data structures must be checked against the + original data the length of bit strings must be preserved within a data + structure between the time that a checksum is generated through + transmission to the time that the checksum is verified. + + [24] It is NOT recommended that this time value be used to adjust the + workstation's clock since the workstation cannot reliably determine + that such a KRB_AS_REP actually came from the proper KDC in a timely + manner. + + [25] Note, however, that if the time is used as the nonce, one must + make sure that the workstation time is monotonically increasing. If the + time is ever reset backwards, there is a small, but finite, probability + that a nonce will be reused. + + [27] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [29] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [31] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [32] If supported by the encryption method in use, an initialization + vector may be passed to the encryption procedure, in order to achieve + proper cipher chaining. The initialization vector might come from the + last block of the ciphertext from the previous KRB_PRIV message, but it + is the application's choice whether or not to use such an + initialization vector. If left out, the default initialization vector + for the encryption algorithm will be used. + + [33] This prevents an attacker who generates an incorrect AS request + from obtaining verifiable plaintext for use in an off-line password + guessing attack. + + [35] In the above specification, UNTAGGED OCTET STRING(length) is the + notation for an octet string with its tag and length removed. It is not + a valid ASN.1 type. The tag bits and length must be removed from the + confounder since the purpose of the confounder is so that the message + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + starts with random data, but the tag and its length are fixed. For + other fields, the length and tag would be redundant if they were + included because they are specified by the encryption type. [36] The + ordering of the fields in the CipherText is important. Additionally, + messages encoded in this format must include a length as part of the + msg-seq field. This allows the recipient to verify that the message has + not been truncated. Without a length, an attacker could use a chosen + plaintext attack to generate a message which could be truncated, while + leaving the checksum intact. Note that if the msg-seq is an encoding of + an ASN.1 SEQUENCE or OCTET STRING, then the length is part of that + encoding. + + [37] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [38] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [39] A variant of the key is used to limit the use of a key to a + particular function, separating the functions of generating a checksum + from other encryption performed using the session key. The constant + F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The + properties of DES precluded the use of the complement. The same + constant is used for similar purpose in the Message Integrity Check in + the Privacy Enhanced Mail standard. + + [40] This error carries additional information in the e- data field. + The contents of the e-data field for this message is described in + section 5.9.1. diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt new file mode 100644 index 0000000..ae79e8a --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt @@ -0,0 +1,7301 @@ +INTERNET-DRAFT Clifford Neuman + John Kohl + Theodore Ts'o + July 14, 2000 + Expires January 14, 2001 + +The Kerberos Network Authentication Service (V5) + + +draft-ietf-cat-kerberos-revisions-06.txt + +STATUS OF THIS MEMO + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC 2026. Internet-Drafts are working documents +of the Internet Engineering Task Force (IETF), its areas, and its working +groups. Note that other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months and +may be updated, replaced, or obsoleted by other documents at any time. It +is inappropriate to use Internet-Drafts as reference material or to cite +them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +To learn the current status of any Internet-Draft, please check the +"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow +Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), +ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-revisions-06.txt, and expires January 14, 2001. +Please send comments to: krb-protocol@MIT.EDU + + This document is getting closer to a last call, but there are several + issues to be discussed. Some, but not all of these issues, are + highlighted in comments in the draft. We hope to resolve these issues + on the mailing list for the Kerberos working group, leading up to and + during the Pittsburgh IETF on a section by section basis, since this + is a long document, and it has been difficult to consider it as a + whole. Once sections are agreed to, it is out intent to issue the more + formal WG and IETF last calls. + +ABSTRACT + +This document provides an overview and specification of Version 5 of the +Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol +and its intended use that require more detailed or clearer explanation than +was provided in RFC1510. This document is intended to provide a detailed +description of the protocol, suitable for implementation, together with +descriptions of the appropriate use of protocol messages and fields within +those messages. + +This document is not intended to describe Kerberos to the end user, system +administrator, or application developer. Higher level papers describing +Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], +are available elsewhere. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +OVERVIEW + +This INTERNET-DRAFT describes the concepts and model upon which the +Kerberos network authentication system is based. It also specifies Version +5 of the Kerberos protocol. + +The motivations, goals, assumptions, and rationale behind most design +decisions are treated cursorily; they are more fully described in a paper +available in IEEE communications [NT94] and earlier in the Kerberos portion +of the Athena Technical Plan [MNSS87]. The protocols have been a proposed +standard and are being considered for advancement for draft standard +through the IETF standard process. Comments are encouraged on the +presentation, but only minor refinements to the protocol as implemented or +extensions that fit within current protocol framework will be considered at +this time. + +Requests for addition to an electronic mailing list for discussion of +Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. +This mailing list is gatewayed onto the Usenet as the group +comp.protocols.kerberos. Requests for further information, including +documents and code availability, may be sent to info-kerberos@MIT.EDU. + +BACKGROUND + +The Kerberos model is based in part on Needham and Schroeder's trusted +third-party authentication protocol [NS78] and on modifications suggested +by Denning and Sacco [DS81]. The original design and implementation of +Kerberos Versions 1 through 4 was the work of two former Project Athena +staff members, Steve Miller of Digital Equipment Corporation and Clifford +Neuman (now at the Information Sciences Institute of the University of +Southern California), along with Jerome Saltzer, Technical Director of +Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many +other members of Project Athena have also contributed to the work on +Kerberos. + +Version 5 of the Kerberos protocol (described in this document) has evolved +from Version 4 based on new requirements and desires for features not +available in Version 4. The design of Version 5 of the Kerberos protocol +was led by Clifford Neuman and John Kohl with much input from the +community. The development of the MIT reference implementation was led at +MIT by John Kohl and Theodore T'so, with help and contributed code from +many others. Since RFC1510 was issued, extensions and revisions to the +protocol have been proposed by many individuals. Some of these proposals +are reflected in this document. Where such changes involved significant +effort, the document cites the contribution of the proposer. + +Reference implementations of both version 4 and version 5 of Kerberos are +publicly available and commercial implementations have been developed and +are widely used. Details on the differences between Kerberos Versions 4 and +5 can be found in [KNT92]. + +1. Introduction + +Kerberos provides a means of verifying the identities of principals, (e.g. +a workstation user or a network server) on an open (unprotected) network. +This is accomplished without relying on assertions by the host operating +system, without basing trust on host addresses, without requiring physical +security of all the hosts on the network, and under the assumption that +packets traveling along the network can be read, modified, and inserted at +will[1]. Kerberos performs authentication under these conditions as a +trusted third-party authentication service by using conventional (shared +secret key [2] cryptography. Kerberos extensions have been proposed and +implemented that provide for the use of public key cryptography during +certain phases of the authentication protocol. These extensions provide for + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +authentication of users registered with public key certification +authorities, and allow the system to provide certain benefits of public key +cryptography in situations where they are needed. + +The basic Kerberos authentication process proceeds as follows: A client +sends a request to the authentication server (AS) requesting 'credentials' +for a given server. The AS responds with these credentials, encrypted in +the client's key. The credentials consist of 1) a 'ticket' for the server +and 2) a temporary encryption key (often called a "session key"). The +client transmits the ticket (which contains the client's identity and a +copy of the session key, all encrypted in the server's key) to the server. +The session key (now shared by the client and server) is used to +authenticate the client, and may optionally be used to authenticate the +server. It may also be used to encrypt further communication between the +two parties or to exchange a separate sub-session key to be used to encrypt +further communication. + +Implementation of the basic protocol consists of one or more authentication +servers running on physically secure hosts. The authentication servers +maintain a database of principals (i.e., users and servers) and their +secret keys. Code libraries provide encryption and implement the Kerberos +protocol. In order to add authentication to its transactions, a typical +network application adds one or two calls to the Kerberos library directly +or through the Generic Security Services Application Programming Interface, +GSSAPI, described in separate document. These calls result in the +transmission of the necessary messages to achieve authentication. + +The Kerberos protocol consists of several sub-protocols (or exchanges). +There are two basic methods by which a client can ask a Kerberos server for +credentials. In the first approach, the client sends a cleartext request +for a ticket for the desired server to the AS. The reply is sent encrypted +in the client's secret key. Usually this request is for a ticket-granting +ticket (TGT) which can later be used with the ticket-granting server (TGS). +In the second method, the client sends a request to the TGS. The client +uses the TGT to authenticate itself to the TGS in the same manner as if it +were contacting any other application server that requires Kerberos +authentication. The reply is encrypted in the session key from the TGT. +Though the protocol specification describes the AS and the TGS as separate +servers, they are implemented in practice as different protocol entry +points within a single Kerberos server. + +Once obtained, credentials may be used to verify the identity of the +principals in a transaction, to ensure the integrity of messages exchanged +between them, or to preserve privacy of the messages. The application is +free to choose whatever protection may be necessary. + +To verify the identities of the principals in a transaction, the client +transmits the ticket to the application server. Since the ticket is sent +"in the clear" (parts of it are encrypted, but this encryption doesn't +thwart replay) and might be intercepted and reused by an attacker, +additional information is sent to prove that the message originated with +the principal to whom the ticket was issued. This information (called the +authenticator) is encrypted in the session key, and includes a timestamp. +The timestamp proves that the message was recently generated and is not a +replay. Encrypting the authenticator in the session key proves that it was +generated by a party possessing the session key. Since no one except the +requesting principal and the server know the session key (it is never sent +over the network in the clear) this guarantees the identity of the client. + +The integrity of the messages exchanged between principals can also be +guaranteed using the session key (passed in the ticket and contained in the +credentials). This approach provides detection of both replay attacks and +message stream modification attacks. It is accomplished by generating and +transmitting a collision-proof checksum (elsewhere called a hash or digest +function) of the client's message, keyed with the session key. Privacy and + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +integrity of the messages exchanged between principals can be secured by +encrypting the data to be passed using the session key contained in the +ticket or the subsession key found in the authenticator. + +The authentication exchanges mentioned above require read-only access to +the Kerberos database. Sometimes, however, the entries in the database must +be modified, such as when adding new principals or changing a principal's +key. This is done using a protocol between a client and a third Kerberos +server, the Kerberos Administration Server (KADM). There is also a protocol +for maintaining multiple copies of the Kerberos database. Neither of these +protocols are described in this document. + +1.1. Cross-Realm Operation + +The Kerberos protocol is designed to operate across organizational +boundaries. A client in one organization can be authenticated to a server +in another. Each organization wishing to run a Kerberos server establishes +its own 'realm'. The name of the realm in which a client is registered is +part of the client's name, and can be used by the end-service to decide +whether to honor a request. + +By establishing 'inter-realm' keys, the administrators of two realms can +allow a client authenticated in the local realm to prove its identity to +servers in other realms[3]. The exchange of inter-realm keys (a separate +key may be used for each direction) registers the ticket-granting service +of each realm as a principal in the other realm. A client is then able to +obtain a ticket-granting ticket for the remote realm's ticket-granting +service from its local realm. When that ticket-granting ticket is used, the +remote ticket-granting service uses the inter-realm key (which usually +differs from its own normal TGS key) to decrypt the ticket-granting ticket, +and is thus certain that it was issued by the client's own TGS. Tickets +issued by the remote ticket-granting service will indicate to the +end-service that the client was authenticated from another realm. + +A realm is said to communicate with another realm if the two realms share +an inter-realm key, or if the local realm shares an inter-realm key with an +intermediate realm that communicates with the remote realm. An +authentication path is the sequence of intermediate realms that are +transited in communicating from one realm to another. + +Realms are typically organized hierarchically. Each realm shares a key with +its parent and a different key with each child. If an inter-realm key is +not directly shared by two realms, the hierarchical organization allows an +authentication path to be easily constructed. If a hierarchical +organization is not used, it may be necessary to consult a database in +order to construct an authentication path between realms. + +Although realms are typically hierarchical, intermediate realms may be +bypassed to achieve cross-realm authentication through alternate +authentication paths (these might be established to make communication +between two realms more efficient). It is important for the end-service to +know which realms were transited when deciding how much faith to place in +the authentication process. To facilitate this decision, a field in each +ticket contains the names of the realms that were involved in +authenticating the client. + +The application server is ultimately responsible for accepting or rejecting +authentication and should check the transited field. The application server +may choose to rely on the KDC for the application server's realm to check +the transited field. The application server's KDC will set the +TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate +realms may also check the transited field as they issue +ticket-granting-tickets for other realms, but they are encouraged not to do +so. A client may request that the KDC's not check the transited field by +setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not +required to honor this flag. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [JBrezak] Should there be a section here on how clients determine what + realm a service is in? Something like: + + The client may not immediately know what realm a particular service + principal is in. There are 2 basic mechanisms that can be used to + determine the realm of a service. The first requires that the client + fully specify the service principal including the realm in the + Kerberos protocol request. If the Kerberos server for the specified + realm does not have a principal that exactly matches the service in + the request, the Kerberos server will return an error indicating that + the service principal was not found. Alternatively the client can make + a request providing just the service principal name and requesting + name canonicalization from the Kerberos server. The Kerberos server + will attempt to locate a service principal in its database that best + matches the request principal or provide a referral to another + Kerberos realm that may be contain the requested service principal. + +1.2. Authorization + +As an authentication service, Kerberos provides a means of verifying the +identity of principals on a network. Authentication is usually useful +primarily as a first step in the process of authorization, determining +whether a client may use a service, which objects the client is allowed to +access, and the type of access allowed for each. Kerberos does not, by +itself, provide authorization. Possession of a client ticket for a service +provides only for authentication of the client to that service, and in the +absence of a separate authorization procedure, it should not be considered +by an application as authorizing the use of that service. + +Such separate authorization methods may be implemented as application +specific access control functions and may be based on files such as the +application server, or on separately issued authorization credentials such +as those based on proxies [Neu93], or on other authorization services. +Separately authenticated authorization credentials may be embedded in a +tickets authorization data when encapsulated by the kdc-issued +authorization data element. + +Applications should not be modified to accept the mere issuance of a +service ticket by the Kerberos server (even by a modified Kerberos server) +as granting authority to use the service, since such applications may +become vulnerable to the bypass of this authorization check in an +environment if they interoperate with other KDCs or where other options for +application authentication (e.g. the PKTAPP proposal) are provided. + +1.3. Environmental assumptions + +Kerberos imposes a few assumptions on the environment in which it can +properly function: + + * 'Denial of service' attacks are not solved with Kerberos. There are + places in these protocols where an intruder can prevent an application + from participating in the proper authentication steps. Detection and + solution of such attacks (some of which can appear to be nnot-uncommon + 'normal' failure modes for the system) is usually best left to the + human administrators and users. + * Principals must keep their secret keys secret. If an intruder somehow + steals a principal's key, it will be able to masquerade as that + principal or impersonate any server to the legitimate principal. + * 'Password guessing' attacks are not solved by Kerberos. If a user + chooses a poor password, it is possible for an attacker to + successfully mount an offline dictionary attack by repeatedly + attempting to decrypt, with successive entries from a dictionary, + messages obtained which are encrypted under a key derived from the + user's password. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + * Each host on the network must have a clock which is 'loosely + synchronized' to the time of the other hosts; this synchronization is + used to reduce the bookkeeping needs of application servers when they + do replay detection. The degree of "looseness" can be configured on a + per-server basis, but is typically on the order of 5 minutes. If the + clocks are synchronized over the network, the clock synchronization + protocol must itself be secured from network attackers. + * Principal identifiers are not recycled on a short-term basis. A + typical mode of access control will use access control lists (ACLs) to + grant permissions to particular principals. If a stale ACL entry + remains for a deleted principal and the principal identifier is + reused, the new principal will inherit rights specified in the stale + ACL entry. By not re-using principal identifiers, the danger of + inadvertent access is removed. + +1.4. Glossary of terms + +Below is a list of terms used throughout this document. + +Authentication + Verifying the claimed identity of a principal. +Authentication header + A record containing a Ticket and an Authenticator to be presented to a + server as part of the authentication process. +Authentication path + A sequence of intermediate realms transited in the authentication + process when communicating from one realm to another. +Authenticator + A record containing information that can be shown to have been + recently generated using the session key known only by the client and + server. +Authorization + The process of determining whether a client may use a service, which + objects the client is allowed to access, and the type of access + allowed for each. +Capability + A token that grants the bearer permission to access an object or + service. In Kerberos, this might be a ticket whose use is restricted + by the contents of the authorization data field, but which lists no + network addresses, together with the session key necessary to use the + ticket. +Ciphertext + The output of an encryption function. Encryption transforms plaintext + into ciphertext. +Client + A process that makes use of a network service on behalf of a user. + Note that in some cases a Server may itself be a client of some other + server (e.g. a print server may be a client of a file server). +Credentials + A ticket plus the secret session key necessary to successfully use + that ticket in an authentication exchange. +KDC + Key Distribution Center, a network service that supplies tickets and + temporary session keys; or an instance of that service or the host on + which it runs. The KDC services both initial ticket and + ticket-granting ticket requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service). The + ticket-granting ticket portion is sometimes referred to as the + ticket-granting server (or service). +Kerberos + Aside from the 3-headed dog guarding Hades, the name given to Project + Athena's authentication service, the protocol used by that service, or + the code used to implement the authentication service. +Plaintext + The input to an encryption function or the output of a decryption + function. Decryption transforms ciphertext into plaintext. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +Principal + A uniquely named client or server instance that participates in a + network communication. +Principal identifier + The name used to uniquely identify each different principal. +Seal + To encipher a record containing several fields in such a way that the + fields cannot be individually replaced without either knowledge of the + encryption key or leaving evidence of tampering. +Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the case of + a human user's principal, the secret key is derived from a password. +Server + A particular Principal which provides a resource to network clients. + The server is sometimes refered to as the Application Server. +Service + A resource provided to network clients; often provided by more than + one server (for example, remote file service). +Session key + A temporary encryption key used between two principals, with a + lifetime limited to the duration of a single login "session". +Sub-session key + A temporary encryption key used between two principals, selected and + exchanged by the principals using the session key, and with a lifetime + limited to the duration of a single association. +Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and other + information, all sealed using the server's secret key. It only serves + to authenticate a client when presented along with a fresh + Authenticator. + +2. Ticket flag uses and requests + +Each Kerberos ticket contains a set of flags which are used to indicate +various attributes of that ticket. Most flags may be requested by a client +when the ticket is obtained; some are automatically turned on and off by a +Kerberos server as required. The following sections explain what the +various flags mean, and gives examples of reasons to use such a flag. + +2.1. Initial and pre-authenticated tickets + +The INITIAL flag indicates that a ticket was issued using the AS protocol +and not issued based on a ticket-granting ticket. Application servers that +want to require the demonstrated knowledge of a client's secret key (e.g. a +password-changing program) can insist that this flag be set in any tickets +they accept, and thus be assured that the client's key was recently +presented to the application client. + +The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the +initial authentication, regardless of whether the current ticket was issued +directly (in which case INITIAL will also be set) or issued on the basis of +a ticket-granting ticket (in which case the INITIAL flag is clear, but the +PRE-AUTHENT and HW-AUTHENT flags are carried forward from the +ticket-granting ticket). + +2.2. Invalid tickets + +The INVALID flag indicates that a ticket is invalid. Application servers +must reject tickets which have this flag set. A postdated ticket will +usually be issued in this form. Invalid tickets must be validated by the +KDC before use, by presenting them to the KDC in a TGS request with the +VALIDATE option specified. The KDC will only validate tickets after their +starttime has passed. The validation is required so that postdated tickets +which have been stolen before their starttime can be rendered permanently +invalid (through a hot-list mechanism) (see section 3.3.3.1). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +2.3. Renewable tickets + +Applications may desire to hold tickets which can be valid for long periods +of time. However, this can expose their credentials to potential theft for +equally long periods, and those stolen credentials would be valid until the +expiration time of the ticket(s). Simply using short-lived tickets and +obtaining new ones periodically would require the client to have long-term +access to its secret key, an even greater risk. Renewable tickets can be +used to mitigate the consequences of theft. Renewable tickets have two +"expiration times": the first is when the current instance of the ticket +expires, and the second is the latest permissible value for an individual +expiration time. An application client must periodically (i.e. before it +expires) present a renewable ticket to the KDC, with the RENEW option set +in the KDC request. The KDC will issue a new ticket with a new session key +and a later expiration time. All other fields of the ticket are left +unmodified by the renewal process. When the latest permissible expiration +time arrives, the ticket expires permanently. At each renewal, the KDC may +consult a hot-list to determine if the ticket had been reported stolen +since its last renewal; it will refuse to renew such stolen tickets, and +thus the usable lifetime of stolen tickets is reduced. + +The RENEWABLE flag in a ticket is normally only interpreted by the +ticket-granting service (discussed below in section 3.3). It can usually be +ignored by application servers. However, some particularly careful +application servers may wish to disallow renewable tickets. + +If a renewable ticket is not renewed by its expiration time, the KDC will +not renew the ticket. The RENEWABLE flag is reset by default, but a client +may request it be set by setting the RENEWABLE option in the KRB_AS_REQ +message. If it is set, then the renew-till field in the ticket contains the +time after which the ticket may not be renewed. + +2.4. Postdated tickets + +Applications may occasionally need to obtain tickets for use much later, +e.g. a batch submission system would need tickets to be valid at the time +the batch job is serviced. However, it is dangerous to hold valid tickets +in a batch queue, since they will be on-line longer and more prone to +theft. Postdated tickets provide a way to obtain these tickets from the KDC +at job submission time, but to leave them "dormant" until they are +activated and validated by a further request of the KDC. If a ticket theft +were reported in the interim, the KDC would refuse to validate the ticket, +and the thief would be foiled. + +The MAY-POSTDATE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. This +flag must be set in a ticket-granting ticket in order to issue a postdated +ticket based on the presented ticket. It is reset by default; it may be +requested by a client by setting the ALLOW-POSTDATE option in the +KRB_AS_REQ message. This flag does not allow a client to obtain a postdated +ticket-granting ticket; postdated ticket-granting tickets can only by +obtained by requesting the postdating in the KRB_AS_REQ message. The life +(endtime-starttime) of a postdated ticket will be the remaining life of the +ticket-granting ticket at the time of the request, unless the RENEWABLE +option is also set, in which case it can be the full life +(endtime-starttime) of the ticket-granting ticket. The KDC may limit how +far in the future a ticket may be postdated. + +The POSTDATED flag indicates that a ticket has been postdated. The +application server can check the authtime field in the ticket to see when +the original authentication occurred. Some services may choose to reject +postdated tickets, or they may only accept them within a certain period +after the original authentication. When the KDC issues a POSTDATED ticket, +it will also be marked as INVALID, so that the application client must +present the ticket to the KDC to be validated before use. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +2.5. Proxiable and proxy tickets + +At times it may be necessary for a principal to allow a service to perform +an operation on its behalf. The service must be able to take on the +identity of the client, but only for a particular purpose. A principal can +allow a service to take on the principal's identity for a particular +purpose by granting it a proxy. + +The process of granting a proxy using the proxy and proxiable flags is used +to provide credentials for use with specific services. Though conceptually +also a proxy, user's wishing to delegate their identity for ANY purpose +must use the ticket forwarding mechanism described in the next section to +forward a ticket granting ticket. + +The PROXIABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. When +set, this flag tells the ticket-granting server that it is OK to issue a +new ticket (but not a ticket-granting ticket) with a different network +address based on this ticket. This flag is set if requested by the client +on initial authentication. By default, the client will request that it be +set when requesting a ticket granting ticket, and reset when requesting any +other ticket. + +This flag allows a client to pass a proxy to a server to perform a remote +request on its behalf, e.g. a print service client can give the print +server a proxy to access the client's files on a particular file server in +order to satisfy a print request. + +In order to complicate the use of stolen credentials, Kerberos tickets are +usually valid from only those network addresses specifically included in +the ticket[4]. When granting a proxy, the client must specify the new +network address from which the proxy is to be used, or indicate that the +proxy is to be issued for use from any address. + +The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. +Application servers may check this flag and at their option they may +require additional authentication from the agent presenting the proxy in +order to provide an audit trail. + +2.6. Forwardable tickets + +Authentication forwarding is an instance of a proxy where the service is +granted complete use of the client's identity. An example where it might be +used is when a user logs in to a remote system and wants authentication to +work from that system as if the login were local. + +The FORWARDABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. The +FORWARDABLE flag has an interpretation similar to that of the PROXIABLE +flag, except ticket-granting tickets may also be issued with different +network addresses. This flag is reset by default, but users may request +that it be set by setting the FORWARDABLE option in the AS request when +they request their initial ticket- granting ticket. + +This flag allows for authentication forwarding without requiring the user +to enter a password again. If the flag is not set, then authentication +forwarding is not permitted, but the same result can still be achieved if +the user engages in the AS exchange specifying the requested network +addresses and supplies a password. + +The FORWARDED flag is set by the TGS when a client presents a ticket with +the FORWARDABLE flag set and requests a forwarded ticket by specifying the +FORWARDED KDC option and supplying a set of addresses for the new ticket. +It is also set in all tickets issued based on tickets with the FORWARDED +flag set. Application servers may choose to process FORWARDED tickets +differently than non-FORWARDED tickets. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +2.7 Name canonicalization [JBrezak] + +If a client does not have the full name information for a principal, it can +request that the Kerberos server attempt to lookup the name in its database +and return a canonical form of the requested principal or a referral to a +realm that has the requested principal in its namespace. Name +canonicalization allows a principal to have alternate names. Name +canonicalization must not be used to locate principal names supplied from +wildcards and is not a mechanism to be used to search a Kerberos database. + +The CANONICALIZE flag in a ticket request is used to indicate to the +Kerberos server that the client will accept an alternative name to the +principal in the request or a referral to another realm. Both the AS and +TGS must be able to interpret requests with this flag. + +By using this flag, the client can avoid extensive configuration needed to +map specific host names to a particular realm. + +2.8. Other KDC options + +There are two additional options which may be set in a client's request of +the KDC. The RENEWABLE-OK option indicates that the client will accept a +renewable ticket if a ticket with the requested life cannot otherwise be +provided. If a ticket with the requested life cannot be provided, then the +KDC may issue a renewable ticket with a renew-till equal to the the +requested endtime. The value of the renew-till field may still be adjusted +by site-determined limits or limits imposed by the individual principal or +server. + +The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. +It indicates that the ticket to be issued for the end server is to be +encrypted in the session key from the a additional second ticket-granting +ticket provided with the request. See section 3.3.3 for specific details. + +3. Message Exchanges + +The following sections describe the interactions between network clients +and servers and the messages involved in those exchanges. + +3.1. The Authentication Service Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_AS_REQ 5.4.1 + 2. Kerberos to client KRB_AS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The Authentication Service (AS) Exchange between the client and the +Kerberos Authentication Server is initiated by a client when it wishes to +obtain authentication credentials for a given server but currently holds no +credentials. In its basic form, the client's secret key is used for +encryption and decryption. This exchange is typically used at the +initiation of a login session to obtain credentials for a Ticket-Granting +Server which will subsequently be used to obtain credentials for other +servers (see section 3.3) without requiring further use of the client's +secret key. This exchange is also used to request credentials for services +which must not be mediated through the Ticket-Granting Service, but rather +require a principal's secret key, such as the password-changing service[5]. +This exchange does not by itself provide any assurance of the the identity +of the user[6]. + +The exchange consists of two messages: KRB_AS_REQ from the client to +Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these +messages are described in sections 5.4.1, 5.4.2, and 5.9.1. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +In the request, the client sends (in cleartext) its own identity and the +identity of the server for which it is requesting credentials. The +response, KRB_AS_REP, contains a ticket for the client to present to the +server, and a session key that will be shared by the client and the server. +The session key and additional information are encrypted in the client's +secret key. The KRB_AS_REP message contains information which can be used +to detect replays, and to associate it with the message to which it +replies. Various errors can occur; these are indicated by an error response +(KRB_ERROR) instead of the KRB_AS_REP response. The error message is not +encrypted. The KRB_ERROR message contains information which can be used to +associate it with the message to which it replies. The lack of encryption +in the KRB_ERROR message precludes the ability to detect replays, +fabrications, or modifications of such messages. + +Without preautentication, the authentication server does not know whether +the client is actually the principal named in the request. It simply sends +a reply without knowing or caring whether they are the same. This is +acceptable because nobody but the principal whose identity was given in the +request will be able to use the reply. Its critical information is +encrypted in that principal's key. The initial request supports an optional +field that can be used to pass additional information that might be needed +for the initial exchange. This field may be used for preauthentication as +described in section [hl<>]. + +3.1.1. Generation of KRB_AS_REQ message + +The client may specify a number of options in the initial request. Among +these options are whether pre-authentication is to be performed; whether +the requested ticket is to be renewable, proxiable, or forwardable; whether +it should be postdated or allow postdating of derivative tickets; whether +the client requests name-canonicalization; and whether a renewable ticket +will be accepted in lieu of a non-renewable ticket if the requested ticket +expiration date cannot be satisfied by a non-renewable ticket (due to +configuration constraints; see section 4). See section A.1 for pseudocode. + +The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ message + +If all goes well, processing the KRB_AS_REQ message will result in the +creation of a ticket for the client to present to the server. The format +for the ticket is described in section 5.3.1. The contents of the ticket +are determined as follows. + +3.1.3. Generation of KRB_AS_REP message + +The authentication server looks up the client and server principals named +in the KRB_AS_REQ in its database, extracting their respective keys. If +the requested client principal named in the request is not found in its +database, then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is +returned. If the request had the CANONICALIZE option set, then the AS can +attempt to lookup the client principal name in an alternate database, if it +is found an error message with a KDC_ERR_WRONG_REALM error code and the +cname and crealm in the error message must contain the true client +principal name and realm. + +If required, the server pre-authenticates the request, and if the +pre-authentication check fails, an error message with the code +KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the +requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP +is returned. Otherwise it generates a 'random' session key[7]. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +If there are multiple encryption keys registered for a client in the +Kerberos database (or if the key registered supports multiple encryption +types; e.g. DES3-CBC-SHA1 and DES3-CBC-SHA1-KD), then the etype field from +the AS request is used by the KDC to select the encryption method to be +used for encrypting the response to the client. If there is more than one +supported, strong encryption type in the etype list, the first valid etype +for which an encryption key is available is used. The encryption method +used to respond to a TGS request is taken from the keytype of the session +key found in the ticket granting ticket. + + JBrezak - the behavior of PW-SALT, and ETYPE-INFO should be explained + here; also about using keys that have different string-to-key + functions like AFSsalt + +When the etype field is present in a KDC request, whether an AS or TGS +request, the KDC will attempt to assign the type of the random session key +from the list of methods in the etype field. The KDC will select the +appropriate type using the list of methods provided together with +information from the Kerberos database indicating acceptable encryption +methods for the application server. The KDC will not issue tickets with a +weak session key encryption type. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. +Otherwise the requested start time is checked against the policy of the +local realm (the administrator might decide to prohibit certain types or +ranges of postdated tickets), and if acceptable, the ticket's start time is +set as requested and the INVALID flag is set in the new ticket. The +postdated ticket must be validated before use by presenting it to the KDC +after the start time has been reached. + +The expiration time of the ticket will be set to the minimum of the +following: + + * The expiration time (endtime) requested in the KRB_AS_REQ message. + * The ticket's start time plus the maximum allowable lifetime associated + with the client principal (the authentication server's database + includes a maximum ticket lifetime field in each principal's record; + see section 4). + * The ticket's start time plus the maximum allowable lifetime associated + with the server principal. + * The ticket's start time plus the maximum lifetime set by the policy of + the local realm. + +If the requested expiration time minus the start time (as determined above) +is less than a site-determined minimum lifetime, an error message with code +KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the +ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' +option was requested, then the 'RENEWABLE' flag is set in the new ticket, +and the renew-till value is set as if the 'RENEWABLE' option were requested +(the field and option names are described fully in section 5.4.1). + +If the RENEWABLE option has been requested or if the RENEWABLE-OK option +has been set and a renewable ticket is to be issued, then the renew-till +field is set to the minimum of: + + * Its requested value. + * The start time of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database entries. + * The start time of the ticket plus the maximum renewable lifetime set + by the policy of the local realm. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The flags field of the new ticket will have the following options set if +they have been requested and if the policy of the local realm allows: +FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new +ticket is post-dated (the start time is in the future), its INVALID flag +will also be set. + +If all of the above succeed, the server formats a KRB_AS_REP message (see +section 5.4.2), copying the addresses in the request into the caddr of the +response, placing any required pre-authentication data into the padata of +the response, and encrypts the ciphertext part in the client's key using +the requested encryption method, and sends it to the client. See section +A.2 for pseudocode. + +3.1.4. Generation of KRB_ERROR message + +Several errors can occur, and the Authentication Server responds by +returning an error message, KRB_ERROR, to the client, with the error-code +and e-text fields set to appropriate values. The error message contents and +details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP message + +If the reply message type is KRB_AS_REP, then the client verifies that the +cname and crealm fields in the cleartext portion of the reply match what it +requested. If any padata fields are present, they may be used to derive the +proper secret key to decrypt the message. The client decrypts the encrypted +part of the response using its secret key, verifies that the nonce in the +encrypted part matches the nonce it supplied in its request (to detect +replays). It also verifies that the sname and srealm in the response match +those in the request (or are otherwise expected values), and that the host +address field is also correct. It then stores the ticket, session key, +start and expiration times, and other information for later use. The +key-expiration field from the encrypted part of the response may be checked +to notify the user of impending key expiration (the client program could +then suggest remedial action, such as a password change). See section A.3 +for pseudocode. + +Proper decryption of the KRB_AS_REP message is not sufficient to verify the +identity of the user; the user and an attacker could cooperate to generate +a KRB_AS_REP format message which decrypts properly but is not from the +proper KDC. If the host wishes to verify the identity of the user, it must +require the user to present application credentials which can be verified +using a securely-stored secret key for the host. If those credentials can +be verified, then the identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR message + +If the reply message type is KRB_ERROR, then the client interprets it as an +error and performs whatever application-specific tasks are necessary to +recover. If the client set the CANONICALIZE option and a +KDC_ERR_WRONG_REALM error was returned, the AS request should be retried to +the realm and client principal name specified in the error message crealm +and cname field respectively. + +3.2. The Client/Server Authentication Exchange + + Summary +Message direction Message type Section +Client to Application server KRB_AP_REQ 5.5.1 +[optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + +The client/server authentication (CS) exchange is used by network +applications to authenticate the client to the server and vice versa. The +client must have already acquired credentials for the server using the AS +or TGS exchange. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.2.1. The KRB_AP_REQ message + +The KRB_AP_REQ contains authentication information which should be part of +the first message in an authenticated transaction. It contains a ticket, an +authenticator, and some additional bookkeeping information (see section +5.5.1 for the exact format). The ticket by itself is insufficient to +authenticate a client, since tickets are passed across the network in +cleartext[DS90], so the authenticator is used to prevent invalid replay of +tickets by proving to the server that the client knows the session key of +the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message +is referred to elsewhere as the 'authentication header.' + +3.2.2. Generation of a KRB_AP_REQ message + +When a client wishes to initiate authentication to a server, it obtains +(either through a credentials cache, the AS exchange, or the TGS exchange) +a ticket and session key for the desired service. The client may re-use any +tickets it holds until they expire. To use a ticket the client constructs a +new Authenticator from the the system time, its name, and optionally an +application specific checksum, an initial sequence number to be used in +KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in +negotiations for a session key unique to this particular session. +Authenticators may not be re-used and will be rejected if replayed to a +server[LGDSR87]. If a sequence number is to be included, it should be +randomly chosen so that even after many messages have been exchanged it is +not likely to collide with other sequence numbers in use. + +The client may indicate a requirement of mutual authentication or the use +of a session-key based ticket by setting the appropriate flag(s) in the +ap-options field of the message. + +The Authenticator is encrypted in the session key and combined with the +ticket to form the KRB_AP_REQ message which is then sent to the end server +along with any additional application-specific information. See section A.9 +for pseudocode. + +3.2.3. Receipt of KRB_AP_REQ message + +Authentication is based on the server's current time of day (clocks must be +loosely synchronized), the authenticator, and the ticket. Several errors +are possible. If an error occurs, the server is expected to reply to the +client with a KRB_ERROR message. This message may be encapsulated in the +application protocol if its 'raw' form is not acceptable to the protocol. +The format of error messages is described in section 5.9.1. + +The algorithm for verifying authentication information is as follows. If +the message type is not KRB_AP_REQ, the server returns the +KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in +the KRB_AP_REQ is not one the server can use (e.g., it indicates an old +key, and the server no longer possesses a copy of the old key), the +KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is set +in the ap-options field, it indicates to the server that the ticket is +encrypted in the session key from the server's ticket-granting ticket +rather than its secret key[10]. Since it is possible for the server to be +registered in multiple realms, with different keys in each, the srealm +field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to +specify which secret key the server should use to decrypt that ticket. The +KRB_AP_ERR_NOKEY error code is returned if the server doesn't have the +proper key to decipher the ticket. + +The ticket is decrypted using the version of the server's key specified by +the ticket. If the decryption routines detect a modification of the ticket +(each encryption system must provide safeguards to detect modified +ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned +(chances are good that different keys were used to encrypt and decrypt). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The authenticator is decrypted using the session key extracted from the +decrypted ticket. If decryption shows it to have been modified, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the +client from the ticket are compared against the same fields in the +authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is +returned (they might not match, for example, if the wrong session key was +used to encrypt the authenticator). The addresses in the ticket (if any) +are then searched for an address matching the operating-system reported +address of the client. If no match is found or the server insists on ticket +addresses but none are present in the ticket, the KRB_AP_ERR_BADADDR error +is returned. + +If the local (server) time and the client time in the authenticator differ +by more than the allowable clock skew (e.g., 5 minutes), the +KRB_AP_ERR_SKEW error is returned. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen such tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The +server must remember any authenticator presented within the allowable clock +skew, so that a replay attempt is guaranteed to fail. If a server loses +track of any authenticator presented within the allowable clock skew, it +must reject all requests until the clock skew interval has passed. This +assures that any lost or re-played authenticators will fall outside the +allowable clock skew and can no longer be successfully replayed (If this is +not done, an attacker could conceivably record the ticket and authenticator +sent over the network to a server, then disable the client's host, pose as +the disabled host, and replay the ticket and authenticator to subvert the +authentication.). If a sequence number is provided in the authenticator, +the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV +messages. If a subkey is present, the server either saves it for later use +or uses it to help generate its own choice for a subkey to be returned in a +KRB_AP_REP message. + +The server computes the age of the ticket: local (server) time minus the +start time inside the Ticket. If the start time is later than the current +time by more than the allowable clock skew or if the INVALID flag is set in +the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the +current time is later than end time by more than the allowable clock skew, +the KRB_AP_ERR_TKT_EXPIRED error is returned. + +If all these checks succeed without an error, the server is assured that +the client possesses the credentials of the principal named in the ticket +and thus, the client has been authenticated to the server. See section A.10 +for pseudocode. + +Passing these checks provides only authentication of the named principal; +it does not imply authorization to use the named service. Applications must +make a separate authorization decisions based upon the authenticated name +of the user, the requested operation, local acces control information such +as that contained in a .k5login or .k5users file, and possibly a separate +distributed authorization service. + +3.2.4. Generation of a KRB_AP_REP message + +Typically, a client's request will include both the authentication +information and its initial request in the same message, and the server +need not explicitly reply to the KRB_AP_REQ. However, if mutual +authentication (not only authenticating the client to the server, but also +the server to the client) is being performed, the KRB_AP_REQ message will + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message +is required in response. As with the error message, this message may be +encapsulated in the application protocol if its "raw" form is not +acceptable to the application's protocol. The timestamp and microsecond +field used in the reply must be the client's timestamp and microsecond +field (as provided in the authenticator)[12]. If a sequence number is to be +included, it should be randomly chosen as described above for the +authenticator. A subkey may be included if the server desires to negotiate +a different subkey. The KRB_AP_REP message is encrypted in the session key +extracted from the ticket. See section A.11 for pseudocode. + +3.2.5. Receipt of KRB_AP_REP message + +If a KRB_AP_REP message is returned, the client uses the session key from +the credentials obtained for the server[13] to decrypt the message, and +verifies that the timestamp and microsecond fields match those in the +Authenticator it sent to the server. If they match, then the client is +assured that the server is genuine. The sequence number and subkey (if +present) are retained for later use. See section A.12 for pseudocode. + +3.2.6. Using the encryption key + +After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and +server share an encryption key which can be used by the application. The +'true session key' to be used for KRB_PRIV, KRB_SAFE, or other +application-specific uses may be chosen by the application based on the +subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases, +the use of this session key will be implicit in the protocol; in others the +method of use must be chosen from several alternatives. We leave the +protocol negotiations of how to use the key (e.g. selecting an encryption +or checksum type) to the application programmer; the Kerberos protocol does +not constrain the implementation options, but an example of how this might +be done follows. + +One way that an application may choose to negotiate a key to be used for +subequent integrity and privacy protection is for the client to propose a +key in the subkey field of the authenticator. The server can then choose a +key using the proposed key from the client as input, returning the new +subkey in the subkey field of the application reply. This key could then be +used for subsequent communication. To make this example more concrete, if +the encryption method in use required a 56 bit key, and for whatever +reason, one of the parties was prevented from using a key with more than 40 +unknown bits, this method would allow the the party which is prevented from +using more than 40 bits to either propose (if the client) an initial key +with a known quantity for 16 of those bits, or to mask 16 of the bits (if +the server) with the known quantity. The application implementor is warned, +however, that this is only an example, and that an analysis of the +particular crytosystem to be used, and the reasons for limiting the key +length, must be made before deciding whether it is acceptable to mask bits +of the key. + +With both the one-way and mutual authentication exchanges, the peers should +take care not to send sensitive information to each other without proper +assurances. In particular, applications that require privacy or integrity +should use the KRB_AP_REP response from the server to client to assure both +client and server of their peer's identity. If an application protocol +requires privacy of its messages, it can use the KRB_PRIV message (section +3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + +The TGS exchange between a client and the Kerberos Ticket-Granting Server +is initiated by a client when it wishes to obtain authentication +credentials for a given server (which might be registered in a remote +realm), when it wishes to renew or validate an existing ticket, or when it +wishes to obtain a proxy ticket. In the first case, the client must already +have acquired a ticket for the Ticket-Granting Service using the AS +exchange (the ticket-granting ticket is usually obtained when a client +initially authenticates to the system, such as when a user logs in). The +message format for the TGS exchange is almost identical to that for the AS +exchange. The primary difference is that encryption and decryption in the +TGS exchange does not take place under the client's key. Instead, the +session key from the ticket-granting ticket or renewable ticket, or +sub-session key from an Authenticator is used. As is the case for all +application servers, expired tickets are not accepted by the TGS, so once a +renewable or ticket-granting ticket expires, the client must use a separate +exchange to obtain valid tickets. + +The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the +client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or +KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the +client plus a request for credentials. The authentication information +consists of the authentication header (KRB_AP_REQ) which includes the +client's previously obtained ticket-granting, renewable, or invalid ticket. +In the ticket-granting ticket and proxy cases, the request may include one +or more of: a list of network addresses, a collection of typed +authorization data to be sealed in the ticket for authorization use by the +application server, or additional tickets (the use of which are described +later). The TGS reply (KRB_TGS_REP) contains the requested credentials, +encrypted in the session key from the ticket-granting ticket or renewable +ticket, or if present, in the sub-session key from the Authenticator (part +of the authentication header). The KRB_ERROR message contains an error code +and text explaining what went wrong. The KRB_ERROR message is not +encrypted. The KRB_TGS_REP message contains information which can be used +to detect replays, and to associate it with the message to which it +replies. The KRB_ERROR message also contains information which can be used +to associate it with the message to which it replies, but the lack of +encryption in the KRB_ERROR message precludes the ability to detect replays +or fabrications of such messages. + +3.3.1. Generation of KRB_TGS_REQ message + +Before sending a request to the ticket-granting service, the client must +determine in which realm the application server is registered[15], if it is +known. If the client does know the service principal name and realm and it +does not already possess a ticket-granting ticket for the appropriate +realm, then one must be obtained. This is first attempted by requesting a +ticket-granting ticket for the destination realm from a Kerberos server for +which the client does posess a ticket-granting ticket (using the +KRB_TGS_REQ message recursively). The Kerberos server may return a TGT for +the desired realm in which case one can proceed. + +If the client does not know the realm of the service or the true service +principal name, then the CANONICALIZE option must be used in the request. +This will cause the TGS to locate the service principal based on the target +service name in the ticket and return the service principal name in the +response. Alternatively, the Kerberos server may return a TGT for a realm +which is 'closer' to the desired realm (further along the standard + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +hierarchical path) or the realm that may contain the requested service +principal name in a request with the CANONCALIZE option set [JBrezak], in +which case this step must be repeated with a Kerberos server in the realm +specified in the returned TGT. If neither are returned, then the request +must be retried with a Kerberos server for a realm higher in the hierarchy. +This request will itself require a ticket-granting ticket for the higher +realm which must be obtained by recursively applying these directions. + +Once the client obtains a ticket-granting ticket for the appropriate realm, +it determines which Kerberos servers serve that realm, and contacts one. +The list might be obtained through a configuration file or network service +or it may be generated from the name of the realm; as long as the secret +keys exchanged by realms are kept secret, only denial of service results +from using a false Kerberos server. + +As in the AS exchange, the client may specify a number of options in the +KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing +an authentication header as an element of the padata field, and including +the same fields as used in the KRB_AS_REQ message along with several +optional fields: the enc-authorization-data field for application server +use and additional tickets required by some options. + +In preparing the authentication header, the client can select a sub-session +key under which the response from the Kerberos server will be +encrypted[16]. If the sub-session key is not specified, the session key +from the ticket-granting ticket will be used. If the enc-authorization-data +is present, it must be encrypted in the sub-session key, if present, from +the authenticator portion of the authentication header, or if not present, +using the session key from the ticket-granting ticket. + +Once prepared, the message is sent to a Kerberos server for the destination +realm. See section A.5 for pseudocode. + +3.3.2. Receipt of KRB_TGS_REQ message + +The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ +message, but there are many additional checks to be performed. First, the +Kerberos server must determine which server the accompanying ticket is for +and it must select the appropriate key to decrypt it. For a normal +KRB_TGS_REQ message, it will be for the ticket granting service, and the +TGS's key will be used. If the TGT was issued by another realm, then the +appropriate inter-realm key must be used. If the accompanying ticket is not +a ticket granting ticket for the current realm, but is for an application +server in the current realm, the RENEW, VALIDATE, or PROXY options are +specified in the request, and the server for which a ticket is requested is +the server named in the accompanying ticket, then the KDC will decrypt the +ticket in the authentication header using the key of the server for which +it was issued. If no ticket can be found in the padata field, the +KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + +Once the accompanying ticket has been decrypted, the user-supplied checksum +in the Authenticator must be verified against the contents of the request, +and the message rejected if the checksums do not match (with an error code +of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not +collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the +checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is +returned. If the authorization-data are present, they are decrypted using +the sub-session key from the Authenticator. + +If any of the decryptions indicate failed integrity checks, the +KRB_AP_ERR_BAD_INTEGRITY error is returned. If the CANONICALIZE option is +set in the KRB_TGS_REQ, then the requested service name may not be the true +principal name or the service may not be in the TGS realm. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.3.3. Generation of KRB_TGS_REP message + +The KRB_TGS_REP message shares its format with the KRB_AS_REP +(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed +specification is in section 5.4.2. + +The response will include a ticket for the requested server. The Kerberos +database is queried to retrieve the record for the requested server +(including the key with which the ticket will be encrypted). If the request +is for a ticket granting ticket for a remote realm, and if no key is shared +with the requested realm, then the Kerberos server will select the realm +"closest" to the requested realm with which it does share a key, and use +that realm instead. If the CANONICALIZE option is set, the TGS may return a +ticket containing the server name of the true service principal. If the +requested server cannot be found in the TGS database, then a TGT for +another trusted realm may be returned instead of a ticket for the service. +This TGT is a referral mechanism to cause the client to retry the request +to the realm of the TGT. These are the only cases where the response for +the KDC will be for a different server than that requested by the client. + +By default, the address field, the client's name and realm, the list of +transited realms, the time of initial authentication, the expiration time, +and the authorization data of the newly-issued ticket will be copied from +the ticket-granting ticket (TGT) or renewable ticket. If the transited +field needs to be updated, but the transited type is not supported, the +KDC_ERR_TRTYPE_NOSUPP error is returned. + +If the request specifies an endtime, then the endtime of the new ticket is +set to the minimum of (a) that request, (b) the endtime from the TGT, and +(c) the starttime of the TGT plus the minimum of the maximum life for the +application server and the maximum life for the local realm (the maximum +life for the requesting principal was already applied when the TGT was +issued). If the new ticket is to be a renewal, then the endtime above is +replaced by the minimum of (a) the value of the renew_till field of the +ticket and (b) the starttime for the new ticket plus the life +(endtime-starttime) of the old ticket. + +If the FORWARDED option has been requested, then the resulting ticket will +contain the addresses specified by the client. This option will only be +honored if the FORWARDABLE flag is set in the TGT. The PROXY option is +similar; the resulting ticket will contain the addresses specified by the +client. It will be honored only if the PROXIABLE flag in the TGT is set. +The PROXY option will not be honored on requests for additional +ticket-granting tickets. + +If the requested start time is absent, indicates a time in the past, or is +within the window of acceptable clock skew for the KDC and the POSTDATE +option has not been specified, then the start time of the ticket is set to +the authentication server's current time. If it indicates a time in the +future beyond the acceptable clock skew, but the POSTDATED option has not +been specified or the MAY-POSTDATE flag is not set in the TGT, then the +error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the +ticket-granting ticket has the MAY-POSTDATE flag set, then the resulting +ticket will be postdated and the requested starttime is checked against the +policy of the local realm. If acceptable, the ticket's start time is set as +requested, and the INVALID flag is set. The postdated ticket must be +validated before use by presenting it to the KDC after the starttime has +been reached. However, in no case may the starttime, endtime, or renew-till +time of a newly-issued postdated ticket extend beyond the renew-till time +of the ticket-granting ticket. + +If the ENC-TKT-IN-SKEY option has been specified and an additional ticket +has been included in the request, the KDC will decrypt the additional +ticket using the key for the server to which the additional ticket was +issued and verify that it is a ticket-granting ticket. If the name of the + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +requested server is missing from the request, the name of the client in the +additional ticket will be used. Otherwise the name of the requested server +will be compared to the name of the client in the additional ticket and if +different, the request will be rejected. If the request succeeds, the +session key from the additional ticket will be used to encrypt the new +ticket that is issued instead of using the key of the server for which the +new ticket will be used[17]. + +If the name of the server in the ticket that is presented to the KDC as +part of the authentication header is not that of the ticket-granting server +itself, the server is registered in the realm of the KDC, and the RENEW +option is requested, then the KDC will verify that the RENEWABLE flag is +set in the ticket, that the INVALID flag is not set in the ticket, and that +the renew_till time is still in the future. If the VALIDATE option is +rqeuested, the KDC will check that the starttime has passed and the INVALID +flag is set. If the PROXY option is requested, then the KDC will check that +the PROXIABLE flag is set in the ticket. If the tests succeed, and the +ticket passes the hotlist check described in the next paragraph, the KDC +will issue the appropriate new ticket. + +3.3.3.1. Checking for revoked tickets + +Whenever a request is made to the ticket-granting server, the presented +ticket(s) is(are) checked against a hot-list of tickets which have been +canceled. This hot-list might be implemented by storing a range of issue +timestamps for 'suspect tickets'; if a presented ticket had an authtime in +that range, it would be rejected. In this way, a stolen ticket-granting +ticket or renewable ticket cannot be used to gain additional tickets +(renewals or otherwise) once the theft has been reported. Any normal ticket +obtained before it was reported stolen will still be valid (because they +require no interaction with the KDC), but only until their normal +expiration time. + +The ciphertext part of the response in the KRB_TGS_REP message is encrypted +in the sub-session key from the Authenticator, if present, or the session +key key from the ticket-granting ticket. It is not encrypted using the +client's secret key. Furthermore, the client's key's expiration date and +the key version number fields are left out since these values are stored +along with the client's database record, and that record is not needed to +satisfy a request based on a ticket-granting ticket. See section A.6 for +pseudocode. + +3.3.3.2. Encoding the transited field + +If the identity of the server in the TGT that is presented to the KDC as +part of the authentication header is that of the ticket-granting service, +but the TGT was issued from another realm, the KDC will look up the +inter-realm key shared with that realm and use that key to decrypt the +ticket. If the ticket is valid, then the KDC will honor the request, +subject to the constraints outlined above in the section describing the AS +exchange. The realm part of the client's identity will be taken from the +ticket-granting ticket. The name of the realm that issued the +ticket-granting ticket will be added to the transited field of the ticket +to be issued. This is accomplished by reading the transited field from the +ticket-granting ticket (which is treated as an unordered set of realm +names), adding the new realm to the set, then constructing and writing out +its encoded (shorthand) form (this may involve a rearrangement of the +existing encoding). + +Note that the ticket-granting service does not add the name of its own +realm. Instead, its responsibility is to add the name of the previous +realm. This prevents a malicious Kerberos server from intentionally leaving +out its own name (it could, however, omit other realms' names). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The names of neither the local realm nor the principal's realm are to be +included in the transited field. They appear elsewhere in the ticket and +both are known to have taken part in authenticating the principal. Since +the endpoints are not included, both local and single-hop inter-realm +authentication result in a transited field that is empty. + +Because the name of each realm transited is added to this field, it might +potentially be very long. To decrease the length of this field, its +contents are encoded. The initially supported encoding is optimized for the +normal case of inter-realm communication: a hierarchical arrangement of +realms using either domain or X.500 style realm names. This encoding +(called DOMAIN-X500-COMPRESS) is now described. + +Realm names in the transited field are separated by a ",". The ",", "\", +trailing "."s, and leading spaces (" ") are special characters, and if they +are part of a realm name, they must be quoted in the transited field by +preced- ing them with a "\". + +A realm name ending with a "." is interpreted as being prepended to the +previous realm. For example, we can encode traversal of EDU, MIT.EDU, +ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + +Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that +they would not be included in this field, and we would have: + + "EDU,MIT.,WASHINGTON.EDU" + +A realm name beginning with a "/" is interpreted as being appended to the +previous realm[18]. If it is to stand by itself, then it should be preceded +by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, +/COM/HP, /COM, and /COM/DEC as: + + "/COM,/HP,/APOLLO, /COM/DEC". + +Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they +they would not be included in this field, and we would have: + + "/COM,/HP" + +A null subfield preceding or following a "," indicates that all realms +between the previous realm and the next realm have been traversed[19]. +Thus, "," means that all realms along the path between the client and the +server have been traversed. ",EDU, /COM," means that that all realms from +the client's realm up to EDU (in a domain style hierarchy) have been +traversed, and that everything from /COM down to the server's realm in an +X.500 style has also been traversed. This could occur if the EDU realm in +one hierarchy shares an inter-realm key directly with the /COM realm in +another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP message + +When the KRB_TGS_REP is received by the client, it is processed in the same +manner as the KRB_AS_REP processing described above. The primary difference +is that the ciphertext part of the response must be decrypted using the +session key from the ticket-granting ticket rather than the client's secret +key. The server name returned in the reply is the true principal name of +the service. See section A.7 for pseudocode. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.4. The KRB_SAFE Exchange + +The KRB_SAFE message may be used by clients requiring the ability to detect +modifications of messages they exchange. It achieves this by including a +keyed collision-proof checksum of the user data and some control +information. The checksum is keyed with an encryption key (usually the last +key negotiated via subkeys, or the session key if no negotiation has +occured). + +3.4.1. Generation of a KRB_SAFE message + +When an application wishes to send a KRB_SAFE message, it collects its data +and the appropriate control information and computes a checksum over them. +The checksum algorithm should be a keyed one-way hash function (such as the +RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES +MAC), generated using the sub-session key if present, or the session key. +Different algorithms may be selected by changing the checksum type in the +message. Unkeyed or non-collision-proof checksums are not suitable for this +use. + +The control information for the KRB_SAFE message includes both a timestamp +and a sequence number. The designer of an application using the KRB_SAFE +message must choose at least one of the two mechanisms. This choice should +be based on the needs of the application protocol. + +Sequence numbers are useful when all messages sent will be received by +one's peer. Connection state is presently required to maintain the session +key, so maintaining the next sequence number should not present an +additional problem. + +If the application protocol is expected to tolerate lost messages without +them being resent, the use of the timestamp is the appropriate replay +detection mechanism. Using timestamps is also the appropriate mechanism for +multi-cast protocols where all of one's peers share a common sub-session +key, but some messages will be sent to a subset of one's peers. + +After computing the checksum, the client then transmits the information and +checksum to the recipient in the message format specified in section 5.6.1. + +3.4.2. Receipt of KRB_SAFE message + +When an application receives a KRB_SAFE message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + +The message is first checked by verifying that the protocol version and +type fields match the current version and KRB_SAFE, respectively. A +mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. +The application verifies that the checksum used is a collision-proof keyed +checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If +the sender's address was included in the control information, the recipient +verifies that the operating system's report of the sender's address matches +the sender's address in the message, and (if a recipient address is +specified or the recipient requires an address) that one of the recipient's +addresses appears as the recipient's address in the message. A failed match +for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp +and usec and/or the sequence number fields are checked. If timestamp and +usec are expected and not present, or they are present but not current, the +KRB_AP_ERR_SKEW error is generated. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT +error is generated. If an incorrect sequence number is included, or a +sequence number is expected but not present, the KRB_AP_ERR_BADORDER error +is generated. If neither a time-stamp and usec or a sequence number is +present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is +computed over the data and control information, and if it doesn't match the +received checksum, a KRB_AP_ERR_MODIFIED error is generated. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +If all the checks succeed, the application is assured that the message was +generated by its peer and was not modi- fied in transit. + +3.5. The KRB_PRIV Exchange + +The KRB_PRIV message may be used by clients requiring confidentiality and +the ability to detect modifications of exchanged messages. It achieves this +by encrypting the messages and adding control information. + +3.5.1. Generation of a KRB_PRIV message + +When an application wishes to send a KRB_PRIV message, it collects its data +and the appropriate control information (specified in section 5.7.1) and +encrypts them under an encryption key (usually the last key negotiated via +subkeys, or the session key if no negotiation has occured). As part of the +control information, the client must choose to use either a timestamp or a +sequence number (or both); see the discussion in section 3.4.1 for +guidelines on which to use. After the user data and control information are +encrypted, the client transmits the ciphertext and some 'envelope' +information to the recipient. + +3.5.2. Receipt of KRB_PRIV message + +When an application receives a KRB_PRIV message, it verifies it as follows. +If any error occurs, an error code is reported for use by the application. + +The message is first checked by verifying that the protocol version and +type fields match the current version and KRB_PRIV, respectively. A +mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. +The application then decrypts the ciphertext and processes the resultant +plaintext. If decryption shows the data to have been modified, a +KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was +included in the control information, the recipient verifies that the +operating system's report of the sender's address matches the sender's +address in the message, and (if a recipient address is specified or the +recipient requires an address) that one of the recipient's addresses +appears as the recipient's address in the message. A failed match for +either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and +usec and/or the sequence number fields are checked. If timestamp and usec +are expected and not present, or they are present but not current, the +KRB_AP_ERR_SKEW error is generated. If the server name, along with the +client name, time and microsecond fields from the Authenticator match any +recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an +incorrect sequence number is included, or a sequence number is expected but +not present, the KRB_AP_ERR_BADORDER error is generated. If neither a +time-stamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED +error is generated. + +If all the checks succeed, the application can assume the message was +generated by its peer, and was securely transmitted (without intruders able +to see the unencrypted contents). + +3.6. The KRB_CRED Exchange + +The KRB_CRED message may be used by clients requiring the ability to send +Kerberos credentials from one host to another. It achieves this by sending +the tickets together with encrypted data containing the session keys and +other information associated with the tickets. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +3.6.1. Generation of a KRB_CRED message + +When an application wishes to send a KRB_CRED message it first (using the +KRB_TGS exchange) obtains credentials to be sent to the remote host. It +then constructs a KRB_CRED message using the ticket or tickets so obtained, +placing the session key needed to use each ticket in the key field of the +corresponding KrbCredInfo sequence of the encrypted part of the the +KRB_CRED message. + +Other information associated with each ticket and obtained during the +KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence +in the encrypted part of the KRB_CRED message. The current time and, if +specifically required by the application the nonce, s-address, and +r-address fields, are placed in the encrypted part of the KRB_CRED message +which is then encrypted under an encryption key previosuly exchanged in the +KRB_AP exchange (usually the last key negotiated via subkeys, or the +session key if no negotiation has occured). + +3.6.2. Receipt of KRB_CRED message + +When an application receives a KRB_CRED message, it verifies it. If any +error occurs, an error code is reported for use by the application. The +message is verified by checking that the protocol version and type fields +match the current version and KRB_CRED, respectively. A mismatch generates +a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then +decrypts the ciphertext and processes the resultant plaintext. If +decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY +error is generated. + +If present or required, the recipient verifies that the operating system's +report of the sender's address matches the sender's address in the message, +and that one of the recipient's addresses appears as the recipient's +address in the message. A failed match for either case generates a +KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce +field if required) are checked next. If the timestamp and usec are not +present, or they are present but not current, the KRB_AP_ERR_SKEW error is +generated. + +If all the checks succeed, the application stores each of the new tickets +in its ticket cache together with the session key and other information in +the corresponding KrbCredInfo sequence from the encrypted part of the +KRB_CRED message. + +4. The Kerberos Database + +The Kerberos server must have access to a database containing the principal +identifiers and secret keys of principals to be authenticated[21]. + +4.1. Database contents + +A database entry should contain at least the following fields: + +Field Value + +name Principal's identifier +key Principal's secret key +p_kvno Principal's key version +max_life Maximum lifetime for Tickets +max_renewable_life Maximum total lifetime for renewable Tickets + +The name field is an encoding of the principal's identifier. The key field +contains an encryption key. This key is the principal's secret key. (The +key can be encrypted before storage under a Kerberos "master key" to +protect it in case the database is compromised but the master key is not. +In that case, an extra field must be added to indicate the master key + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +version used, see below.) The p_kvno field is the key version number of the +principal's secret key. The max_life field contains the maximum allowable +lifetime (endtime - starttime) for any Ticket issued for this principal. +The max_renewable_life field contains the maximum allowable total lifetime +for any renewable Ticket issued for this principal. (See section 3.1 for a +description of how these lifetimes are used in determining the lifetime of +a given Ticket.) + +A server may provide KDC service to several realms, as long as the database +representation provides a mechanism to distinguish between principal +records with identifiers which differ only in the realm name. + +When an application server's key changes, if the change is routine (i.e. +not the result of disclosure of the old key), the old key should be +retained by the server until all tickets that had been issued using that +key have expired. Because of this, it is possible for several keys to be +active for a single principal. Ciphertext encrypted in a principal's key is +always tagged with the version of the key that was used for encryption, to +help the recipient find the proper key for decryption. + +When more than one key is active for a particular principal, the principal +will have more than one record in the Kerberos database. The keys and key +version numbers will differ between the records (the rest of the fields may +or may not be the same). Whenever Kerberos issues a ticket, or responds to +a request for initial authentication, the most recent key (known by the +Kerberos server) will be used for encryption. This is the key with the +highest key version number. + +4.2. Additional fields + +Project Athena's KDC implementation uses additional fields in its database: + +Field Value + +K_kvno Kerberos' key version +expiration Expiration date for entry +attributes Bit field of attributes +mod_date Timestamp of last modification +mod_name Modifying principal's identifier + +The K_kvno field indicates the key version of the Kerberos master key under +which the principal's secret key is encrypted. + +After an entry's expiration date has passed, the KDC will return an error +to any client attempting to gain tickets as or for the principal. (A +database may want to maintain two expiration dates: one for the principal, +and one for the principal's current key. This allows password aging to work +independently of the principal's expiration date. However, due to the +limited space in the responses, the KDC must combine the key expiration and +principal expiration date into a single value called 'key_exp', which is +used as a hint to the user to take administrative action.) + +The attributes field is a bitfield used to govern the operations involving +the principal. This field might be useful in conjunction with user +registration procedures, for site-specific policy implementations (Project +Athena currently uses it for their user registration process controlled by +the system-wide database service, Moira [LGDSR87]), to identify whether a +principal can play the role of a client or server or both, to note whether +a server is appropriate trusted to recieve credentials delegated by a +client, or to identify the 'string to key' conversion algorithm used for a +principal's key[22]. Other bits are used to indicate that certain ticket +options should not be allowed in tickets encrypted under a principal's key +(one bit each): Disallow issuing postdated tickets, disallow issuing +forwardable tickets, disallow issuing tickets based on TGT authentication, +disallow issuing renewable tickets, disallow issuing proxiable tickets, and +disallow issuing tickets for which the principal is the server. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The mod_date field contains the time of last modification of the entry, and +the mod_name field contains the name of the principal which last modified +the entry. + +4.3. Frequently Changing Fields + +Some KDC implementations may wish to maintain the last time that a request +was made by a particular principal. Information that might be maintained +includes the time of the last request, the time of the last request for a +ticket-granting ticket, the time of the last use of a ticket-granting +ticket, or other times. This information can then be returned to the user +in the last-req field (see section 5.2). + +Other frequently changing information that can be maintained is the latest +expiration time for any tickets that have been issued using each key. This +field would be used to indicate how long old keys must remain valid to +allow the continued use of outstanding tickets. + +4.4. Site Constants + +The KDC implementation should have the following configurable constants or +options, to allow an administrator to make and enforce policy decisions: + + * The minimum supported lifetime (used to determine whether the + KDC_ERR_NEVER_VALID error should be returned). This constant should + reflect reasonable expectations of round-trip time to the KDC, + encryption/decryption time, and processing time by the client and + target server, and it should allow for a minimum 'useful' lifetime. + * The maximum allowable total (renewable) lifetime of a ticket + (renew_till - starttime). + * The maximum allowable lifetime of a ticket (endtime - starttime). + * Whether to allow the issue of tickets with empty address fields + (including the ability to specify that such tickets may only be issued + if the request specifies some authorization_data). + * Whether proxiable, forwardable, renewable or post-datable tickets are + to be issued. + +5. Message Specifications + +The following sections describe the exact contents and encoding of protocol +messages and objects. The ASN.1 base definitions are presented in the first +subsection. The remaining subsections specify the protocol objects (tickets +and authenticators) and messages. Specification of encryption and checksum +techniques, and the fields related to them, appear in section 6. + +Optional field in ASN.1 sequences + +For optional integer value and date fields in ASN.1 sequences where a +default value has been specified, certain default values will not be +allowed in the encoding because these values will always be represented +through defaulting by the absence of the optional field. For example, one +will not send a microsecond zero value because one must make sure that +there is only one way to encode this value. + +Additional fields in ASN.1 sequences + +Implementations receiving Kerberos messages with additional fields present +in ASN.1 sequences should carry the those fields through, unmodified, when +the message is forwarded. Implementations should not drop such fields if +the sequence is reencoded. + +5.1. ASN.1 Distinguished Encoding Representation + +All uses of ASN.1 in Kerberos shall use the Distinguished Encoding +Representation of the data elements as described in the X.509 +specification, section 8.7 [X509-88]. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.2. ASN.1 Base Definitions + +The following ASN.1 base definitions are used in the rest of this section. +Note that since the underscore character (_) is not permitted in ASN.1 +names, the hyphen (-) is used in its place for the purposes of ASN.1 names. + +Realm ::= GeneralString +PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString +} + +Kerberos realms are encoded as GeneralStrings. Realms shall not contain a +character with the code 0 (the ASCII NUL). Most realms will usually consist +of several components separated by periods (.), in the style of Internet +Domain Names, or separated by slashes (/) in the style of X.500 names. +Acceptable forms for realm names are specified in section 7. A +PrincipalName is a typed sequence of components consisting of the following +sub-fields: + +name-type + This field specifies the type of name that follows. Pre-defined values + for this field are specified in section 7.2. The name-type should be + treated as a hint. Ignoring the name type, no two names can be the + same (i.e. at least one of the components, or the realm, must be + different). This constraint may be eliminated in the future. +name-string + This field encodes a sequence of components that form a name, each + component encoded as a GeneralString. Taken together, a PrincipalName + and a Realm form a principal identifier. Most PrincipalNames will have + only a few components (typically one or two). + +KerberosTime ::= GeneralizedTime + -- Specifying UTC time zone (Z) + +The timestamps used in Kerberos are encoded as GeneralizedTimes. An +encoding shall specify the UTC time zone (Z) and shall not include any +fractional portions of the seconds. It further shall not include any +separators. Example: The only valid format for UTC time 6 minutes, 27 +seconds after 9 pm on 6 November 1985 is 19851106210627Z. + +HostAddress ::= SEQUENCE { + addr-type[0] INTEGER, + address[1] OCTET STRING +} + +HostAddresses ::= SEQUENCE OF HostAddress + +The host adddress encodings consists of two fields: + +addr-type + This field specifies the type of address that follows. Pre-defined + values for this field are specified in section 8.1. +address + This field encodes a single address of type addr-type. + +The two forms differ slightly. HostAddress contains exactly one address; +HostAddresses contains a sequence of possibly many addresses. + +AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type[0] INTEGER, + ad-data[1] OCTET STRING +} + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +ad-data + This field contains authorization data to be interpreted according to + the value of the corresponding ad-type field. +ad-type + This field specifies the format for the ad-data subfield. All negative + values are reserved for local use. Non-negative values are reserved + for registered use. + +Each sequence of type and data is refered to as an authorization element. +Elements may be application specific, however, there is a common set of +recursive elements that should be understood by all implementations. These +elements contain other elements embedded within them, and the +interpretation of the encapsulating element determines which of the +embedded elements must be interpreted, and which may be ignored. +Definitions for these common elements may be found in Appendix B. + +TicketExtensions ::= SEQUENCE OF SEQUENCE { + te-type[0] INTEGER, + te-data[1] OCTET STRING +} + + + +te-data + This field contains opaque data that must be caried with the ticket to + support extensions to the Kerberos protocol including but not limited + to some forms of inter-realm key exchange and plaintext authorization + data. See appendix C for some common uses of this field. +te-type + This field specifies the format for the te-data subfield. All negative + values are reserved for local use. Non-negative values are reserved + for registered use. + +APOptions ::= BIT STRING + -- reserved(0), + -- use-session-key(1), + -- mutual-required(2) + +TicketFlags ::= BIT STRING + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- may-postdate(5), + -- postdated(6), + -- invalid(7), + -- renewable(8), + -- initial(9), + -- pre-authent(10), + -- hw-authent(11), + -- transited-policy-checked(12), + -- ok-as-delegate(13) + +KDCOptions ::= BIT STRING io + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + -- proxiable(3), + -- proxy(4), + -- allow-postdate(5), + -- postdated(6), + -- unused7(7), + -- renewable(8), + -- unused9(9), + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + -- unused10(10), + -- unused11(11), + -- unused12(12), + -- unused13(13), + -- requestanonymous(14), + -- canonicalize(15), + -- disable-transited-check(26), + -- renewable-ok(27), + -- enc-tkt-in-skey(28), + -- renew(30), + -- validate(31) + +ASN.1 Bit strings have a length and a value. When used in Kerberos for the +APOptions, TicketFlags, and KDCOptions, the length of the bit string on +generated values should be the smallest number of bits needed to include +the highest order bit that is set (1), but in no case less than 32 bits. +The ASN.1 representation of the bit strings uses unnamed bits, with the +meaning of the individual bits defined by the comments in the specification +above. Implementations should accept values of bit strings of any length +and treat the value of flags corresponding to bits beyond the end of the +bit string as if the bit were reset (0). Comparison of bit strings of +different length should treat the smaller string as if it were padded with +zeros beyond the high order bits to the length of the longer string[23]. + +LastReq ::= SEQUENCE OF SEQUENCE { + lr-type[0] INTEGER, + lr-value[1] KerberosTime +} + +lr-type + This field indicates how the following lr-value field is to be + interpreted. Negative values indicate that the information pertains + only to the responding server. Non-negative values pertain to all + servers for the realm. If the lr-type field is zero (0), then no + information is conveyed by the lr-value subfield. If the absolute + value of the lr-type field is one (1), then the lr-value subfield is + the time of last initial request for a TGT. If it is two (2), then the + lr-value subfield is the time of last initial request. If it is three + (3), then the lr-value subfield is the time of issue for the newest + ticket-granting ticket used. If it is four (4), then the lr-value + subfield is the time of the last renewal. If it is five (5), then the + lr-value subfield is the time of last request (of any type). If it is + (6), then the lr-value subfield is the time when the password will + expire. +lr-value + This field contains the time of the last request. the time must be + interpreted according to the contents of the accompanying lr-type + subfield. + +See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, +EncryptionKey, EncryptionType, and KeyType. + +5.3. Tickets and Authenticators + +This section describes the format and encryption parameters for tickets and +authenticators. When a ticket or authenticator is included in a protocol +message it is treated as an opaque object. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.3.1. Tickets + +A ticket is a record that helps a client authenticate to a service. A +Ticket contains the following information: + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno[0] INTEGER, + realm[1] Realm, + sname[2] PrincipalName, + enc-part[3] EncryptedData, + extensions[4] TicketExtensions OPTIONAL +} + +-- Encrypted part of ticket +EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags[0] TicketFlags, + key[1] EncryptionKey, + crealm[2] Realm, + cname[3] PrincipalName, + transited[4] TransitedEncoding, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + caddr[9] HostAddresses OPTIONAL, + authorization-data[10] AuthorizationData OPTIONAL +} +-- encoded Transited field +TransitedEncoding ::= SEQUENCE { + tr-type[0] INTEGER, -- must be +registered + contents[1] OCTET STRING +} + +The encoding of EncTicketPart is encrypted in the key shared by Kerberos +and the end server (the server's secret key). See section 6 for the format +of the ciphertext. + +tkt-vno + This field specifies the version number for the ticket format. This + document describes version number 5. +realm + This field specifies the realm that issued a ticket. It also serves to + identify the realm part of the server's principal identifier. Since a + Kerberos server can only issue tickets for servers within its realm, + the two will always be identical. +sname + This field specifies all components of the name part of the server's + identity, including those parts that identify a specific instance of a + service. +enc-part + This field holds the encrypted encoding of the EncTicketPart sequence. +extensions + This optional field contains a sequence of extentions that may be used + to carry information that must be carried with the ticket to support + several extensions, including but not limited to plaintext + authorization data, tokens for exchanging inter-realm keys, and other + information that must be associated with a ticket for use by the + application server. See Appendix C for definitions of some common + extensions. + + Note that some older versions of Kerberos did not support this field. + Because this is an optional field it will not break older clients, but + older clients might strip this field from the ticket before sending it + to the application server. This limits the usefulness of this ticket + field to environments where the ticket will not be parsed and + reconstructed by these older Kerberos clients. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + If it is known that the client will strip this field from the ticket, + as an interim measure the KDC may append this field to the end of the + enc-part of the ticket and append a traler indicating the lenght of + the appended extensions field. (this paragraph is open for discussion, + including the form of the traler). +flags + This field indicates which of various options were used or requested + when the ticket was issued. It is a bit-field, where the selected + options are indicated by the bit being set (1), and the unselected + options and reserved fields being reset (0). Bit 0 is the most + significant bit. The encoding of the bits is specified in section 5.2. + The flags are described in more detail above in section 2. The + meanings of the flags are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. When set, this + flag tells the ticket-granting server + that it is OK to issue a new ticket- + granting ticket with a different network + address based on the presented ticket. + + 2 FORWARDED + When set, this flag indicates that the + ticket has either been forwarded or was + issued based on authentication involving + a forwarded ticket-granting ticket. + + 3 PROXIABLE + The PROXIABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. The PROXIABLE + flag has an interpretation identical to + that of the FORWARDABLE flag, except + that the PROXIABLE flag tells the + ticket-granting server that only non- + ticket-granting tickets may be issued + with different network addresses. + + 4 PROXY + When set, this flag indicates that a + ticket is a proxy. + + 5 MAY-POSTDATE + The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. This flag tells + the ticket-granting server that a post- + dated ticket may be issued based on this + ticket-granting ticket. + + 6 POSTDATED + This flag indicates that this ticket has + been postdated. The end-service can + check the authtime field to see when the + original authentication occurred. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 7 INVALID + This flag indicates that a ticket is + invalid, and it must be validated by the + KDC before use. Application servers + must reject tickets which have this flag + set. + + 8 RENEWABLE + The RENEWABLE flag is normally only + interpreted by the TGS, and can usually + be ignored by end servers (some particu- + larly careful servers may wish to disal- + low renewable tickets). A renewable + ticket can be used to obtain a replace- + ment ticket that expires at a later + date. + + 9 INITIAL + This flag indicates that this ticket was + issued using the AS protocol, and not + issued based on a ticket-granting + ticket. + + 10 PRE-AUTHENT + This flag indicates that during initial + authentication, the client was authenti- + cated by the KDC before a ticket was + issued. The strength of the pre- + authentication method is not indicated, + but is acceptable to the KDC. + + 11 HW-AUTHENT + This flag indicates that the protocol + employed for initial authentication + required the use of hardware expected to + be possessed solely by the named client. + The hardware authentication method is + selected by the KDC and the strength of + the method is not indicated. + + 12 TRANSITED This flag indicates that the KDC for the + POLICY-CHECKED realm has checked the transited field + against a realm defined policy for + trusted certifiers. If this flag is + reset (0), then the application server + must check the transited field itself, + and if unable to do so it must reject + the authentication. If the flag is set + (1) then the application server may skip + its own validation of the transited + field, relying on the validation + performed by the KDC. At its option the + application server may still apply its + own validation based on a separate + policy for acceptance. + + 13 OK-AS-DELEGATE This flag indicates that the server (not + the client) specified in the ticket has + been determined by policy of the realm + to be a suitable recipient of + delegation. A client can use the + presence of this flag to help it make a + decision whether to delegate credentials + (either grant a proxy or a forwarded + ticket granting ticket) to this server. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The client is free to ignore the value + of this flag. When setting this flag, + an administrator should consider the + Security and placement of the server on + which the service will run, as well as + whether the service requires the use of + delegated credentials. + + 14 ANONYMOUS + This flag indicates that the principal + named in the ticket is a generic princi- + pal for the realm and does not identify + the individual using the ticket. The + purpose of the ticket is only to + securely distribute a session key, and + not to identify the user. Subsequent + requests using the same ticket and ses- + sion may be considered as originating + from the same user, but requests with + the same username but a different ticket + are likely to originate from different + users. + + 15-31 RESERVED + Reserved for future use. + +key + This field exists in the ticket and the KDC response and is used to + pass the session key from Kerberos to the application server and the + client. The field's encoding is described in section 6.2. +crealm + This field contains the name of the realm in which the client is + registered and in which initial authentication took place. +cname + This field contains the name part of the client's principal + identifier. +transited + This field lists the names of the Kerberos realms that took part in + authenticating the user to whom this ticket was issued. It does not + specify the order in which the realms were transited. See section + 3.3.3.2 for details on how this field encodes the traversed realms. + When the names of CA's are to be embedded inthe transited field (as + specified for some extentions to the protocol), the X.500 names of the + CA's should be mapped into items in the transited field using the + mapping defined by RFC2253. +authtime + This field indicates the time of initial authentication for the named + principal. It is the time of issue for the original ticket on which + this ticket is based. It is included in the ticket to provide + additional information to the end service, and to provide the + necessary information for implementation of a `hot list' service at + the KDC. An end service that is particularly paranoid could refuse to + accept tickets for which the initial authentication occurred "too far" + in the past. This field is also returned as part of the response from + the KDC. When returned as part of the response to initial + authentication (KRB_AS_REP), this is the current time on the Kerberos + server[24]. +starttime + This field in the ticket specifies the time after which the ticket is + valid. Together with endtime, this field specifies the life of the + ticket. If it is absent from the ticket, its value should be treated + as that of the authtime field. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +endtime + This field contains the time after which the ticket will not be + honored (its expiration time). Note that individual services may place + their own limits on the life of a ticket and may reject tickets which + have not yet expired. As such, this is really an upper bound on the + expiration time for the ticket. +renew-till + This field is only present in tickets that have the RENEWABLE flag set + in the flags field. It indicates the maximum endtime that may be + included in a renewal. It can be thought of as the absolute expiration + time for the ticket, including all renewals. +caddr + This field in a ticket contains zero (if omitted) or more (if present) + host addresses. These are the addresses from which the ticket can be + used. If there are no addresses, the ticket can be used from any + location. The decision by the KDC to issue or by the end server to + accept zero-address tickets is a policy decision and is left to the + Kerberos and end-service administrators; they may refuse to issue or + accept such tickets. The suggested and default policy, however, is + that such tickets will only be issued or accepted when additional + information that can be used to restrict the use of the ticket is + included in the authorization_data field. Such a ticket is a + capability. + + Network addresses are included in the ticket to make it harder for an + attacker to use stolen credentials. Because the session key is not + sent over the network in cleartext, credentials can't be stolen simply + by listening to the network; an attacker has to gain access to the + session key (perhaps through operating system security breaches or a + careless user's unattended session) to make use of stolen tickets. + + It is important to note that the network address from which a + connection is received cannot be reliably determined. Even if it could + be, an attacker who has compromised the client's workstation could use + the credentials from there. Including the network addresses only makes + it more difficult, not impossible, for an attacker to walk off with + stolen credentials and then use them from a "safe" location. +authorization-data + The authorization-data field is used to pass authorization data from + the principal on whose behalf a ticket was issued to the application + service. If no authorization data is included, this field will be left + out. Experience has shown that the name of this field is confusing, + and that a better name for this field would be restrictions. + Unfortunately, it is not possible to change the name of this field at + this time. + + This field contains restrictions on any authority obtained on the + basis of authentication using the ticket. It is possible for any + principal in posession of credentials to add entries to the + authorization data field since these entries further restrict what can + be done with the ticket. Such additions can be made by specifying the + additional entries when a new ticket is obtained during the TGS + exchange, or they may be added during chained delegation using the + authorization data field of the authenticator. + + Because entries may be added to this field by the holder of + credentials, except when an entry is separately authenticated by + encapulation in the kdc-issued element, it is not allowable for the + presence of an entry in the authorization data field of a ticket to + amplify the priveleges one would obtain from using a ticket. + + The data in this field may be specific to the end service; the field + will contain the names of service specific objects, and the rights to + those objects. The format for this field is described in section 5.2. + Although Kerberos is not concerned with the format of the contents of + the sub-fields, it does carry type information (ad-type). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + By using the authorization_data field, a principal is able to issue a + proxy that is valid for a specific purpose. For example, a client + wishing to print a file can obtain a file server proxy to be passed to + the print server. By specifying the name of the file in the + authorization_data field, the file server knows that the print server + can only use the client's rights when accessing the particular file to + be printed. + + A separate service providing authorization or certifying group + membership may be built using the authorization-data field. In this + case, the entity granting authorization (not the authorized entity), + may obtain a ticket in its own name (e.g. the ticket is issued in the + name of a privelege server), and this entity adds restrictions on its + own authority and delegates the restricted authority through a proxy + to the client. The client would then present this authorization + credential to the application server separately from the + authentication exchange. Alternatively, such authorization credentials + may be embedded in the ticket authenticating the authorized entity, + when the authorization is separately authenticated using the + kdc-issued authorization data element (see B.4). + + Similarly, if one specifies the authorization-data field of a proxy + and leaves the host addresses blank, the resulting ticket and session + key can be treated as a capability. See [Neu93] for some suggested + uses of this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +5.3.2. Authenticators + +An authenticator is a record sent with a ticket to a server to certify the +client's knowledge of the encryption key in the ticket, to help the server +detect replays, and to help choose a "true session key" to use with the +particular session. The encoding is encrypted in the ticket's session key +shared by the client and the server: + +-- Unencrypted authenticator +Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno[0] INTEGER, + crealm[1] Realm, + cname[2] PrincipalName, + cksum[3] Checksum OPTIONAL, + cusec[4] INTEGER, + ctime[5] KerberosTime, + subkey[6] EncryptionKey OPTIONAL, + seq-number[7] INTEGER OPTIONAL, + authorization-data[8] AuthorizationData OPTIONAL +} + + +authenticator-vno + This field specifies the version number for the format of the + authenticator. This document specifies version 5. +crealm and cname + These fields are the same as those described for the ticket in section + 5.3.1. +cksum + This field contains a checksum of the the applica- tion data that + accompanies the KRB_AP_REQ. +cusec + This field contains the microsecond part of the client's timestamp. + Its value (before encryption) ranges from 0 to 999999. It often + appears along with ctime. The two fields are used together to specify + a reasonably accurate timestamp. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +ctime + This field contains the current time on the client's host. +subkey + This field contains the client's choice for an encryption key which is + to be used to protect this specific application session. Unless an + application specifies otherwise, if this field is left out the session + key from the ticket will be used. +seq-number + This optional field includes the initial sequence number to be used by + the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to + detect replays (It may also be used by application specific messages). + When included in the authenticator this field specifies the initial + sequence number for messages from the client to the server. When + included in the AP-REP message, the initial sequence number is that + for messages from the server to the client. When used in KRB_PRIV or + KRB_SAFE messages, it is incremented by one after each message is + sent. Sequence numbers fall in the range of 0 through 2^32 - 1 and + wrap to zero following the value 2^32 - 1. + + For sequence numbers to adequately support the detection of replays + they should be non-repeating, even across connection boundaries. The + initial sequence number should be random and uniformly distributed + across the full space of possible sequence numbers, so that it cannot + be guessed by an attacker and so that it and the successive sequence + numbers do not repeat other sequences. +authorization-data + This field is the same as described for the ticket in section 5.3.1. + It is optional and will only appear when additional restrictions are + to be placed on the use of a ticket, beyond those carried in the + ticket itself. + +5.4. Specifications for the AS and TGS exchanges + +This section specifies the format of the messages used in the exchange +between the client and the Kerberos server. The format of possible error +messages appears in section 5.9.1. + +5.4.1. KRB_KDC_REQ definition + +The KRB_KDC_REQ message has no type of its own. Instead, its type is one of +KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an +initial ticket or an additional ticket. In either case, the message is sent +from the client to the Authentication Server to request credentials for a +service. + +The message fields are: + +AS-REQ ::= [APPLICATION 10] KDC-REQ +TGS-REQ ::= [APPLICATION 12] KDC-REQ + +KDC-REQ ::= SEQUENCE { + pvno[1] INTEGER, + msg-type[2] INTEGER, + padata[3] SEQUENCE OF PA-DATA OPTIONAL, + req-body[4] KDC-REQ-BODY +} + +PA-DATA ::= SEQUENCE { + padata-type[1] INTEGER, + padata-value[2] OCTET STRING, + -- might be encoded AP-REQ +} + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +KDC-REQ-BODY ::= SEQUENCE { + kdc-options[0] KDCOptions, + cname[1] PrincipalName OPTIONAL, + -- Used only in AS-REQ + realm[2] Realm, -- Server's realm + -- Also client's in AS-REQ + sname[3] PrincipalName OPTIONAL, + from[4] KerberosTime OPTIONAL, + till[5] KerberosTime OPTIONAL, + rtime[6] KerberosTime OPTIONAL, + nonce[7] INTEGER, + etype[8] SEQUENCE OF INTEGER, + -- EncryptionType, + -- in preference order + addresses[9] HostAddresses OPTIONAL, + enc-authorization-data[10] EncryptedData OPTIONAL, + -- Encrypted AuthorizationData + -- encoding + additional-tickets[11] SEQUENCE OF Ticket OPTIONAL +} + +The fields in this message are: + +pvno + This field is included in each message, and specifies the protocol + version number. This document specifies protocol version 5. +msg-type + This field indicates the type of a protocol message. It will almost + always be the same as the application identifier associated with a + message. It is included to make the identifier more readily accessible + to the application. For the KDC-REQ message, this type will be + KRB_AS_REQ or KRB_TGS_REQ. +padata + The padata (pre-authentication data) field contains a sequence of + authentication information which may be needed before credentials can + be issued or decrypted. In the case of requests for additional tickets + (KRB_TGS_REQ), this field will include an element with padata-type of + PA-TGS-REQ and data of an authentication header (ticket-granting + ticket and authenticator). The checksum in the authenticator (which + must be collision-proof) is to be computed over the KDC-REQ-BODY + encoding. In most requests for initial authentication (KRB_AS_REQ) and + most replies (KDC-REP), the padata field will be left out. + + This field may also contain information needed by certain extensions + to the Kerberos protocol. For example, it might be used to initially + verify the identity of a client before any response is returned. When + this field is used to authenticate or pre-authenticate a request, it + should contain a keyed checksum over the KDC-REQ-BODY to bind the + pre-authentication data to rest of the request. The KDC, as a matter + of policy, may decide whether to honor a KDC-REQ which includes any + pre-authentication data that does not contain the checksum field. + PA-ENC-TIMESTAMP defines a pre-authentication data type that is used + for authenticating a client by way of an encrypted timestamp. This is + accomplished with a padata field with padata-type equal to + PA-ENC-TIMESTAMP and padata-value defined as follows (query: the + checksum is new in this definition. If the optional field will break + things we can keep the old PA-ENC-TS-ENC, and define a new alternate + form that includes the checksum). : + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + padata-type ::= PA-ENC-TIMESTAMP + padata-value ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp[0] KerberosTime, -- client's time + pausec[1] INTEGER OPTIONAL, + pachecksum[2] checksum OPTIONAL + -- keyed checksum of +KDC-REQ-BODY + } + + with patimestamp containing the client's time and pausec containing + the microseconds which may be omitted if a client will not generate + more than one request per second. The ciphertext (padata-value) + consists of the PA-ENC-TS-ENC sequence, encrypted using the client's + secret key. + + [use-specified-kvno item is here for discussion and may be removed] It + may also be used by the client to specify the version of a key that is + being used for accompanying preauthentication, and/or which should be + used to encrypt the reply from the KDC. + + PA-USE-SPECIFIED-KVNO ::= Integer + + The KDC should only accept and abide by the value of the + use-specified-kvno preauthentication data field when the specified key + is still valid and until use of a new key is confirmed. This situation + is likely to occur primarily during the period during which an updated + key is propagating to other KDC's in a realm. + + The padata field can also contain information needed to help the KDC + or the client select the key needed for generating or decrypting the + response. This form of the padata is useful for supporting the use of + certain token cards with Kerberos. The details of such extensions are + specified in separate documents. See [Pat92] for additional uses of + this field. +padata-type + The padata-type element of the padata field indicates the way that the + padata-value element is to be interpreted. Negative values of + padata-type are reserved for unregistered use; non-negative values are + used for a registered interpretation of the element type. +req-body + This field is a placeholder delimiting the extent of the remaining + fields. If a checksum is to be calculated over the request, it is + calculated over an encoding of the KDC-REQ-BODY sequence which is + enclosed within the req-body field. +kdc-options + This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the + KDC and indicates the flags that the client wants set on the tickets + as well as other information that is to modify the behavior of the + KDC. Where appropriate, the name of an option may be the same as the + flag that is set by that option. Although in most case, the bit in the + options field will be the same as that in the flags field, this is not + guaranteed, so it is not acceptable to simply copy the options field + to the flags field. There are various checks that must be made before + honoring an option anyway. + + The kdc_options field is a bit-field, where the selected options are + indicated by the bit being set (1), and the unselected options and + reserved fields being reset (0). The encoding of the bits is specified + in section 5.2. The options are described in more detail above in + section 2. The meanings of the options are: + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + Bit(s) Name Description + 0 RESERVED + Reserved for future expansion of +this + field. + + 1 FORWARDABLE + The FORWARDABLE option indicates +that + the ticket to be issued is to have +its + forwardable flag set. It may only +be + set on the initial request, or in a +sub- + sequent request if the +ticket-granting + ticket on which it is based is also +for- + wardable. + + 2 FORWARDED + The FORWARDED option is only +specified + in a request to the +ticket-granting + server and will only be honored if +the + ticket-granting ticket in the +request + has its FORWARDABLE bit set. +This + option indicates that this is a +request + for forwarding. The address(es) of +the + host from which the resulting ticket +is + to be valid are included in +the + addresses field of the request. + + 3 PROXIABLE + The PROXIABLE option indicates that +the + ticket to be issued is to have its +prox- + iable flag set. It may only be set +on + the initial request, or in a +subsequent + request if the ticket-granting ticket +on + which it is based is also proxiable. + + 4 PROXY + The PROXY option indicates that this +is + a request for a proxy. This option +will + only be honored if the +ticket-granting + ticket in the request has its +PROXIABLE + bit set. The address(es) of the +host + from which the resulting ticket is to +be + valid are included in the +addresses + field of the request. + + 5 ALLOW-POSTDATE + The ALLOW-POSTDATE option indicates +that + the ticket to be issued is to have +its + MAY-POSTDATE flag set. It may only +be + set on the initial request, or in a +sub- + sequent request if the +ticket-granting + ticket on which it is based also has +its + MAY-POSTDATE flag set. + + 6 POSTDATED + The POSTDATED option indicates that +this + is a request for a postdated +ticket. + This option will only be honored if +the + ticket-granting ticket on which it +is + based has its MAY-POSTDATE flag +set. + The resulting ticket will also have +its + INVALID flag set, and that flag may +be + reset by a subsequent request to the +KDC + after the starttime in the ticket +has + been reached. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 7 UNUSED + This option is presently unused. + + 8 RENEWABLE + The RENEWABLE option indicates that +the + ticket to be issued is to have +its + RENEWABLE flag set. It may only be +set + on the initial request, or when +the + ticket-granting ticket on which +the + request is based is also renewable. +If + this option is requested, then the +rtime + field in the request contains +the + desired absolute expiration time for +the + ticket. + + 9 RESERVED + Reserved for PK-Cross + + 10-13 UNUSED + These options are presently unused. + + 14 REQUEST-ANONYMOUS + The REQUEST-ANONYMOUS option +indicates + that the ticket to be issued is not +to + identify the user to which it +was + issued. Instead, the principal +identif- + ier is to be generic, as specified +by + the policy of the realm (e.g. +usually + anonymous@realm). The purpose of +the + ticket is only to securely distribute +a + session key, and not to identify +the + user. The ANONYMOUS flag on the +ticket + to be returned should be set. If +the + local realms policy does not +permit + anonymous credentials, the request is +to + be rejected. + + 15 CANONICALIZE + The CANONICALIZE option indicates that + the client will accept the return of a + true server name instead of the name + specified in the request. In addition + the client will be able to process + any TGT referrals that will direct + the client to another realm to locate + the requested server. If a KDC does + not support name- canonicalization, + the option is ignored and the + appropriate + KDC_ERR_C_PRINCIPAL_UNKNOWN or + KDC_ERR_S_PRINCIPAL_UNKNOWN error is + returned. [JBrezak] + + 16-25 RESERVED + Reserved for future use. + + 26 DISABLE-TRANSITED-CHECK + By default the KDC will check the + transited field of a ticket-granting- + ticket against the policy of the local + realm before it will issue derivative + tickets based on the ticket granting + ticket. If this flag is set in the + request, checking of the transited +field + is disabled. Tickets issued without +the + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + performance of this check will be +noted + by the reset (0) value of the + TRANSITED-POLICY-CHECKED flag, + indicating to the application server + that the tranisted field must be +checked + locally. KDC's are encouraged but not + required to honor the + DISABLE-TRANSITED-CHECK option. + + 27 RENEWABLE-OK + The RENEWABLE-OK option indicates that +a + renewable ticket will be acceptable if +a + ticket with the requested life +cannot + otherwise be provided. If a ticket +with + the requested life cannot be +provided, + then a renewable ticket may be +issued + with a renew-till equal to the +the + requested endtime. The value of +the + renew-till field may still be limited +by + local limits, or limits selected by +the + individual principal or server. + + 28 ENC-TKT-IN-SKEY + This option is used only by the +ticket- + granting service. The +ENC-TKT-IN-SKEY + option indicates that the ticket for +the + end server is to be encrypted in +the + session key from the additional +ticket- + granting ticket provided. + + 29 RESERVED + Reserved for future use. + + 30 RENEW + This option is used only by the +ticket- + granting service. The RENEW +option + indicates that the present request +is + for a renewal. The ticket provided +is + encrypted in the secret key for +the + server on which it is valid. +This + option will only be honored if +the + ticket to be renewed has its +RENEWABLE + flag set and if the time in its +renew- + till field has not passed. The +ticket + to be renewed is passed in the +padata + field as part of the +authentication + header. + + 31 VALIDATE + This option is used only by the +ticket- + granting service. The VALIDATE +option + indicates that the request is to +vali- + date a postdated ticket. It will +only + be honored if the ticket presented +is + postdated, presently has its +INVALID + flag set, and would be otherwise +usable + at this time. A ticket cannot be +vali- + dated before its starttime. The +ticket + presented for validation is encrypted +in + the key of the server for which it +is + valid and is passed in the padata +field + as part of the authentication header. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +cname and sname + These fields are the same as those described for the ticket in section + 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is + specified. If absent, the name of the server is taken from the name of + the client in the ticket passed as additional-tickets. +enc-authorization-data + The enc-authorization-data, if present (and it can only be present in + the TGS_REQ form), is an encoding of the desired authorization-data + encrypted under the sub-session key if present in the Authenticator, + or alternatively from the session key in the ticket-granting ticket, + both from the padata field in the KRB_AP_REQ. +realm + This field specifies the realm part of the server's principal + identifier. In the AS exchange, this is also the realm part of the + client's principal identifier. If the CANONICALIZE option is set, the + realm is used as a hint to the KDC for its database lookup. +from + This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket + requests when the requested ticket is to be postdated. It specifies + the desired start time for the requested ticket. If this field is + omitted then the KDC should use the current time instead. +till + This field contains the expiration date requested by the client in a + ticket request. It is optional and if omitted the requested ticket is + to have the maximum endtime permitted according to KDC policy for the + parties to the authentication exchange as limited by expiration date + of the ticket granting ticket or other preauthentication credentials. +rtime + This field is the requested renew-till time sent from a client to the + KDC in a ticket request. It is optional. +nonce + This field is part of the KDC request and response. It it intended to + hold a random number generated by the client. If the same number is + included in the encrypted response from the KDC, it provides evidence + that the response is fresh and has not been replayed by an attacker. + Nonces must never be re-used. Ideally, it should be generated + randomly, but if the correct time is known, it may suffice[25]. +etype + This field specifies the desired encryption algorithm to be used in + the response. +addresses + This field is included in the initial request for tickets, and + optionally included in requests for additional tickets from the + ticket-granting server. It specifies the addresses from which the + requested ticket is to be valid. Normally it includes the addresses + for the client's host. If a proxy is requested, this field will + contain other addresses. The contents of this field are usually copied + by the KDC into the caddr field of the resulting ticket. +additional-tickets + Additional tickets may be optionally included in a request to the + ticket-granting server. If the ENC-TKT-IN-SKEY option has been + specified, then the session key from the additional ticket will be + used in place of the server's key to encrypt the new ticket. When he + ENC-TKT-IN-SKEY option is used for user-to-user authentication, this + addional ticket may be a TGT issued by the local realm or an + inter-realm TGT issued for the current KDC's realm by a remote KDC. If + more than one option which requires additional tickets has been + specified, then the additional tickets are used in the order specified + by the ordering of the options bits (see kdc-options, above). + +The application code will be either ten (10) or twelve (12) depending on +whether the request is for an initial ticket (AS-REQ) or for an additional +ticket (TGS-REQ). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +The optional fields (addresses, authorization-data and additional-tickets) +are only included if necessary to perform the operation specified in the +kdc-options field. + +It should be noted that in KRB_TGS_REQ, the protocol version number appears +twice and two different message types appear: the KRB_TGS_REQ message +contains these fields as does the authentication header (KRB_AP_REQ) that +is passed in the padata field. + +5.4.2. KRB_KDC_REP definition + +The KRB_KDC_REP message format is used for the reply from the KDC for +either an initial (AS) request or a subsequent (TGS) request. There is no +message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP +or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply +depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in +the client's secret key, and the client's key version number is included in +the key version number for the encrypted data. For KRB_TGS_REP, the +ciphertext is encrypted in the sub-session key from the Authenticator, or +if absent, the session key from the ticket-granting ticket used in the +request. In that case, no version number will be present in the +EncryptedData sequence. + +The KRB_KDC_REP message contains the following fields: + +AS-REP ::= [APPLICATION 11] KDC-REP +TGS-REP ::= [APPLICATION 13] KDC-REP + +KDC-REP ::= SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + padata[2] SEQUENCE OF PA-DATA OPTIONAL, + crealm[3] Realm, + cname[4] PrincipalName, + ticket[5] Ticket, + enc-part[6] EncryptedData +} + +EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart +EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + +EncKDCRepPart ::= SEQUENCE { + key[0] EncryptionKey, + last-req[1] LastReq, + nonce[2] INTEGER, + key-expiration[3] KerberosTime OPTIONAL, + flags[4] TicketFlags, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + srealm[9] Realm, + sname[10] PrincipalName, + caddr[11] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is either + KRB_AS_REP or KRB_TGS_REP. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +padata + This field is described in detail in section 5.4.1. One possible use + for this field is to encode an alternate "mix-in" string to be used + with a string-to-key algorithm (such as is described in section + 6.3.2). This ability is useful to ease transitions if a realm name + needs to change (e.g. when a company is acquired); in such a case all + existing password-derived entries in the KDC database would be flagged + as needing a special mix-in string until the next password change. +crealm, cname, srealm and sname + These fields are the same as those described for the ticket in section + 5.3.1. +ticket + The newly-issued ticket, from section 5.3.1. +enc-part + This field is a place holder for the ciphertext and related + information that forms the encrypted part of a message. The + description of the encrypted part of the message follows each + appearance of this field. The encrypted part is encoded as described + in section 6.1. +key + This field is the same as described for the ticket in section 5.3.1. +last-req + This field is returned by the KDC and specifies the time(s) of the + last request by a principal. Depending on what information is + available, this might be the last time that a request for a + ticket-granting ticket was made, or the last time that a request based + on a ticket-granting ticket was successful. It also might cover all + servers for a realm, or just the particular server. Some + implementations may display this information to the user to aid in + discovering unauthorized use of one's identity. It is similar in + spirit to the last login time displayed when logging into timesharing + systems. +nonce + This field is described above in section 5.4.1. +key-expiration + The key-expiration field is part of the response from the KDC and + specifies the time that the client's secret key is due to expire. The + expiration might be the result of password aging or an account + expiration. This field will usually be left out of the TGS reply since + the response to the TGS request is encrypted in a session key and no + client information need be retrieved from the KDC database. It is up + to the application client (usually the login program) to take + appropriate action (such as notifying the user) if the expiration time + is imminent. +flags, authtime, starttime, endtime, renew-till and caddr + These fields are duplicates of those found in the encrypted portion of + the attached ticket (see section 5.3.1), provided so the client may + verify they match the intended request and to assist in proper ticket + caching. If the message is of type KRB_TGS_REP, the caddr field will + only be filled in if the request was for a proxy or forwarded ticket, + or if the user is substituting a subset of the addresses from the + ticket granting ticket. If the client-requested addresses are not + present or not used, then the addresses contained in the ticket will + be the same as those included in the ticket-granting ticket. + +5.5. Client/Server (CS) message specifications + +This section specifies the format of the messages used for the +authentication of the client to the application server. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.5.1. KRB_AP_REQ definition + +The KRB_AP_REQ message contains the Kerberos protocol version number, the +message type KRB_AP_REQ, an options field to indicate any options in use, +and the ticket and authenticator themselves. The KRB_AP_REQ message is +often referred to as the 'authentication header'. + +AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ap-options[2] APOptions, + ticket[3] Ticket, + authenticator[4] EncryptedData +} + +APOptions ::= BIT STRING { + reserved(0), + use-session-key(1), + mutual-required(2) +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REQ. +ap-options + This field appears in the application request (KRB_AP_REQ) and affects + the way the request is processed. It is a bit-field, where the + selected options are indicated by the bit being set (1), and the + unselected options and reserved fields being reset (0). The encoding + of the bits is specified in section 5.2. The meanings of the options + are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 USE-SESSION-KEY + The USE-SESSION-KEY option indicates + that the ticket the client is presenting + to a server is encrypted in the session + key from the server's ticket-granting + ticket. When this option is not speci- + fied, the ticket is encrypted in the + server's secret key. + + 2 MUTUAL-REQUIRED + The MUTUAL-REQUIRED option tells the + server that the client requires mutual + authentication, and that it must respond + with a KRB_AP_REP message. + + 3-31 RESERVED + Reserved for future use. + +ticket + This field is a ticket authenticating the client to the server. +authenticator + This contains the authenticator, which includes the client's choice of + a subkey. Its encoding is described in section 5.3.2. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.5.2. KRB_AP_REP definition + +The KRB_AP_REP message contains the Kerberos protocol version number, the +message type, and an encrypted time- stamp. The message is sent in in +response to an application request (KRB_AP_REQ) where the mutual +authentication option has been selected in the ap-options field. + +AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[2] EncryptedData +} + +EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { + ctime[0] KerberosTime, + cusec[1] INTEGER, + subkey[2] EncryptionKey OPTIONAL, + seq-number[3] INTEGER OPTIONAL +} + +The encoded EncAPRepPart is encrypted in the shared session key of the +ticket. The optional subkey field can be used in an application-arranged +negotiation to choose a per association session key. + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REP. +enc-part + This field is described above in section 5.4.2. +ctime + This field contains the current time on the client's host. +cusec + This field contains the microsecond part of the client's timestamp. +subkey + This field contains an encryption key which is to be used to protect + this specific application session. See section 3.2.6 for specifics on + how this field is used to negotiate a key. Unless an application + specifies otherwise, if this field is left out, the sub-session key + from the authenticator, or if also left out, the session key from the + ticket will be used. + +5.5.3. Error message reply + +If an error occurs while processing the application request, the KRB_ERROR +message will be sent in response. See section 5.9.1 for the format of the +error message. The cname and crealm fields may be left out if the server +cannot determine their appropriate values from the corresponding KRB_AP_REQ +message. If the authenticator was decipherable, the ctime and cusec fields +will contain the values from it. + +5.6. KRB_SAFE message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to send a tamper-proof message to +its peer. It presumes that a session key has previously been exchanged (for +example, by using the KRB_AP_REQ/KRB_AP_REP messages). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.6.1. KRB_SAFE definition + +The KRB_SAFE message contains user data along with a collision-proof +checksum keyed with the last encryption key negotiated via subkeys, or the +session key if no negotiation has occured. The message fields are: + +KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + safe-body[2] KRB-SAFE-BODY, + cksum[3] Checksum +} + +KRB-SAFE-BODY ::= SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_SAFE. +safe-body + This field is a placeholder for the body of the KRB-SAFE message. +cksum + This field contains the checksum of the application data. Checksum + details are described in section 6.4. The checksum is computed over + the encoding of the KRB-SAFE sequence. First, the cksum is zeroed and + the checksum is computed over the encoding of the KRB-SAFE sequence, + then the checksum is set to the result of that computation, and + finally the KRB-SAFE sequence is encoded again. +user-data + This field is part of the KRB_SAFE and KRB_PRIV messages and contain + the application specific data that is being passed from the sender to + the recipient. +timestamp + This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents + are the current time as known by the sender of the message. By + checking the timestamp, the recipient of the message is able to make + sure that it was recently generated, and is not a replay. +usec + This field is part of the KRB_SAFE and KRB_PRIV headers. It contains + the microsecond part of the timestamp. +seq-number + This field is described above in section 5.3.2. +s-address + This field specifies the address in use by the sender of the message. + It may be omitted if not required by the application protocol. The + application designer considering omission of this field is warned, + that the inclusion of this address prevents some kinds of replay + attacks (e.g., reflection attacks) and that it is only acceptable to + omit this address if there is sufficient information in the integrity + protected part of the application message for the recipient to + unambiguously determine if it was the intended recipient. +r-address + This field specifies the address in use by the recipient of the + message. It may be omitted for some uses (such as broadcast + protocols), but the recipient may arbitrarily reject such messages. + This field along with s-address can be used to help detect messages + which have been incorrectly or maliciously delivered to the wrong + recipient. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.7. KRB_PRIV message specification + +This section specifies the format of a message that can be used by either +side (client or server) of an application to securely and privately send a +message to its peer. It presumes that a session key has previously been +exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV definition + +The KRB_PRIV message contains user data encrypted in the Session Key. The +message fields are: + +KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[3] EncryptedData +} + +EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, -- sender's +addr + r-address[5] HostAddress OPTIONAL -- recip's +addr +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_PRIV. +enc-part + This field holds an encoding of the EncKrbPrivPart sequence encrypted + under the session key[32]. This encrypted encoding is used for the + enc-part field of the KRB-PRIV message. See section 6 for the format + of the ciphertext. +user-data, timestamp, usec, s-address and r-address + These fields are described above in section 5.6.1. +seq-number + This field is described above in section 5.3.2. + +5.8. KRB_CRED message specification + +This section specifies the format of a message that can be used to send +Kerberos credentials from one principal to another. It is presented here to +encourage a common mechanism to be used by applications when forwarding +tickets or providing proxies to subordinate servers. It presumes that a +session key has already been exchanged perhaps by using the +KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED definition + +The KRB_CRED message contains a sequence of tickets to be sent and +information needed to use the tickets, including the session key from each. +The information needed to use the tickets is encrypted under an encryption +key previously exchanged or transferred alongside the KRB_CRED message. The +message fields are: + +KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, -- KRB_CRED + tickets[2] SEQUENCE OF Ticket, + enc-part[3] EncryptedData +} + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info[0] SEQUENCE OF KrbCredInfo, + nonce[1] INTEGER OPTIONAL, + timestamp[2] KerberosTime OPTIONAL, + usec[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +KrbCredInfo ::= SEQUENCE { + key[0] EncryptionKey, + prealm[1] Realm OPTIONAL, + pname[2] PrincipalName OPTIONAL, + flags[3] TicketFlags OPTIONAL, + authtime[4] KerberosTime OPTIONAL, + starttime[5] KerberosTime OPTIONAL, + endtime[6] KerberosTime OPTIONAL + renew-till[7] KerberosTime OPTIONAL, + srealm[8] Realm OPTIONAL, + sname[9] PrincipalName OPTIONAL, + caddr[10] HostAddresses OPTIONAL +} + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_CRED. +tickets + These are the tickets obtained from the KDC specifically for use by + the intended recipient. Successive tickets are paired with the + corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED + message. +enc-part + This field holds an encoding of the EncKrbCredPart sequence encrypted + under the session key shared between the sender and the intended + recipient. This encrypted encoding is used for the enc-part field of + the KRB-CRED message. See section 6 for the format of the ciphertext. +nonce + If practical, an application may require the inclusion of a nonce + generated by the recipient of the message. If the same value is + included as the nonce in the message, it provides evidence that the + message is fresh and has not been replayed by an attacker. A nonce + must never be re-used; it should be generated randomly by the + recipient of the message and provided to the sender of the message in + an application specific manner. +timestamp and usec + These fields specify the time that the KRB-CRED message was generated. + The time is used to provide assurance that the message is fresh. +s-address and r-address + These fields are described above in section 5.6.1. They are used + optionally to provide additional assurance of the integrity of the + KRB-CRED message. +key + This field exists in the corresponding ticket passed by the KRB-CRED + message and is used to pass the session key from the sender to the + intended recipient. The field's encoding is described in section 6.2. + +The following fields are optional. If present, they can be associated with +the credentials in the remote ticket file. If left out, then it is assumed +that the recipient of the credentials already knows their value. + +prealm and pname + The name and realm of the delegated principal identity. +flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr + These fields contain the values of the correspond- ing fields from the + ticket found in the ticket field. Descriptions of the fields are + identical to the descriptions in the KDC-REP message. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +5.9. Error message specification + +This section specifies the format for the KRB_ERROR message. The fields +included in the message are intended to return as much information as +possible about an error. It is not expected that all the information +required by the fields will be available for all types of errors. If the +appropriate information is not available when the message is composed, the +corresponding field will be left out of the message. + +Note that since the KRB_ERROR message is only optionally integrity +protected, it is quite possible for an intruder to synthesize or modify +such a message. In particular, this means that unless appropriate integrity +protection mechanisms have been applied to the KRB_ERROR message, the +client should not use any fields in this message for security-critical +purposes, such as setting a system clock or generating a fresh +authenticator. The message can be useful, however, for advising a user on +the reason for some failure. + +5.9.1. KRB_ERROR definition + +The KRB_ERROR message consists of the following fields: + +KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ctime[2] KerberosTime OPTIONAL, + cusec[3] INTEGER OPTIONAL, + stime[4] KerberosTime, + susec[5] INTEGER, + error-code[6] INTEGER, + crealm[7] Realm OPTIONAL, + cname[8] PrincipalName OPTIONAL, + realm[9] Realm, -- Correct realm + sname[10] PrincipalName, -- Correct name + e-text[11] GeneralString OPTIONAL, + e-data[12] OCTET STRING OPTIONAL, + e-cksum[13] Checksum OPTIONAL, +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_ERROR. +ctime + This field is described above in section 5.4.1. +cusec + This field is described above in section 5.5.2. +stime + This field contains the current time on the server. It is of type + KerberosTime. +susec + This field contains the microsecond part of the server's timestamp. + Its value ranges from 0 to 999999. It appears along with stime. The + two fields are used in conjunction to specify a reasonably accurate + timestamp. +error-code + This field contains the error code returned by Kerberos or the server + when a request fails. To interpret the value of this field see the + list of error codes in section 8. Implementations are encouraged to + provide for national language support in the display of error + messages. +crealm, cname, srealm and sname + These fields are described above in section 5.3.1. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + +e-text + This field contains additional text to help explain the error code + associated with the failed request (for example, it might include a + principal name which was unknown). +e-data + This field contains additional data about the error for use by the + application to help it recover from or handle the error. If present, + this field will contain the encoding of a sequence of TypedData + (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, + in which case it will contain the encoding of a sequence of of padata + fields (METHOD-DATA below), each corresponding to an acceptable + pre-authentication method and optionally containing data for the + method: + + TYPED-DATA ::= SEQUENCE of TypeData + METHOD-DATA ::= SEQUENCE of PA-DATA + + TypedData ::= SEQUENCE { + data-type[0] INTEGER, + data-value[1] OCTET STRING OPTIONAL + } + + Note that e-data-types have been reserved for all PA data types + defined prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, + when using new PA data types defined in July 1999 or later, the + METHOD-DATA sequence must itself be encapsulated in an TypedData + element of type TD-PADATA. All new implementations interpreting the + METHOD-DATA field for the KDC_ERR_PREAUTH_REQUIRED message must accept + a type of TD-PADATA, extract the typed data field and interpret the + use any elements encapsulated in the TD-PADATA elements as if they + were present in the METHOD-DATA sequence. +e-cksum + This field contains an optional checksum for the KRB-ERROR message. + The checksum is calculated over the Kerberos ASN.1 encoding of the + KRB-ERROR message with the checksum absent. The checksum is then added + to the KRB-ERROR structure and the message is re-encoded. The Checksum + should be calculated using the session key from the ticket granting + ticket or service ticket, where available. If the error is in response + to a TGS or AP request, the checksum should be calculated uing the the + session key from the client's ticket. If the error is in response to + an AS request, then the checksum should be calulated using the + client's secret key ONLY if there has been suitable preauthentication + to prove knowledge of the secret key by the client[33]. If a checksum + can not be computed because the key to be used is not available, no + checksum will be included. + + 6. Encryption and Checksum Specifications + + The Kerberos protocols described in this document are designed to use + stream encryption ciphers, which can be simulated using commonly + available block encryption ciphers, such as the Data Encryption + Standard [DES77], and triple DES variants, in conjunction with block + chaining and checksum methods [DESM80]. Encryption is used to prove + the identities of the network entities participating in message + exchanges. The Key Distribution Center for each realm is trusted by + all principals registered in that realm to store a secret key in + confidence. Proof of knowledge of this secret key is used to verify + the authenticity of a principal. + + The KDC uses the principal's secret key (in the AS exchange) or a + shared session key (in the TGS exchange) to encrypt responses to + ticket requests; the ability to obtain the secret key or session key + implies the knowledge of the appropriate keys and the identity of the + KDC. The ability of a principal to decrypt the KDC response and + present a Ticket and a properly formed Authenticator (generated with + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + the session key from the KDC response) to a service verifies the + identity of the principal; likewise the ability of the service to + extract the session key from the Ticket and prove its knowledge + thereof in a response verifies the identity of the service. + + The Kerberos protocols generally assume that the encryption used is + secure from cryptanalysis; however, in some cases, the order of fields + in the encrypted portions of messages are arranged to minimize the + effects of poorly chosen keys. It is still important to choose good + keys. If keys are derived from user-typed passwords, those passwords + need to be well chosen to make brute force attacks more difficult. + Poorly chosen keys still make easy targets for intruders. + + The following sections specify the encryption and checksum mechanisms + currently defined for Kerberos. The encodings, chaining, and padding + requirements for each are described. For encryption methods, it is + often desirable to place random information (often referred to as a + confounder) at the start of the message. The requirements for a + confounder are specified with each encryption mechanism. + + Some encryption systems use a block-chaining method to improve the the + security characteristics of the ciphertext. However, these chaining + methods often don't provide an integrity check upon decryption. Such + systems (such as DES in CBC mode) must be augmented with a checksum of + the plain-text which can be verified at decryption and used to detect + any tampering or damage. Such checksums should be good at detecting + burst errors in the input. If any damage is detected, the decryption + routine is expected to return an error indicating the failure of an + integrity check. Each encryption type is expected to provide and + verify an appropriate checksum. The specification of each encryption + method sets out its checksum requirements. + + Finally, where a key is to be derived from a user's password, an + algorithm for converting the password to a key of the appropriate type + is included. It is desirable for the string to key function to be + one-way, and for the mapping to be different in different realms. This + is important because users who are registered in more than one realm + will often use the same password in each, and it is desirable that an + attacker compromising the Kerberos server in one realm not obtain or + derive the user's key in another. + + For an discussion of the integrity characteristics of the candidate + encryption and checksum methods considered for Kerberos, the reader is + referred to [SG92]. + + 6.1. Encryption Specifications + + The following ASN.1 definition describes all encrypted messages. The + enc-part field which appears in the unencrypted part of messages in + section 5 is a sequence consisting of an encryption type, an optional + key version number, and the ciphertext. + + EncryptedData ::= SEQUENCE { + etype[0] INTEGER, -- EncryptionType + kvno[1] INTEGER OPTIONAL, + cipher[2] OCTET STRING -- ciphertext + } + + + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. Detailed specifications for selected + encryption types appear later in this section. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + kvno + This field contains the version number of the key under which + data is encrypted. It is only present in messages encrypted under + long lasting keys, such as principals' secret keys. + cipher + This field contains the enciphered text, encoded as an OCTET + STRING. + The cipher field is generated by applying the specified encryption + algorithm to data composed of the message and algorithm-specific + inputs. Encryption mechanisms defined for use with Kerberos must take + sufficient measures to guarantee the integrity of the plaintext, and + we recommend they also take measures to protect against precomputed + dictionary attacks. If the encryption algorithm is not itself capable + of doing so, the protections can often be enhanced by adding a + checksum and a confounder. + + The suggested format for the data to be encrypted includes a + confounder, a checksum, the encoded plaintext, and any necessary + padding. The msg-seq field contains the part of the protocol message + described in section 5 which is to be encrypted. The confounder, + checksum, and padding are all untagged and untyped, and their length + is exactly sufficient to hold the appropriate item. The type and + length is implicit and specified by the particular encryption type + being used (etype). The format for the data to be encrypted for some + methods is described in the following diagram, but other methods may + deviate from this layour - so long as the definition of the method + defines the layout actually in use. + + +-----------+----------+-------------+-----+ + |confounder | check | msg-seq | pad | + +-----------+----------+-------------+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + CipherText ::= ENCRYPTED SEQUENCE { + confounder[0] UNTAGGED[35] OCTET STRING(conf_length) +OPTIONAL, + check[1] UNTAGGED OCTET STRING(checksum_length) +OPTIONAL, + msg-seq[2] MsgSequence, + pad UNTAGGED OCTET STRING(pad_length) OPTIONAL + } + + One generates a random confounder of the appropriate length, placing + it in confounder; zeroes out check; calculates the appropriate + checksum over confounder, check, and msg-seq, placing the result in + check; adds the necessary padding; then encrypts using the specified + encryption type and the appropriate key. + + Unless otherwise specified, a definition of an encryption algorithm + that specifies a checksum, a length for the confounder field, or an + octet boundary for padding uses this ciphertext format[36]. Those + fields which are not specified will be omitted. + + In the interest of allowing all implementations using a particular + encryption type to communicate with all others using that type, the + specification of an encryption type defines any checksum that is + needed as part of the encryption process. If an alternative checksum + is to be used, a new encryption type must be defined. + + Some cryptosystems require additional information beyond the key and + the data to be encrypted. For example, DES, when used in + cipher-block-chaining mode, requires an initialization vector. If + required, the description for each encryption type must specify the + source of such additional information. 6.2. Encryption Keys + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The sequence below shows the encoding of an encryption key: + + EncryptionKey ::= SEQUENCE { + keytype[0] INTEGER, + keyvalue[1] OCTET STRING + } + + keytype + This field specifies the type of encryption that is to be + performed using the key that follows in the keyvalue field. It + will always correspond to the etype to be used to generate or + decode the EncryptedData. In cases when multiple algorithms use a + common kind of key (e.g., if the encryption algorithm uses an + alternate checksum algorithm for an integrity check, or a + different chaining mechanism), the keytype provides information + needed to determine which algorithm is to be used. + keyvalue + This field contains the key itself, encoded as an octet string. + All negative values for the encryption key type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpreta- tions. + + 6.3. Encryption Systems + + 6.3.1. The NULL Encryption System (null) + + If no encryption is in use, the encryption system is said to be the + NULL encryption system. In the NULL encryption system there is no + checksum, confounder or padding. The ciphertext is simply the + plaintext. The NULL Key is used by the null encryption system and is + zero octets in length, with keytype zero (0). + + 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) + + The des-cbc-crc encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is + applied to the confounder and message sequence (msg-seq) and placed in + the cksum field. DES blocks are 8 bytes. As a result, the data to be + encrypted (the concatenation of confounder, checksum, and message) + must be padded to an 8 byte boundary before encryption. The details of + the encryption of this data are identical to those for the des-cbc-md5 + encryption mode. + + Note that, since the CRC-32 checksum is not collision-proof, an + attacker could use a probabilistic chosen-plaintext attack to generate + a valid message even if a confounder is used [SG92]. The use of + collision-proof checksums is recommended for environments where such + attacks represent a significant threat. The use of the CRC-32 as the + checksum for ticket or authenticator is no longer mandated as an + interoperability requirement for Kerberos Version 5 Specification 1 + (See section 9.1 for specific details). + + 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) + + The des-cbc-md4 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD4 checksum (described in [MD492]) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be + padded to an 8 byte boundary before encryption. The details of the + encryption of this data are identical to those for the des-cbc-md5 + encryption mode. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) + + The des-cbc-md5 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be + padded to an 8 byte boundary before encryption. + + Plaintext and DES ciphtertext are encoded as blocks of 8 octets which + are concatenated to make the 64-bit inputs for the DES algorithms. The + first octet supplies the 8 most significant bits (with the octet's + MSbit used as the DES input block's MSbit, etc.), the second octet the + next 8 bits, ..., and the eighth octet supplies the 8 least + significant bits. + + Encryption under DES using cipher block chaining requires an + additional input in the form of an initialization vector. Unless + otherwise specified, zero should be used as the initialization vector. + Kerberos' use of DES requires an 8 octet confounder. + + The DES specifications identify some 'weak' and 'semi-weak' keys; + those keys shall not be used for encrypting messages for use in + Kerberos. Additionally, because of the way that keys are derived for + the encryption of checksums, keys shall not be used that yield 'weak' + or 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant + F0F0F0F0F0F0F0F0. + + A DES key is 8 octets of data, with keytype one (1). This consists of + 56 bits of key, and 8 parity bits (one per octet). The key is encoded + as a series of 8 octets written in MSB-first order. The bits within + the key are also encoded in MSB order. For example, if the encryption + key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) + where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 + are the parity bits, the first octet of the key would be + B1,B2,...,B7,P1 (with B1 as the MSbit). [See the FIPS 81 introduction + for reference.] + + String to key transformation + + To generate a DES key from a text string (password), a "salt" is + concatenated to the text string, and then padded with ASCII nulls to + an 8 byte boundary. This "salt" is normally the realm and each + component of the principal's name appended. However, sometimes + different salts are used --- for example, when a realm is renamed, or + if a user changes her username, or for compatibility with Kerberos V4 + (whose string-to-key algorithm uses a null string for the salt). This + string is then fan-folded and eXclusive-ORed with itself to form an 8 + byte DES key. Before eXclusive-ORing a block, every byte is shifted + one bit to the left to leave the lowest bit zero. The key is the + "corrected" by correcting the parity on the key, and if the key + matches a 'weak' or 'semi-weak' key as described in the DES + specification, it is eXclusive-ORed with the constant + 00000000000000F0. This key is then used to generate a DES CBC checksum + on the initial string (with the salt appended). The result of the CBC + checksum is the "corrected" as described above to form the result + which is return as the key. Pseudocode follows: + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + name_to_default_salt(realm, name) { + s = realm + for(each component in name) { + s = s + component; + } + return s; + } + + key_correction(key) { + fixparity(key); + if (is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + + string_to_key(string,salt) { + + odd = 1; + s = string + salt; + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + left shift every byte in 8byteblock one bit; + tempkey = tempkey XOR 8byteblock; + } + tempkey = key_correction(tempkey); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + + 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and + without Key Derivation [Original draft by Marc Horowitz, revisions by + David Miller] + + There are still a few pieces of this specification to be included + by falue, rather than by reference. This will be done before the + Pittsburgh IETF. + This encryption type is based on the Triple DES cryptosystem, the + HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key + derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may + not be used in conjunction with the use of Triple DES keys. + + Algorithm Identifiers + + The des3-cbc-hmac-sha1 encryption type has been assigned the value 7. + The des3-cbc-hmac-sha1-kd encryption type, specifying the key + derivation variant of the encryption type, has been assigned the value + 16. The hmac-sha1-des3 checksum type has been assigned the value 13. + The hmac-sha1-des3-kd checksum type, specifying the key derivation + variant of the checksum, has been assigned the value 12. + + Triple DES Key Production + + The EncryptionKey value is 24 octets long. The 7 most significant bits + of each octet contain key bits, and the least significant bit is the + inverse of the xor of the key bits. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + For the purposes of key derivation, the block size is 64 bits, and the + key size is 168 bits. The 168 bits output by key derivation are + converted to an EncryptionKey value as follows. First, the 168 bits + are divided into three groups of 56 bits, which are expanded + individually into 64 bits as follows: + + 1 2 3 4 5 6 7 p + 9 10 11 12 13 14 15 p + 17 18 19 20 21 22 23 p + 25 26 27 28 29 30 31 p + 33 34 35 36 37 38 39 p + 41 42 43 44 45 46 47 p + 49 50 51 52 53 54 55 p + 56 48 40 32 24 16 8 p + + The "p" bits are parity bits computed over the data bits. The output + of the three expansions are concatenated to form the EncryptionKey + value. + + When the HMAC-SHA1 of a string is computed, the key is used in the + EncryptedKey form. + + The string-to-key function is used to tranform UNICODE passwords into + DES3 keys. The DES3 string-to-key function relies on the "N-fold" + algorithm, which is detailed in [9]. The description of the N-fold + algorithm in that document is as follows: + o To n-fold a number X, replicate the input value to a length that + is the least common multiple of n and the length of X. Before + each repetition, the input is rotated to the right by 13 bit + positions. The successive n-bit chunks are added together using + 1's-complement addition (that is, addition with end-around carry) + to yield an n-bit result" + o The n-fold algorithm, as with DES string-to-key, is applied to + the password string concatenated with a salt value. The salt + value is derived in the same was as for the DES string-to-key + algorithm. For 3-key triple DES then, the operation will involve + a 168-fold of the input password string. The remainder of the + string-to-key function for DES3 is shown here in pseudocode: + + DES3string-to-key(passwordString, key) + + salt = name_to_default_salt(realm, name) + s = passwordString + salt + tmpKey1 = 168-fold(s) + parityFix(tmpKey1); + if not weakKey(tmpKey1) + /* + * Encrypt temp key in itself with a + * zero initialization vector + * + * Function signature is DES3encrypt(plain, key, iv) + * with cipher as the return value + */ + tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec) + /* + * Encrypt resultant temp key in itself with third component + * of first temp key as initialization vector + */ + key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2]) + parityFix(key) + if not weakKey(key) + return SUCCESS + else + return FAILURE + else + return FAILURE + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The weakKey function above is the same weakKey function used with DES + keys, but applied to each of the three single DES keys that comprise + the triple DES key. + + The lengths of UNICODE encoded character strings include the trailing + terminator character (0). + + Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd + + EncryptedData using this type must be generated as described in + [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC + mode. The checksum algorithm is HMAC-SHA1. If the key derivation + variant of the encryption type is used, encryption key values are + modified according to the method under the Key Derivation section + below. + + Unless otherwise specified, a zero IV must be used. + + If the length of the input data is not a multiple of the block size, + zero octets must be used to pad the plaintext to the next eight-octet + boundary. The counfounder must be eight random octets (one block). + + Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd + + Checksums using this type must be generated as described in + [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key + derivation variant of the checksum type is used, checksum key values + are modified according to the method under the Key Derivation section + below. + + Key Derivation + + In the Kerberos protocol, cryptographic keys are used in a number of + places. In order to minimize the effect of compromising a key, it is + desirable to use a different key for each of these places. Key + derivation [Horowitz96] can be used to construct different keys for + each operation from the keys transported on the network. For this to + be possible, a small change to the specification is necessary. + + This section specifies a profile for the use of key derivation + [Horowitz96] with Kerberos. For each place where a key is used, a + ``key usage'' must is specified for that purpose. The key, key usage, + and encryption/checksum type together describe the transformation from + plaintext to ciphertext, or plaintext to checksum. + + Key Usage Values + + This is a complete list of places keys are used in the kerberos + protocol, with key usage values and RFC 1510 section numbers: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the + client key (section 5.4.1) + 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or + application session key), encrypted with the service key + (section 5.4.2) + 3. AS-REP encrypted part (includes tgs session key or application + session key), encrypted with the client key (section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + session key (section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + authenticator subkey (section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed + with the tgs session key (sections 5.3.2, 5.4.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs + authenticator subkey), encrypted with the tgs session key + (section 5.3.2) + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 8. TGS-REP encrypted part (includes application session key), + encrypted with the tgs session key (section 5.4.2) + 9. TGS-REP encrypted part (includes application session key), + encrypted with the tgs authenticator subkey (section 5.4.2) + 10. AP-REQ Authenticator cksum, keyed with the application session + key (section 5.3.2) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (section + 5.3.2) + 12. AP-REP encrypted part (includes application session subkey), + encrypted with the application session key (section 5.5.2) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by the + application (section 5.7.1) + 14. KRB-CRED encrypted part, encrypted with a key chosen by the + application (section 5.6.1) + 15. KRB-SAVE cksum, keyed with a key chosen by the application + (section 5.8.1) + 18. KRB-ERROR checksum (e-cksum in section 5.9.1) + 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) + 20. Checksum for Mandatory Ticket Extensions (appendix B.6) + 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) + + Key usage values between 1024 and 2047 (inclusive) are reserved for + application use. Applications should use even values for encryption + and odd values for checksums within this range. + + A few of these key usages need a little clarification. A service which + receives an AP-REQ has no way to know if the enclosed Ticket was part + of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used + for generating a Ticket, whether it is in response to an AS- REQ or + TGS-REQ. + + There might exist other documents which define protocols in terms of + the RFC1510 encryption types or checksum types. Such documents would + not know about key usages. In order that these documents continue to + be meaningful until they are updated, key usages 1024 and 1025 must be + used to derive keys for encryption and checksums, respectively. New + protocols defined in terms of the Kerberos encryption and checksum + types should use their own key usages. Key usages may be registered + with IANA to avoid conflicts. Key usages must be unsigned 32 bit + integers. Zero is not permitted. + + Defining Cryptosystems Using Key Derivation + + Kerberos requires that the ciphertext component of EncryptedData be + tamper-resistant as well as confidential. This implies encryption and + integrity functions, which must each use their own separate keys. So, + for each key usage, two keys must be generated, one for encryption + (Ke), and one for integrity (Ki): + + Ke = DK(protocol key, key usage | 0xAA) + Ki = DK(protocol key, key usage | 0x55) + + where the protocol key is from the EncryptionKey from the wire + protocol, and the key usage is represented as a 32 bit integer in + network byte order. The ciphertest must be generated from the + plaintext as follows: + + ciphertext = E(Ke, confounder | plaintext | padding) | + H(Ki, confounder | plaintext | padding) + + The confounder and padding are specific to the encryption algorithm E. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + When generating a checksum only, there is no need for a confounder or + padding. Again, a new key (Kc) must be used. Checksums must be + generated from the plaintext as follows: + + Kc = DK(protocol key, key usage | 0x99) + MAC = H(Kc, plaintext) + + Note that each enctype is described by an encryption algorithm E and a + keyed hash algorithm H, and each checksum type is described by a keyed + hash algorithm H. HMAC, with an appropriate hash, is required for use + as H. + + Key Derivation from Passwords + + The well-known constant for password key derivation must be the byte + string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values + correspond to the ASCII encoding for the string "kerberos". + + 6.4. Checksums + + The following is the ASN.1 definition used for a checksum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + checksum[1] OCTET STRING + } + + cksumtype + This field indicates the algorithm used to generate the + accompanying checksum. + checksum + This field contains the checksum itself, encoded as an octet + string. + Detailed specification of selected checksum types appear later in this + section. Negative values for the checksum type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + Checksums used by Kerberos can be classified by two properties: + whether they are collision-proof, and whether they are keyed. It is + infeasible to find two plaintexts which generate the same checksum + value for a collision-proof checksum. A key is required to perturb or + initialize the algorithm in a keyed checksum. To prevent + message-stream modification by an active attacker, unkeyed checksums + should only be used when the checksum and message will be subsequently + encrypted (e.g. the checksums defined as part of the encryption + algorithms covered earlier in this section). + + Collision-proof checksums can be made tamper-proof if the checksum + value is encrypted before inclusion in a message. In such cases, the + composition of the checksum and the encryption algorithm must be + considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using + DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed + checksums, as well as for the encrypted forms of unkeyed + collision-proof checksums, Kerberos prepends a confounder before the + checksum is calculated. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 6.4.1. The CRC-32 Checksum (crc32) + + The CRC-32 checksum calculates a checksum based on a cyclic redundancy + check as described in ISO 3309 [ISO3309]. The resulting checksum is + four (4) octets in length. The CRC-32 is neither keyed nor + collision-proof. The use of this checksum is not recommended. An + attacker using a probabilistic chosen-plaintext attack as described in + [SG92] might be able to generate an alternative message that satisfies + the checksum. The use of collision-proof checksums is recommended for + environments where such attacks represent a significant threat. + + 6.4.2. The RSA MD4 Checksum (rsa-md4) + + The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm + [MD4-92]. The algorithm takes as input an input message of arbitrary + length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 + is believed to be collision-proof. + + 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) + + The RSA-MD4-DES checksum calculates a keyed collision-proof checksum + by prepending an 8 octet confounder before the text, applying the RSA + MD4 checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be + zero. The resulting checksum is 24 octets long (8 octets of which are + redundant). This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some weak keys' and 'semi-weak keys'; + those keys shall not be used for generating RSA-MD4 checksums for use + in Kerberos. + + The format for the checksum is described in the follow- ing diagram: + + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) +| + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.4. The RSA MD5 Checksum (rsa-md5) + + The RSA-MD5 checksum calculates a checksum using the RSA MD5 + algorithm. [MD5-92]. The algorithm takes as input an input message of + arbitrary length and produces as output a 128-bit (16 octet) checksum. + RSA-MD5 is believed to be collision-proof. + + 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) + + The RSA-MD5-DES checksum calculates a keyed collision-proof checksum + by prepending an 8 octet confounder before the text, applying the RSA + MD5 checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector + should be zero. The resulting checksum is 24 octets long (8 octets of + which are redundant). This checksum is tamper-proof and believed to be + collision-proof. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + The DES specifications identify some 'weak keys' and 'semi-weak keys'; + those keys shall not be used for encrypting RSA-MD5 checksums for use + in Kerberos. + + The format for the checksum is described in the following diagram: + + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) +| + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.6. DES cipher-block chained checksum (des-mac) + + The DES-MAC checksum is computed by prepending an 8 octet confounder + to the plaintext, performing a DES CBC-mode encryption on the result + using the key and an initialization vector of zero, taking the last + block of the ciphertext, prepending the same confounder and encrypting + the pair using DES in cipher-block-chaining (CBC) mode using a a + variant of the key, where the variant is computed by eXclusive-ORing + the key with the hexadecimal constant F0F0F0F0F0F0F0F0. The + initialization vector should be zero. The resulting checksum is 128 + bits (16 octets) long, 64 bits of which are redundant. This checksum + is tamper-proof and collision-proof. + + The format for the checksum is described in the following diagram: + + ++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) +| + ++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(8) + } + + The DES specifications identify some 'weak' and 'semi-weak' keys; + those keys shall not be used for generating DES-MAC checksums for use + in Kerberos, nor shall a key be used whose variant is 'weak' or + 'semi-weak'. + + 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative + (rsa-md4-des-k) + + The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum + by applying the RSA MD4 checksum algorithm and encrypting the results + using DES in cipher-block-chaining (CBC) mode using a DES key as both + key and initialization vector. The resulting checksum is 16 octets + long. This checksum is tamper-proof and believed to be + collision-proof. Note that this checksum type is the old method for + encoding the RSA-MD4-DES checksum and it is no longer recommended. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, and using the last block of the + ciphertext as the checksum value. It is keyed with an encryption key + and an initialization vector; any uses which do not specify an + additional initialization vector will use the key as both key and + initialization vector. The resulting checksum is 64 bits (8 octets) + long. This checksum is tamper-proof and collision-proof. Note that + this checksum type is the old method for encoding the DES-MAC checksum + and it is no longer recommended. The DES specifications identify some + 'weak keys' and 'semi-weak keys'; those keys shall not be used for + generating DES-MAC checksums for use in Kerberos. + + 7. Naming Constraints + + 7.1. Realm Names + + Although realm names are encoded as GeneralStrings and although a + realm can technically select any name it chooses, interoperability + across realm boundaries requires agreement on how realm names are to + be assigned, and what information they imply. + + To enforce these conventions, each realm must conform to the + conventions itself, and it must require that any realms with which + inter-realm keys are shared also conform to the conventions and + require the same from its neighbors. + + Kerberos realm names are case sensitive. Realm names that differ only + in the case of the characters are not equivalent. There are presently + four styles of realm names: domain, X500, other, and reserved. + Examples of each style follow: + + domain: ATHENA.MIT.EDU (example) + X500: C=US/O=OSF (example) + other: NAMETYPE:rest/of.name=without-restrictions (example) + reserved: reserved, but will not conflict with above + + Domain names must look like domain names: they consist of components + separated by periods (.) and they contain neither colons (:) nor + slashes (/). Though domain names themselves are case insensitive, in + order for realms to match, the case must match as well. When + establishing a new realm name based on an internet domain name it is + recommended by convention that the characters be converted to upper + case. + + X.500 names contain an equal (=) and cannot contain a colon (:) before + the equal. The realm names for X.500 names will be string + representations of the names with components separated by slashes. + Leading and trailing slashes will not be included. + + Names that fall into the other category must begin with a prefix that + contains no equal (=) or period (.) and the prefix must be followed by + a colon (:) and the rest of the name. All prefixes must be assigned + before they may be used. Presently none are assigned. + + The reserved category includes strings which do not fall into the + first three categories. All names in this category are reserved. It is + unlikely that names will be assigned to this category unless there is + a very strong argument for not using the 'other' category. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + These rules guarantee that there will be no conflicts between the + various name styles. The following additional constraints apply to the + assignment of realm names in the domain and X.500 categories: the name + of a realm for the domain or X.500 formats must either be used by the + organization owning (to whom it was assigned) an Internet domain name + or X.500 name, or in the case that no such names are registered, + authority to use a realm name may be derived from the authority of the + parent realm. For example, if there is no domain name for E40.MIT.EDU, + then the administrator of the MIT.EDU realm can authorize the creation + of a realm with that name. + + This is acceptable because the organization to which the parent is + assigned is presumably the organization authorized to assign names to + its children in the X.500 and domain name systems as well. If the + parent assigns a realm name without also registering it in the domain + name or X.500 hierarchy, it is the parent's responsibility to make + sure that there will not in the future exists a name identical to the + realm name of the child unless it is assigned to the same entity as + the realm name. + + 7.2. Principal Names + + As was the case for realm names, conventions are needed to ensure that + all agree on what information is implied by a principal name. The + name-type field that is part of the principal name indicates the kind + of information implied by the name. The name-type should be treated as + a hint. Ignoring the name type, no two names can be the same (i.e. at + least one of the components, or the realm, must be different). The + following name types are defined: + + name-type value meaning + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 General principal name (e.g. username, DCE +principal) + NT-SRV-INST 2 Service and other unique instance (krbtgt) + NT-SRV-HST 3 Service with host name as instance (telnet, rcmds) + NT-SRV-XHST 4 Service with slash-separated host name components + NT-UID 5 Unique ID + NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] + NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. +user@foo.com) + + When a name implies no information other than its uniqueness at a + particular time the name type PRINCIPAL should be used. The principal + name type should be used for users, and it might also be used for a + unique server. If the name is a unique machine generated ID that is + guaranteed never to be reassigned then the name type of UID should be + used (note that it is generally a bad idea to reassign names of any + type since stale entries might remain in access control lists). + + If the first component of a name identifies a service and the + remaining components identify an instance of the service in a server + specified manner, then the name type of SRV-INST should be used. An + example of this name type is the Kerberos ticket-granting service + whose name has a first component of krbtgt and a second component + identifying the realm for which the ticket is valid. + + If instance is a single component following the service name and the + instance identifies the host on which the server is running, then the + name type SRV-HST should be used. This type is typically used for + Internet services such as telnet and the Berkeley R commands. If the + separate components of the host name appear as successive components + following the name of the service, then the name type SRV-XHST should + be used. This type might be used to identify servers on hosts with + X.500 names where the slash (/) might otherwise be ambiguous. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + A name type of NT-X500-PRINCIPAL should be used when a name from an + X.509 certificiate is translated into a Kerberos name. The encoding of + the X.509 name as a Kerberos principal shall conform to the encoding + rules specified in RFC 2253. + + A name type of SMTP allows a name to be of a form that resembles a + SMTP email name. This name type can be used in conjunction with + name-canonicalization to allow a free-form of username to be specified + as a client name and allow the KDC to determine the Kerberos principal + name for the requested name. [JBrezak] + + A name type of UNKNOWN should be used when the form of the name is not + known. When comparing names, a name of type UNKNOWN will match + principals authenticated with names of any type. A principal + authenticated with a name of type UNKNOWN, however, will only match + other names of type UNKNOWN. + + Names of any type with an initial component of 'krbtgt' are reserved + for the Kerberos ticket granting service. See section 8.2.3 for the + form of such names. + + 7.2.1. Name of server principals + + The principal identifier for a server on a host will generally be + composed of two parts: (1) the realm of the KDC with which the server + is registered, and (2) a two-component name of type NT-SRV-HST if the + host name is an Internet domain name or a multi-component name of type + NT-SRV-XHST if the name of the host is of a form such as X.500 that + allows slash (/) separators. The first component of the two- or + multi-component name will identify the service and the latter + components will identify the host. Where the name of the host is not + case sensitive (for example, with Internet domain names) the name of + the host must be lower case. If specified by the application protocol + for services such as telnet and the Berkeley R commands which run with + system privileges, the first component may be the string 'host' + instead of a service specific identifier. When a host has an official + name and one or more aliases, the official name of the host must be + used when constructing the name of the server principal. + + 8. Constants and other defined values + + 8.1. Host address types + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + The values of the types for the following addresses are chosen to + match the defined address family constants in the Berkeley Standard + Distributions of Unix. They can be found in with symbolic names AF_xxx + (where xxx is an abbreviation of the address family name). + + Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in + MSB order. The type of IPv4 addresses is two (2). + + Internet (IPv6) Addresses [Westerlund] + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB + order. The type of IPv6 addresses is twenty-four (24). [RFC1883] + [RFC1884]. The following addresses (see [RFC1884]) MUST not appear in + any Kerberos packet: + o the Unspecified Address + o the Loopback Address + o Link-Local addresses + IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. + + CHAOSnet addresses + + CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB + order. The type of CHAOSnet addresses is five (5). + + ISO addresses + + ISO addresses are variable-length. The type of ISO addresses is seven + (7). + + Xerox Network Services (XNS) addresses + + XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. + The type of XNS addresses is six (6). + + AppleTalk Datagram Delivery Protocol (DDP) addresses + + AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit + network number. The first octet of the address is the node number; the + remaining two octets encode the network number in MSB order. The type + of AppleTalk DDP addresses is sixteen (16). + + DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. + The type of DECnet Phase IV addresses is twelve (12). + + Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 to 15 + characters, trailing blank (ascii char 20) filled, with a 16th octet + of 0x0. The type of Netbios addresses is 20 (0x14). + + 8.2. KDC messages + + 8.2.1. UDP/IP transport + + When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request + using UDP IP transport, the client shall send a UDP datagram + containing only an encoding of the request to port 88 (decimal) at the + KDC's IP address; the KDC will respond with a reply datagram + containing only an encoding of the reply message (either a KRB_ERROR + or a KRB_KDC_REP) to the sending port at the sender's IP address. + Kerberos servers supporting IP transport must accept UDP requests on + port 88 (decimal). The response to a request made through UDP/IP + transport must also use UDP/IP transport. + + 8.2.2. TCP/IP transport [Westerlund,Danielsson] + + Kerberos servers (KDC's) should accept TCP requests on port 88 + (decimal) and clients should support the sending of TCP requests on + port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC + over a TCP stream, a new connection will be established for each + authentication exchange (request and response). The KRB_KDC_REP or + KRB_ERROR message will be returned to the client on the same TCP + stream that was established for the request. The response to a request + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + made through TCP/IP transport must also use TCP/IP transport. + Implementors should note that some extentions to the Kerberos protocol + will not work if any implementation not supporting the TCP transport + is involved (client or KDC). Implementors are strongly urged to + support the TCP transport on both the client and server and are + advised that the current notation of "should" support will likely + change in the future to must support. The KDC may close the TCP stream + after sending a response, but may leave the stream open if it expects + a followup - in which case it may close the stream at any time if + resource constratints or other factors make it desirable to do so. + Care must be taken in managing TCP/IP connections with the KDC to + prevent denial of service attacks based on the number of TCP/IP + connections with the KDC that remain open. If multiple exchanges with + the KDC are needed for certain forms of preauthentication, multiple + TCP connections may be required. A client may close the stream after + receiving response, and should close the stream if it does not expect + to send followup messages. The client must be prepared to have the + stream closed by the KDC at anytime, in which case it must simply + connect again when it is ready to send subsequent messages. + + The first four octets of the TCP stream used to transmit the request + request will encode in network byte order the length of the request + (KRB_KDC_REQ), and the length will be followed by the request itself. + The response will similarly be preceeded by a 4 octet encoding in + network byte order of the length of the KRB_KDC_REP or the KRB_ERROR + message and will be followed by the KRB_KDC_REP or the KRB_ERROR + response. If the sign bit is set on the integer represented by the + first 4 octets, then the next 4 octets will be read, extending the + length of the field by another 4 octets (less the sign bit which is + reserved for future expansion). + + 8.2.3. OSI transport + + During authentication of an OSI client to an OSI server, the mutual + authentication of an OSI server to an OSI client, the transfer of + credentials from an OSI client to an OSI server, or during exchange of + private or integrity checked messages, Kerberos protocol messages may + be treated as opaque objects and the type of the authentication + mechanism will be: + + OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), +security(5),kerberosv5(2)} + + Depending on the situation, the opaque object will be an + authentication header (KRB_AP_REQ), an authentication reply + (KRB_AP_REP), a safe message (KRB_SAFE), a private message (KRB_PRIV), + or a credentials message (KRB_CRED). The opaque data contains an + application code as specified in the ASN.1 description for each + message. The application code may be used by Kerberos to determine the + message type. + + 8.2.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: (1) the realm of the KDC issuing the TGS + ticket (2) a two-part name of type NT-SRV-INST, with the first part + "krbtgt" and the second part the name of the realm which will accept + the ticket-granting ticket. For example, a ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" + (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), + ("krbtgt", "MIT.EDU") (name). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + 8.3. Protocol constants and associated values + + The following tables list constants used in the protocol and defines + their meanings. Ranges are specified in the "specification" section + that limit the values of constants for which values are defined here. + This allows implementations to make assumptions about the maximum + values that will be received for these constants. Implementation + receiving values outside the range specified in the "specification" + section may reject the request, but they must recover cleanly. + + Encryption type etype value block size minimum pad confounder +size + NULL 0 1 0 0 + des-cbc-crc 1 8 4 8 + des-cbc-md4 2 8 0 8 + des-cbc-md5 3 8 0 8 + reserved 4 + des3-cbc-md5 5 8 0 8 + reserved 6 + des3-cbc-sha1 7 8 0 8 + dsaWithSHA1-CmsOID 9 +(pkinit) + md5WithRSAEncryption-CmsOID 10 +(pkinit) + sha1WithRSAEncryption-CmsOID 11 +(pkinit) + rc2CBC-EnvOID 12 +(pkinit) + rsaEncryption-EnvOID 13 (pkinit from PKCS#1 +v1.5) + rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 +v2.0) + des-ede3-cbc-Env-OID 15 +(pkinit) + des3-cbc-sha1-kd 16 (Tom +Yu) + rc4-hmac 23 +(swift) + rc4-hmac-exp 24 +(swift) + + reserved 0x8003 + + Checksum type sumtype value checksum size + CRC32 1 4 + rsa-md4 2 16 + rsa-md4-des 3 24 + des-mac 4 16 + des-mac-k 5 8 + rsa-md4-des-k 6 16 (drop rsa ?) + rsa-md5 7 16 (drop rsa ?) + rsa-md5-des 8 24 (drop rsa ?) + rsa-md5-des3 9 24 (drop rsa ?) + hmac-sha1-des3-kd 12 20 + hmac-sha1-des3 13 20 + sha1 (unkeyed) 14 20 + + padata type padata-type value + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + reserved 4 + PA-ENC-UNIX-TIME 5 (depricated) + PA-SANDIA-SECUREID 6 + PA-SESAME 7 + PA-OSF-DCE 8 + PA-CYBERSAFE-SECUREID 9 + PA-AFS3-SALT 10 + PA-ETYPE-INFO 11 + PA-SAM-CHALLENGE 12 (sam/otp) + PA-SAM-RESPONSE 13 (sam/otp) + PA-PK-AS-REQ 14 (pkinit) + PA-PK-AS-REP 15 (pkinit) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 + PA-SAM-ETYPE-INFO 23 (sam/otp) + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + data-type value form of typed-data + + reserved 1-21 + TD-PADATA 22 + TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + TD-APP-DEFINED-ERROR 106 + + authorization data type ad-type value + AD-IF-RELEVANT 1 + AD-INTENDED-FOR-SERVER 2 + AD-INTENDED-FOR-APPLICATION-CLASS 3 + AD-KDC-ISSUED 4 + AD-OR 5 + AD-MANDATORY-TICKET-EXTENSIONS 6 + AD-IN-TICKET-EXTENSIONS 7 + reserved values 8-63 + OSF-DCE 64 + SESAME 65 + AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) + AD-WIN200-PAC 128 +(jbrezak@exchange.microsoft.com) + + Ticket Extension Types + + TE-TYPE-NULL 0 Null ticket extension + TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization +data + reserved 2 TE-TYPE-PKCROSS-KDC + TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket + TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp + reserved 5 TE-TYPE-DEST-HOST + + alternate authentication type method-type value + reserved values 0-63 + ATT-CHALLENGE-RESPONSE 64 + + transited encoding type tr-type value + DOMAIN-X500-COMPRESS 1 + reserved values all others + + Label Value Meaning or MIT code + + pvno 5 current Kerberos protocol version number + + message types + + KRB_AS_REQ 10 Request for initial authentication + KRB_AS_REP 11 Response to KRB_AS_REQ request + KRB_TGS_REQ 12 Request for authentication based on TGT + KRB_TGS_REP 13 Response to KRB_TGS_REQ request + KRB_AP_REQ 14 application request to server + KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL + KRB_SAFE 20 Safe (checksummed) application message + KRB_PRIV 21 Private (encrypted) application message + KRB_CRED 22 Private (encrypted) message to forward +credentials + KRB_ERROR 30 Error response + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + name types + + KRB_NT_UNKNOWN 0 Name type not known + KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or +for users + KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) + KRB_NT_SRV_HST 3 Service with host name as instance (telnet, +rcommands) + KRB_NT_SRV_XHST 4 Service with host as remaining components + KRB_NT_UID 5 Unique ID + KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] + + error codes + + KDC_ERR_NONE 0 No error + KDC_ERR_NAME_EXP 1 Client's entry in database has +expired + KDC_ERR_SERVICE_EXP 2 Server's entry in database has +expired + KDC_ERR_BAD_PVNO 3 Requested protocol version number +not supported + KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old +master key + KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old +master key + KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos +database + KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos +database + KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in +database + KDC_ERR_NULL_KEY 9 The client or server has a null key + KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating + KDC_ERR_NEVER_VALID 11 Requested start time is later than +end time + KDC_ERR_POLICY 12 KDC policy rejects request + KDC_ERR_BADOPTION 13 KDC cannot accommodate requested +option + KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption +type + KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum +type + KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type + KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited +type + KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been +revoked + KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been +revoked + KDC_ERR_TGT_REVOKED 20 TGT has been revoked + KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again +later + KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again +later + KDC_ERR_KEY_EXPIRED 23 Password has expired - change +password to reset + KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was +invalid + KDC_ERR_PREAUTH_REQUIRED 25 Additional +pre-authenticationrequired [40] + KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't +match + KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for +user2user only + KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path + KDC_ERR_SVC_UNAVAILABLE 29 A service is not available + KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field +failed + KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired + KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid + KRB_AP_ERR_REPEAT 34 Request is a replay + KRB_AP_ERR_NOT_US 35 The ticket isn't for us + KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't +match + KRB_AP_ERR_SKEW 37 Clock skew too great + KRB_AP_ERR_BADADDR 38 Incorrect net address + KRB_AP_ERR_BADVERSION 39 Protocol version mismatch + KRB_AP_ERR_MSG_TYPE 40 Invalid msg type + KRB_AP_ERR_MODIFIED 41 Message stream modified + KRB_AP_ERR_BADORDER 42 Message out of order + KRB_AP_ERR_BADKEYVER 44 Specified version of key is not +available + KRB_AP_ERR_NOKEY 45 Service key not available + KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed + KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction + KRB_AP_ERR_METHOD 48 Alternative authentication method +required + KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in +message + KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in +message + KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path + KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry +with TCP + KRB_ERR_GENERIC 60 Generic error (description in +e-text) + KRB_ERR_FIELD_TOOLONG 61 Field is too long for this +implementation + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) + KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) + KDC_ERROR_INVALID_SIG 64 (pkinit) + KDC_ERR_KEY_TOO_WEAK 65 (pkinit) + KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) + KRB_AP_ERR_NO_TGT 67 (user-to-user) + KDC_ERR_WRONG_REALM 68 (user-to-user) + KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) + KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) + KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) + KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) + KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) + + 9. Interoperability requirements + + Version 5 of the Kerberos protocol supports a myriad of options. Among + these are multiple encryption and checksum types, alternative encoding + schemes for the transited field, optional mechanisms for + pre-authentication, the handling of tickets with no addresses, options + for mutual authentication, user to user authentication, support for + proxies, forwarding, postdating, and renewing tickets, the format of + realm names, and the handling of authorization data. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration which must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + + 9.1. Specification 2 + + This section defines the second specification of these options. + Implementations which are configured in this way can be said to + support Kerberos Version 5 Specification 2 (5.1). Specification 1 + (depricated) may be found in RFC1510. + + Transport + + TCP/IP and UDP/IP transport must be supported by KDCs claiming + conformance to specification 2. Kerberos clients claiming conformance + to specification 2 must support UDP/IP transport for messages with the + KDC and should support TCP/IP transport. + + Encryption and checksum methods + + The following encryption and checksum mechanisms must be supported. + Implementations may support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them: This list is to be determined. + + Encryption: DES-CBC-MD5, one triple des variant (tbd) + Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd) + + Realm Names + + All implementations must understand hierarchical realms in both the + Internet Domain and the X.500 style. When a ticket granting ticket for + an unknown realm is requested, the KDC must be able to determine the + names of the intermediate realms between the KDCs realm and the + requested realm. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + Transited field encoding + + DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. + Alternative encodings may be supported, but they may be used only when + that encoding is supported by ALL intermediate realms. + + Pre-authentication methods + + The TGS-REQ method must be supported. The TGS-REQ method is not used + on the initial request. The PA-ENC-TIMESTAMP method must be supported + by clients but whether it is enabled by default may be determined on a + realm by realm basis. If not used in the initial request and the error + KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an + acceptable method, the client should retry the initial request using + the PA-ENC-TIMESTAMP preauthentication method. Servers need not + support the PA-ENC-TIMESTAMP method, but if not supported the server + should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a + request. + + Mutual authentication + + Mutual authentication (via the KRB_AP_REP message) must be supported. + + Ticket addresses and flags + + All KDC's must pass on tickets that carry no addresses (i.e. if a TGT + contains no addresses, the KDC will return derivative tickets), but + each realm may set its own policy for issuing such tickets, and each + application server will set its own policy with respect to accepting + them. + + Proxies and forwarded tickets must be supported. Individual realms and + application servers can set their own policy on when such tickets will + be accepted. + + All implementations must recognize renewable and postdated tickets, + but need not actually implement them. If these options are not + supported, the starttime and endtime in the ticket shall specify a + ticket's entire useful life. When a postdated ticket is decoded by a + server, all implementations shall make the presence of the postdated + flag visible to the calling server. + + User-to-user authentication + + Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC + option) must be provided by implementations, but individual realms may + decide as a matter of policy to reject such requests on a + per-principal or realm-wide basis. + + Authorization data + + Implementations must pass all authorization data subfields from + ticket-granting tickets to any derivative tickets unless directed to + suppress a subfield as part of the definition of that registered + subfield type (it is never incorrect to pass on a subfield, and no + registered subfield types presently specify suppression at the KDC). + + Implementations must make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + Constant ranges + + All protocol constants are constrained to 32 bit (signed) values + unless further constrained by the protocol definition. This limit is + provided to allow implementations to make assumptions about the + maximum values that will be received for these constants. + Implementation receiving values outside this range may reject the + request, but they must recover cleanly. + + 9.2. Recommended KDC values + + Following is a list of recommended values for a KDC implementation, + based on the list of suggested configuration constants (see section + 4.4). + + minimum lifetime 5 minutes + maximum renewable lifetime 1 week + maximum ticket lifetime 1 day + empty addresses only when suitable restrictions appear + in authorization data + proxiable, etc. Allowed. + + 10. REFERENCES + + [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- + cation Service for Computer Networks," IEEE Communica- + tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). + + [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. + Saltzer, Section E.2.1: Kerberos Authentication and + Authorization System, M.I.T. Project Athena, Cambridge, + Massachusetts (December 21, 1987). + + [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- + beros: An Authentication Service for Open Network Sys- + tems," pp. 191-202 in Usenix Conference Proceedings, + Dallas, Texas (February, 1988). + + [NS78] Roger M. Needham and Michael D. Schroeder, "Using + Encryption for Authentication in Large Networks of Com- + puters," Communications of the ACM, Vol. 21(12), + pp. 993-999 (December, 1978). + + [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- + stamps in Key Distribution Protocols," Communications + of the ACM, Vol. 24(8), pp. 533-536 (August 1981). + + [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, + "The Evolution of the Kerberos Authentication Service," + in an IEEE Computer Society Text soon to be published + (June 1992). + + [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in Proceedings of + the 13th International Conference on Distributed Com- + puting Systems, Pittsburgh, PA (May, 1993). + + [DS90] Don Davis and Ralph Swick, "Workstation Services and + Kerberos Authentication at Project Athena," Technical + Memorandum TM-424, MIT Laboratory for Computer Science + (February 1990). + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- + merfeld, and K. Raeburn, Section E.1: Service Manage- + ment System, M.I.T. Project Athena, Cambridge, Mas- + sachusetts (1987). + + [X509-88] CCITT, Recommendation X.509: The Directory Authentica- + tion Framework, December 1988. + + [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password + Guessing Attacks, Open Software Foundation DCE Request + for Comments 26 (December 1992). + + [DES77] National Bureau of Standards, U.S. Department of Com- + merce, "Data Encryption Standard," Federal Information + Processing Standards Publication 46, Washington, DC + (1977). + + [DESM80] National Bureau of Standards, U.S. Department of Com- + merce, "DES Modes of Operation," Federal Information + Processing Standards Publication 81, Springfield, VA + (December 1980). + + [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message + Integrity in Cryptographic Protocols," in Proceedings + of the IEEE Symposium on Research in Security and + Privacy, Oakland, California (May 1992). + + [IS3309] International Organization for Standardization, "ISO + Information Processing Systems - Data Communication - + High-Level Data Link Control Procedure - Frame Struc- + ture," IS 3309 (October 1984). 3rd Edition. + + [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC + 1320, MIT Laboratory for Computer Science (April + 1992). + + [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC + 1321, MIT Laboratory for Computer Science (April + 1992). + + [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication," Working Draft + draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). + + [Horowitz96] Horowitz, M., "Key Derivation for Authentication, + Integrity, and Privacy", +draft-horowitz-key-derivation-02.txt, + August 1998. + + [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- + horowitz-kerb-key-derivation-01.txt, September 1998. + + [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", +draft-ietf-ipsec-hmac- + md5-01.txt, August, 1996. + + A. Pseudo-code for protocol processing + + This appendix provides pseudo-code describing how the messages are to + be constructed and interpreted by clients and servers. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + A.1. KRB_AS_REQ generation + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_AS_REQ */ + + if(pa_enc_timestamp_required) then + request.padata.padata-type = PA-ENC-TIMESTAMP; + get system_time; + padata-body.patimestamp,pausec = system_time; + encrypt padata-body into request.padata.padata-value + using client.key; /* derived from password */ + endif + + body.kdc-options := users's preferences; + body.cname := user's name; + body.realm := user's realm; + body.sname := service's name; /* usually "krbtgt", +"localrealm" */ + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + omit body.enc-authorization-data; + request.req-body := body; + + kerberos := lookup(name of local kerberos server (or servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.2. KRB_AS_REQ verification and KRB_AS_REP generation + + decode message into req; + + client := lookup(req.cname,req.realm); + server := lookup(req.sname,req.realm); + + get system_time; + kdc_time := system_time.seconds; + + if (!client) then + /* no client in Database */ + error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); + endif + if (!server) then + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + + if(client.pa_enc_timestamp_required and + pa_enc_timestamp not present) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); + endif + + if(pa_enc_timestamp present) then + decrypt req.padata-value into decrypted_enc_timestamp + using client.key; + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + if(decrypted_enc_timestamp is not within allowable +skew) then + error_out(KDC_ERR_PREAUTH_FAILED); + endif + if(decrypted_enc_timestamp and usec is replay) + error_out(KDC_ERR_PREAUTH_FAILED); + endif + add decrypted_enc_timestamp and usec to replay cache; + endif + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := req.srealm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + if (req.kdc-options.FORWARDABLE is set) then + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.PROXIABLE is set) then + set new_tkt.flags.PROXIABLE; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + set new_tkt.flags.MAY-POSTDATE; + endif + if ((req.kdc-options.RENEW is set) or + (req.kdc-options.VALIDATE is set) or + (req.kdc-options.PROXY is set) or + (req.kdc-options.FORWARDED is set) or + (req.kdc-options.ENC-TKT-IN-SKEY is set)) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.session := random_session_key(); + new_tkt.cname := req.cname; + new_tkt.crealm := req.crealm; + new_tkt.transited := empty_transited_field(); + + new_tkt.authtime := kdc_time; + + if (req.kdc-options.POSTDATED is set) then + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + new_tkt.starttime := req.from; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + else + omit new_tkt.starttime; /* treated as authtime when omitted +*/ + endif + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till)) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := req.till; + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if (req.kdc-options.RENEWABLE is set) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + +new_tkt.starttime+client.max_rlife, + +new_tkt.starttime+server.max_rlife, + +new_tkt.starttime+max_rlife_for_realm); + else + omit new_tkt.renew-till; /* only present if RENEWABLE +*/ + endif + + if (req.addresses) then + new_tkt.caddr := req.addresses; + else + omit new_tkt.caddr; + endif + + new_tkt.authorization_data := empty_authorization_data(); + + encode to-be-encrypted part of ticket into OCTET STRING; + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, +server.p_kvno; + + /* Start processing the response */ + + resp.pvno := 5; + resp.msg-type := KRB_AS_REP; + resp.cname := req.cname; + resp.crealm := req.realm; + resp.ticket := new_tkt; + + resp.key := new_tkt.session; + resp.last-req := fetch_last_request_info(client); + resp.nonce := req.nonce; + resp.key-expiration := client.expiration; + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + resp.endtime := new_tkt.endtime; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + resp.realm := new_tkt.realm; + resp.sname := new_tkt.sname; + + resp.caddr := new_tkt.caddr; + + encode body of reply into OCTET STRING; + + resp.enc-part := encrypt OCTET STRING + using use_etype, client.key, client.p_kvno; + send(resp); + + A.3. KRB_AS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) +then + set pa_enc_timestamp_required; + goto KRB_AS_REQ; + endif + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key */ + /* from the response immediately */ + + key = get_decryption_key(resp.enc-part.kvno, +resp.enc-part.etype, + resp.padata); + unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and key; + zero(key); + + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + if near(resp.princ_exp) then + print(warning message); + endif + save_for_later(ticket,session,client,server,times,flags); + + A.4. KRB_AS_REP and KRB_TGS_REP common checks + + if (decryption_error() or + (req.cname != resp.cname) or + (req.realm != resp.crealm) or + (req.sname != resp.sname) or + (req.realm != resp.realm) or + (req.nonce != resp.nonce) or + (req.addresses != resp.caddr)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + /* make sure no flags are set that shouldn't be, and that all +that */ + /* should be are set +*/ + if (!check_flags_for_compatability(req.kdc-options,resp.flags)) +then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.from = 0) and + (resp.starttime is not within allowable skew)) then + destroy resp.key; + return KRB_AP_ERR_SKEW; + endif + if ((req.from != 0) and (req.from != resp.starttime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.till != 0) and (resp.endtime > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (req.rtime != 0) and (resp.renew-till > req.rtime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.kdc-options.RENEWABLE-OK is set) and + (resp.flags.RENEWABLE) and + (req.till != 0) and + (resp.renew-till > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + A.5. KRB_TGS_REQ generation + + /* Note that make_application_request might have to recursivly +*/ + /* call this routine to get the appropriate ticket-granting +ticket */ + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_TGS_REQ */ + + body.kdc-options := users's preferences; + /* If the TGT is not for the realm of the end-server */ + /* then the sname will be for a TGT for the end-realm */ + /* and the realm of the requested ticket (body.realm) */ + /* will be that of the TGS to which the TGT we are */ + /* sending applies */ + body.sname := service's name; + body.realm := service's realm; + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + body.enc-authorization-data := user-supplied data; + if (body.kdc-options.ENC-TKT-IN-SKEY) then + body.additional-tickets_ticket := second TGT; + endif + + request.req-body := body; + check := generate_checksum (req.body,checksumtype); + + request.padata[0].padata-type := PA-TGS-REQ; + request.padata[0].padata-value := create a KRB_AP_REQ using + the TGT and checksum + + /* add in any other padata as required/supplied */ + + kerberos := lookup(name of local kerberose server (or +servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation + + /* note that reading the application request requires first + determining the server for which a ticket was issued, and +choosing the + correct key for decryption. The name of the server appears in +the + plaintext part of the ticket. */ + + if (no KRB_AP_REQ in req.padata) then + error_out(KDC_ERR_PADATA_TYPE_NOSUPP); + endif + verify KRB_AP_REQ in req.padata; + + /* Note that the realm in which the Kerberos server is +operating is + determined by the instance from the ticket-granting ticket. +The realm + in the ticket-granting ticket is the realm under which the +ticket + granting ticket was issued. It is possible for a single +Kerberos + server to support more than one realm. */ + + auth_hdr := KRB_AP_REQ; + tgt := auth_hdr.ticket; + + if (tgt.sname is not a TGT for local realm and is not +req.sname) then + error_out(KRB_AP_ERR_NOT_US); + + realm := realm_tgt_is_for(tgt); + + decode remainder of request; + + if (auth_hdr.authenticator.cksum is missing) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + if (auth_hdr.authenticator.cksum type is not supported) then + error_out(KDC_ERR_SUMTYPE_NOSUPP); + endif + if (auth_hdr.authenticator.cksum is not both collision-proof +and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + set computed_checksum := checksum(req); + if (computed_checksum != auth_hdr.authenticatory.cksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + + server := lookup(req.sname,realm); + + if (!server) then + if (is_foreign_tgt_name(req.sname)) then + server := best_intermediate_tgs(req.sname); + else + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + endif + + session := generate_random_session_key(); + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := realm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + new_tkt.caddr := tgt.caddr; + resp.caddr := NULL; /* We only include this if they change */ + if (req.kdc-options.FORWARDABLE is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.FORWARDED is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDED; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + if (tgt.flags.FORWARDED is set) then + set new_tkt.flags.FORWARDED; + endif + + if (req.kdc-options.PROXIABLE is set) then + if (tgt.flags.PROXIABLE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXIABLE; + endif + if (req.kdc-options.PROXY is set) then + if (tgt.flags.PROXIABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXY; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + if (tgt.flags.MAY-POSTDATE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.MAY-POSTDATE; + endif + if (req.kdc-options.POSTDATED is set) then + if (tgt.flags.MAY-POSTDATE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + new_tkt.starttime := req.from; + endif + + if (req.kdc-options.VALIDATE is set) then + if (tgt.flags.INVALID is reset) then + error_out(KDC_ERR_POLICY); + endif + if (tgt.starttime > kdc_time) then + error_out(KRB_AP_ERR_NYV); + endif + if (check_hot_list(tgt)) then + error_out(KRB_AP_ERR_REPEAT); + endif + tkt := tgt; + reset new_tkt.flags.INVALID; + endif + + if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, + and those already processed) is set) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.authtime := tgt.authtime; + + if (req.kdc-options.RENEW is set) then + /* Note that if the endtime has already passed, the ticket +would */ + /* have been rejected in the initial authentication stage, so +*/ + /* there is no need to check again here +*/ + if (tgt.flags.RENEWABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + if (tgt.renew-till < kdc_time) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + tkt := tgt; + new_tkt.starttime := kdc_time; + old_life := tgt.endttime - tgt.starttime; + new_tkt.endtime := min(tgt.renew-till, + new_tkt.starttime + old_life); + else + new_tkt.starttime := kdc_time; + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + new_tkt.endtime := min(till, + +new_tkt.starttime+client.max_life, + +new_tkt.starttime+server.max_life, + +new_tkt.starttime+max_life_for_realm, + tgt.endtime); + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till) and + (tgt.flags.RENEWABLE is set) then + /* we set the RENEWABLE option for later +processing */ + set req.kdc-options.RENEWABLE; + req.rtime := min(req.till, tgt.renew-till); + endif + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (tgt.flags.RENEWABLE is set)) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + +new_tkt.starttime+client.max_rlife, + +new_tkt.starttime+server.max_rlife, + +new_tkt.starttime+max_rlife_for_realm, + tgt.renew-till); + else + new_tkt.renew-till := OMIT; /* leave the renew-till +field out */ + endif + if (req.enc-authorization-data is present) then + decrypt req.enc-authorization-data into +decrypted_authorization_data + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + endif + new_tkt.authorization_data := +req.auth_hdr.ticket.authorization_data + + decrypted_authorization_data; + + new_tkt.key := session; + new_tkt.crealm := tgt.crealm; + new_tkt.cname := req.auth_hdr.ticket.cname; + + if (realm_tgt_is_for(tgt) := tgt.realm) then + /* tgt issued by local realm */ + new_tkt.transited := tgt.transited; + else + /* was issued for this realm by some other realm */ + if (tgt.transited.tr-type not supported) then + error_out(KDC_ERR_TRTYPE_NOSUPP); + endif + new_tkt.transited := compress_transited(tgt.transited + +tgt.realm) + /* Don't check tranited field if TGT for foreign realm, + * or requested not to check */ + if (is_not_foreign_tgt_name(new_tkt.server) + && req.kdc-options.DISABLE-TRANSITED-CHECK not set) +then + /* Check it, so end-server does not have to + * but don't fail, end-server may still accept +it */ + if (check_transited_field(new_tkt.transited) == +OK) + set +new_tkt.flags.TRANSITED-POLICY-CHECKED; + endif + endif + endif + + encode encrypted part of new_tkt into OCTET STRING; + if (req.kdc-options.ENC-TKT-IN-SKEY is set) then + if (server not specified) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + server = req.second_ticket.client; + endif + if ((req.second_ticket is not a TGT) or + (req.second_ticket.client != server)) then + error_out(KDC_ERR_POLICY); + endif + + new_tkt.enc-part := encrypt OCTET STRING using + using etype_for_key(second-ticket.key), +second-ticket.key; + else + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, +server.p_kvno; + endif + + resp.pvno := 5; + resp.msg-type := KRB_TGS_REP; + resp.crealm := tgt.crealm; + resp.cname := tgt.cname; + resp.ticket := new_tkt; + + resp.key := session; + resp.nonce := req.nonce; + resp.last-req := fetch_last_request_info(client); + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + omit resp.key-expiration; + + resp.sname := new_tkt.sname; + resp.realm := new_tkt.realm; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + encode body of reply into OCTET STRING; + + if (req.padata.authenticator.subkey) + resp.enc-part := encrypt OCTET STRING using use_etype, + req.padata.authenticator.subkey; + else resp.enc-part := encrypt OCTET STRING using use_etype, +tgt.key; + + send(resp); + + A.7. KRB_TGS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key +from + the response immediately */ + + if (req.padata.authenticator.subkey) + unencrypted part of resp := decode of decrypt of +resp.enc-part + using resp.enc-part.etype and subkey; + else unencrypted part of resp := decode of decrypt of +resp.enc-part + using resp.enc-part.etype and tgt's +session key; + if (common_as_rep_tgs_rep_checks fail) then + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + destroy resp.key; + return error; + endif + + check authorization_data as necessary; + save_for_later(ticket,session,client,server,times,flags); + + A.8. Authenticator generation + + body.authenticator-vno := authenticator vno; /* = 5 */ + body.cname, body.crealm := client name; + if (supplying checksum) then + body.cksum := checksum; + endif + get system_time; + body.ctime, body.cusec := system_time; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + A.9. KRB_AP_REQ generation + + obtain ticket and session_key from cache; + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REQ */ + + if (desired(MUTUAL_AUTHENTICATION)) then + set packet.ap-options.MUTUAL-REQUIRED; + else + reset packet.ap-options.MUTUAL-REQUIRED; + endif + if (using session key for ticket) then + set packet.ap-options.USE-SESSION-KEY; + else + reset packet.ap-options.USE-SESSION-KEY; + endif + packet.ticket := ticket; /* ticket */ + generate authenticator; + encode authenticator into OCTET STRING; + encrypt OCTET STRING into packet.authenticator using +session_key; + + A.10. KRB_AP_REQ verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REQ) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.ticket.tkt_vno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.ap_options.USE-SESSION-KEY is set) then + retrieve session key from ticket-granting ticket for + packet.ticket.{sname,srealm,enc-part.etype}; + else + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + retrieve service key for + +packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; + endif + if (no_key_available) then + if (cannot_find_specified_skvno) then + error_out(KRB_AP_ERR_BADKEYVER); + else + error_out(KRB_AP_ERR_NOKEY); + endif + endif + decrypt packet.ticket.enc-part into decr_ticket using retrieved +key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + decrypt packet.authenticator into decr_authenticator + using decr_ticket.key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (decr_authenticator.{cname,crealm} != + decr_ticket.{cname,crealm}) then + error_out(KRB_AP_ERR_BADMATCH); + endif + if (decr_ticket.caddr is present) then + if (sender_address(packet) is not in decr_ticket.caddr) +then + error_out(KRB_AP_ERR_BADADDR); + endif + elseif (application requires addresses) then + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(decr_authenticator.ctime, + decr_authenticator.cusec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) +then + error_out(KRB_AP_ERR_REPEAT); + endif + save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); + get system_time; + if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or + (decr_ticket.flags.INVALID is set)) then + /* it hasn't yet become valid */ + error_out(KRB_AP_ERR_TKT_NYV); + endif + if (system_time-decr_ticket.endtime > CLOCK_SKEW) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + if (decr_ticket.transited) then + /* caller may ignore the TRANSITED-POLICY-CHECKED and do + * check anyway */ + if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) +then + if (check_transited_field(decr_ticket.transited) then + error_out(KDC_AP_PATH_NOT_ACCPETED); + endif + endif + endif + /* caller must check decr_ticket.flags for any pertinent +details */ + return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); + + A.11. KRB_AP_REP generation + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REP */ + + body.ctime := packet.ctime; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + body.cusec := packet.cusec; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part; + + A.12. KRB_AP_REP verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REP) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + cleartext := decrypt(packet.enc-part) using ticket's session +key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (cleartext.ctime != authenticator.ctime) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.cusec != authenticator.cusec) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.subkey is present) then + save cleartext.subkey for future use; + endif + if (cleartext.seq-number is present) then + save cleartext.seq-number for future verifications; + endif + return(AUTHENTICATION_SUCCEEDED); + + A.13. KRB_SAFE generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_SAFE */ + + body.user-data := buffer; /* DATA */ + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + checksum.cksumtype := checksum type; + compute checksum over body; + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + checksum.checksum := checksum value; /* checksum.checksum */ + packet.cksum := checksum; + packet.safe-body := body; + + A.14. KRB_SAFE verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_SAFE) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.checksum.cksumtype is not both collision-proof and +keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + if (safe_priv_common_checks_ok(packet)) then + set computed_checksum := checksum(packet.body); + if (computed_checksum != packet.checksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + return (packet, PACKET_IS_GENUINE); + else + return common_checks_error; + endif + + A.15. KRB_SAFE and KRB_PRIV common checks + + if (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it +*/ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (((packet.timestamp is present) and + (not in_clock_skew(packet.timestamp,packet.usec))) or + (packet.timestamp is not present and timestamp expected)) +then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) +then + error_out(KRB_AP_ERR_REPEAT); + endif + + if (((packet.seq-number is present) and + ((not in_sequence(packet.seq-number)))) or + (packet.seq-number is not present and sequence expected)) +then + error_out(KRB_AP_ERR_BADORDER); + endif + if (packet.timestamp not present and packet.seq-number not +present) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + save_identifier(packet.{timestamp,usec,s-address}, + sender_principal(packet)); + + return PACKET_IS_OK; + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + A.16. KRB_PRIV generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_PRIV */ + + packet.enc-part.etype := encryption type; + + body.user-data := buffer; + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher; + + A.17. KRB_PRIV verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_PRIV) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + + if (safe_priv_common_checks_ok(cleartext)) then + return(cleartext.DATA, +PACKET_IS_GENUINE_AND_UNMODIFIED); + else + return common_checks_error; + endif + + A.18. KRB_CRED generation + + invoke KRB_TGS; /* obtain tickets to be provided to peer */ + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_CRED */ + + for (tickets[n] in tickets to be forwarded) do + packet.tickets[n] = tickets[n].ticket; + done + + packet.enc-part.etype := encryption type; + + for (ticket[n] in tickets to be forwarded) do + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + body.ticket-info[n].key = tickets[n].session; + body.ticket-info[n].prealm = tickets[n].crealm; + body.ticket-info[n].pname = tickets[n].cname; + body.ticket-info[n].flags = tickets[n].flags; + body.ticket-info[n].authtime = tickets[n].authtime; + body.ticket-info[n].starttime = tickets[n].starttime; + body.ticket-info[n].endtime = tickets[n].endtime; + body.ticket-info[n].renew-till = tickets[n].renew-till; + body.ticket-info[n].srealm = tickets[n].srealm; + body.ticket-info[n].sname = tickets[n].sname; + body.ticket-info[n].caddr = tickets[n].caddr; + done + + get system_time; + body.timestamp, body.usec := system_time; + + if (using nonce) then + body.nonce := nonce; + endif + + if (using s-address) then + body.s-address := sender host addresses; + endif + if (limited recipients) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher + using negotiated encryption key; + + A.19. KRB_CRED verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_CRED) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if ((packet.r-address is present or required) and + (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it +*/ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(packet.timestamp,packet.usec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) +then + error_out(KRB_AP_ERR_REPEAT); + endif + if (packet.nonce is required or present) and + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + (packet.nonce != expected-nonce) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + for (ticket[n] in tickets that were forwarded) do + save_for_later(ticket[n],key[n],principal[n], + server[n],times[n],flags[n]); + return + + A.20. KRB_ERROR generation + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_ERROR */ + + get system_time; + packet.stime, packet.susec := system_time; + packet.realm, packet.sname := server name; + + if (client time available) then + packet.ctime, packet.cusec := client_time; + endif + packet.error-code := error code; + if (client name available) then + packet.cname, packet.crealm := client name; + endif + if (error text available) then + packet.e-text := error text; + endif + if (error data available) then + packet.e-data := error data; + endif + + B. Definition of common authorization data elements + + This appendix contains the definitions of common authorization data + elements. These common authorization data elements are recursivly + defined, meaning the ad-data for these types will itself contain a + sequence of authorization data whose interpretation is affected by the + encapsulating element. Depending on the meaning of the encapsulating + element, the encapsulated elements may be ignored, might be + interpreted as issued directly by the KDC, or they might be stored in + a separate plaintext part of the ticket. The types of the + encapsulating elements are specified as part of the Kerberos + specification because the behavior based on these values should be + understood across implementations whereas other elements need only be + understood by the applications which they affect. + + In the definitions that follow, the value of the ad-type for the + element will be specified in the subsection number, and the value of + the ad-data will be as shown in the ASN.1 structure that follows the + subsection heading. + + B.1. If relevant + + AD-IF-RELEVANT AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that + do not understand the type of an element embedded within the + if-relevant element may ignore the uninterpretable element. This + element promotes interoperability across implementations which may + have local extensions for authorization. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + B.2. Intended for server + + AD-INTENDED-FOR-SERVER SEQUENCE { + intended-server[0] SEQUENCE OF PrincipalName + elements[1] AuthorizationData + } + + AD elements encapsulated within the intended-for-server element may be + ignored if the application server is not in the list of principal + names of intended servers. Further, a KDC issuing a ticket for an + application server can remove this element if the application server + is not in the list of intended servers. + + Application servers should check for their principal name in the + intended-server field of this element. If their principal name is not + found, this element should be ignored. If found, then the encapsulated + elements should be evaluated in the same manner as if they were + present in the top level authorization data field. Applications and + application servers that do not implement this element should reject + tickets that contain authorization data elements of this type. + + B.3. Intended for application class + + AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { + intended-application-class[0] SEQUENCE OF GeneralString elements[1] + AuthorizationData } AD elements encapsulated within the + intended-for-application-class element may be ignored if the + application server is not in one of the named classes of application + servers. Examples of application server classes include "FILESYSTEM", + and other kinds of servers. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.4. KDC Issued + + AD-KDCIssued SEQUENCE { + ad-checksum[0] Checksum, + i-realm[1] Realm OPTIONAL, + i-sname[2] PrincipalName OPTIONAL, + elements[3] AuthorizationData. + } + + ad-checksum + A checksum over the elements field using a cryptographic checksum + method that is identical to the checksum used to protect the + ticket itself (i.e. using the same hash function and the same + encryption algorithm used to encrypt the ticket) and using a key + derived from the same key used to protect the ticket. + i-realm, i-sname + The name of the issuing principal if different from the KDC + itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal and it + allows this KDC to notify the application server of the validity + of those elements. + elements + A sequence of authorization data elements issued by the KDC. + The KDC-issued ad-data field is intended to provide a means for + Kerberos principal credentials to embed within themselves privilege + attributes and other mechanisms for positive authorization, amplifying + the priveleges of the principal beyond what can be done using a + credentials without such an a-data element. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + This can not be provided without this element because the definition + of the authorization-data field allows elements to be added at will by + the bearer of a TGT at the time that they request service tickets and + elements may also be added to a delegated ticket by inclusion in the + authenticator. + + For KDC-issued elements this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the server's + key (the same key used to encrypt the ticket - or a key derived from + that key). Elements encapsulated with in the KDC-issued element will + be ignored by the application server if this "signature" is not + present. Further, elements encapsulated within this element from a + ticket granting ticket may be interpreted by the KDC, and used as a + basis according to policy for including new signed elements within + derivative tickets, but they will not be copied to a derivative ticket + directly. If they are copied directly to a derivative ticket by a KDC + that is not aware of this element, the signature will not be correct + for the application ticket elements, and the field will be ignored by + the application server. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.5. And-Or + + AD-AND-OR SEQUENCE { + condition-count[0] INTEGER, + elements[1] AuthorizationData + } + + When restrictive AD elements encapsulated within the and-or element + are encountered, only the number specified in condition-count of the + encapsulated conditions must be met in order to satisfy this element. + This element may be used to implement an "or" operation by setting the + condition-count field to 1, and it may specify an "and" operation by + setting the condition count to the number of embedded elements. + Application servers that do not implement this element must reject + tickets that contain authorization data elements of this type. + + B.6. Mandatory ticket extensions + + AD-Mandatory-Ticket-Extensions SEQUENCE { + te-type[0] INTEGER, + te-checksum[0] Checksum + } + + An authorization data element of type mandatory-ticket-extensions + specifies the type and a collision-proof checksum using the same hash + algorithm used to protect the integrity of the ticket itself. This + checksum will be calculated over an individual extension field of the + type indicated. If there are more than one extension, multiple + Mandatory-Ticket-Extensions authorization data elements may be + present, each with a checksum for a different extension field. This + restriction indicates that the ticket should not be accepted if a + ticket extension is not present in the ticket for which the type and + checksum do not match that checksum specified in the authorization + data element. Note that although the type is redundant for the + purposes of the comparison, it makes the comparison easier when + multiple extensions are present. Application servers that do not + implement this element must reject tickets that contain authorization + data elements of this type. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + B.7. Authorization Data in ticket extensions + + AD-IN-Ticket-Extensions Checksum + + An authorization data element of type in-ticket-extensions specifies a + collision-proof checksum using the same hash algorithm used to protect + the integrity of the ticket itself. This checksum is calculated over a + separate external AuthorizationData field carried in the ticket + extensions. Application servers that do not implement this element + must reject tickets that contain authorization data elements of this + type. Application servers that do implement this element will search + the ticket extensions for authorization data fields, calculate the + specified checksum over each authorization data field and look for one + matching the checksum in this in-ticket-extensions element. If not + found, then the ticket must be rejected. If found, the corresponding + authorization data elements will be interpreted in the same manner as + if they were contained in the top level authorization data field. + + Note that if multiple external authorization data fields are present + in a ticket, each will have a corresponding element of type + in-ticket-extensions in the top level authorization data field, and + the external entries will be linked to the corresponding element by + their checksums. + + C. Definition of common ticket extensions + + This appendix contains the definitions of common ticket extensions. + Support for these extensions is optional. However, certain extensions + have associated authorization data elements that may require rejection + of a ticket containing an extension by application servers that do not + implement the particular extension. Other extensions have been defined + beyond those described in this specification. Such extensions are + described elswhere and for some of those extensions the reserved + number may be found in the list of constants. + + It is known that older versions of Kerberos did not support this + field, and that some clients will strip this field from a ticket when + they parse and then reassemble a ticket as it is passed to the + application servers. The presence of the extension will not break such + clients, but any functionaly dependent on the extensions will not work + when such tickets are handled by old clients. In such situations, some + implementation may use alternate methods to transmit the information + in the extensions field. + + C.1. Null ticket extension + + TE-NullExtension OctetString -- The empty Octet String + + The te-data field in the null ticket extension is an octet string of + lenght zero. This extension may be included in a ticket granting + ticket so that the KDC can determine on presentation of the ticket + granting ticket whether the client software will strip the extensions + field. + + C.2. External Authorization Data + + TE-ExternalAuthorizationData AuthorizationData + + The te-data field in the external authorization data ticket extension + is field of type AuthorizationData containing one or more + authorization data elements. If present, a corresponding authorization + data element will be present in the primary authorization data for the + ticket and that element will contain a checksum of the external + authorization data ticket extension. + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + ---------------------------------------------------------------------- + [TM] Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). No commercial use of + these trademarks may be made without prior written permission of MIT. + + [1] Note, however, that many applications use Kerberos' functions only + upon the initiation of a stream-based network connection. Unless an + application subsequently provides integrity protection for the data + stream, the identity verification applies only to the initiation of + the connection, and does not guarantee that subsequent messages on the + connection originate from the same principal. + + [2] Secret and private are often used interchangeably in the + literature. In our usage, it takes two (or more) to share a secret, + thus a shared DES key is a secret key. Something is only private when + no one but its owner knows it. Thus, in public key cryptosystems, one + has a public and a private key. + + [3] Of course, with appropriate permission the client could arrange + registration of a separately-named prin- cipal in a remote realm, and + engage in normal exchanges with that realm's services. However, for + even small numbers of clients this becomes cumbersome, and more + automatic methods as described here are necessary. + + [4] Though it is permissible to request or issue tick- ets with no + network addresses specified. + + [5] The password-changing request must not be honored unless the + requester can provide the old password (the user's current secret + key). Otherwise, it would be possible for someone to walk up to an + unattended ses- sion and change another user's password. + + [6] To authenticate a user logging on to a local system, the + credentials obtained in the AS exchange may first be used in a TGS + exchange to obtain credentials for a local server. Those credentials + must then be verified by a local server through successful completion + of the Client/Server exchange. + + [7] "Random" means that, among other things, it should be impossible + to guess the next session key based on knowledge of past session keys. + This can only be achieved in a pseudo-random number generator if it is + based on cryptographic principles. It is more desirable to use a truly + random number generator, such as one based on measurements of random + physical phenomena. + + [8] Tickets contain both an encrypted and unencrypted portion, so + cleartext here refers to the entire unit, which can be copied from one + message and replayed in another without any cryptographic skill. + + [9] Note that this can make applications based on unreliable + transports difficult to code correctly. If the transport might deliver + duplicated messages, either a new authenticator must be generated for + each retry, or the application server must match requests and replies + and replay the first reply in response to a detected duplicate. + + [10] This is used for user-to-user authentication as described in [8]. + + [11] Note that the rejection here is restricted to authenticators from + the same principal to the same server. Other client principals + communicating with the same server principal should not be have their + authenticators rejected if the time and microsecond fields happen to + match some other client's authenticator. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [12] In the Kerberos version 4 protocol, the timestamp in the reply + was the client's timestamp plus one. This is not necessary in version + 5 because version 5 messages are formatted in such a way that it is + not possible to create the reply by judicious message surgery (even in + encrypted form) without knowledge of the appropriate encryption keys. + + [13] Note that for encrypting the KRB_AP_REP message, the sub-session + key is not used, even if present in the Authenticator. + + [14] Implementations of the protocol may wish to provide routines to + choose subkeys based on session keys and random numbers and to + generate a negotiated key to be returned in the KRB_AP_REP message. + + [15]This can be accomplished in several ways. It might be known + beforehand (since the realm is part of the principal identifier), it + might be stored in a nameserver, or it might be obtained from a + configura- tion file. If the realm to be used is obtained from a + nameserver, there is a danger of being spoofed if the nameservice + providing the realm name is not authenti- cated. This might result in + the use of a realm which has been compromised, and would result in an + attacker's ability to compromise the authentication of the application + server to the client. + + [16] If the client selects a sub-session key, care must be taken to + ensure the randomness of the selected sub- session key. One approach + would be to generate a random number and XOR it with the session key + from the ticket-granting ticket. + + [17] This allows easy implementation of user-to-user authentication + [8], which uses ticket-granting ticket session keys in lieu of secret + server keys in situa- tions where such secret keys could be easily + comprom- ised. + + [18] For the purpose of appending, the realm preceding the first + listed realm is considered to be the null realm (""). + + [19] For the purpose of interpreting null subfields, the client's + realm is considered to precede those in the transited field, and the + server's realm is considered to follow them. + + [20] This means that a client and server running on the same host and + communicating with one another using the KRB_SAFE messages should not + share a common replay cache to detect KRB_SAFE replays. + + [21] The implementation of the Kerberos server need not combine the + database and the server on the same machine; it is feasible to store + the principal database in, say, a network name service, as long as the + entries stored therein are protected from disclosure to and + modification by unauthorized parties. However, we recommend against + such strategies, as they can make system management and threat + analysis quite complex. + + [22] See the discussion of the padata field in section 5.4.2 for + details on why this can be useful. + + [23] Warning for implementations that unpack and repack data + structures during the generation and verification of embedded + checksums: Because any checksums applied to data structures must be + checked against the original data the length of bit strings must be + preserved within a data structure between the time that a checksum is + generated through transmission to the time that the checksum is + verified. + + +Neuman, Ts'o, Kohl Expires: 14 January +2001 + +^L + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-06 July 14, +2000 + + [24] It is NOT recommended that this time value be used to adjust the + workstation's clock since the workstation cannot reliably determine + that such a KRB_AS_REP actually came from the proper KDC in a timely + manner. + + [25] Note, however, that if the time is used as the nonce, one must + make sure that the workstation time is monotonically increasing. If + the time is ever reset backwards, there is a small, but finite, + probability that a nonce will be reused. + + [27] An application code in the encrypted part of a message provides + an additional check that the message was decrypted properly. + + [29] An application code in the encrypted part of a message provides + an additional check that the message was decrypted properly. + + [31] An application code in the encrypted part of a message provides + an additional check that the message was decrypted properly. + + [32] If supported by the encryption method in use, an initialization + vector may be passed to the encryption procedure, in order to achieve + proper cipher chaining. The initialization vector might come from the + last block of the ciphertext from the previous KRB_PRIV message, but + it is the application's choice whether or not to use such an + initialization vector. If left out, the default initialization vector + for the encryption algorithm will be used. + + [33] This prevents an attacker who generates an incorrect AS request + from obtaining verifiable plaintext for use in an off-line password + guessing attack. + + [35] In the above specification, UNTAGGED OCTET STRING(length) is the + notation for an octet string with its tag and length removed. It is + not a valid ASN.1 type. The tag bits and length must be removed from + the confounder since the purpose of the confounder is so that the + message starts with random data, but the tag and its length are fixed. + For other fields, the length and tag would be redundant if they were + included because they are specified by the encryption type. [36] The + ordering of the fields in the CipherText is important. Additionally, + messages encoded in this format must include a length as part of the + msg-seq field. This allows the recipient to verify that the message + has not been truncated. Without a length, an attacker could use a + chosen plaintext attack to generate a message which could be + truncated, while leaving the checksum intact. Note that if the msg-seq + is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length + is part of that encoding. + + [37] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [38] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [39] A variant of the key is used to limit the use of a key to a + particular function, separating the functions of generating a checksum + from other encryption performed using the session key. The constant + F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The + properties of DES precluded the use of the complement. The same + constant is used for similar purpose in the Message Integrity Check in + the Privacy Enhanced Mail standard. + + [40] This error carries additional information in the e- data field. + The contents of the e-data field for this message is described in + section 5.9.1. + + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt new file mode 100644 index 0000000..6f7dae0d --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt @@ -0,0 +1,325 @@ + +INTERNET-DRAFT Mike Swift +draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft +March 2000 Jonathan Trostle + Cisco Systems + John Brezak + Microsoft + Bill Gossman + Cybersafe + + Kerberos Set/Change Password: Version 2 + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), + does not allow for an administrator to set a password for a new user. + This functionality is useful in some environments, and this proposal + extends [4] to allow password setting. The changes are: adding new + fields to the request message to indicate the principal which is + having its password set, not requiring the initial flag in the service + ticket, using a new protocol version number, and adding three new + result codes. We also extend the set/change protocol to allow a + client to send a sequence of keys to the KDC instead of a cleartext + password. If in the cleartext password case, the cleartext password + fails to satisfy password policy, the server should use the result + code KRB5_KPASSWD_POLICY_REJECT. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + requirement is consistent with the TCP transport header in 1510bis. + +Request Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP-REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [3]) The AP-REQ message must be for the service + principal kadmin/changepw@REALM, where REALM is the REALM of the user + who wishes to change/set his password. The ticket in the AP-REQ must + must include a subkey in the Authenticator. To enable setting of + passwords/keys, it is not required that the initial flag be set in the + Kerberos service ticket. The initial flag is required for change requests, + but not for set password requests. We have the following definitions: + + old passwd initial flag target principal can be + in request? required? distinct from + authenticating principal? + + change password: yes yes no + + set password: no no yes + + set key: no policy yes + determined + + KRB-PRIV message (see [3]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData :: = SEQUENCE { + newpasswdorkeys[0] NewPasswdOrKeys, + targname[1] PrincipalName OPTIONAL, + -- only present in set password: the principal + -- which will have its password set + targrealm[2] Realm OPTIONAL, + -- only present in set password: the realm for + -- the principal which will have its password set + + } + + NewPasswdOrKeys :: = CHOICE { + passwords[0] PasswordSequence, + keyseq[1] KeySequences + } + + KeySequences :: = SEQUENCE OF KeySequence + + KeySequence :: = SEQUENCE { + key[0] EncryptionKey, + salt[1] OCTET STRING OPTIONAL, + salt-type[2] INTEGER OPTIONAL + } + + PasswordSequence :: = SEQUENCE { + newpasswd[0] OCTET STRING, + oldpasswd[1] OCTET STRING OPTIONAL + -- oldpasswd always present for change password + -- but not present for set password + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set or change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password/keys. The server + also checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswdorkeys field contains either the new cleartext password + (with the old cleartext password for a change password operation), + or a sequence of encryption keys with their respective salts. + + In the cleartext password case, if the old password is sent in the + request, the request is defined to be a change password request. If + the old password is not present in the request, the request is a set + password request. The server should apply policy checks to the old + and new password after verifying that the old password is valid. + The server can check validity by obtaining a key from the old + password with a keytype that is present in the KDC database for the + user and comparing the keys for equality. The server then generates + the appropriate keytypes from the password and stores them in the KDC + + database. If all goes well, status 0x0000 is returned to the client + in the reply message (see below). For a change password operation, + the initial flag in the service ticket MUST be set. + + In the key sequence case, the sequence of keys is sent to the set + password service. For a principal that can act as a server, its + preferred keytype should be sent as the first key in the sequence, + but the KDC is not required to honor this preference. Application + servers should use the key sequence option for changing/setting their + keys. The set password service should check that all keys are in the + proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. + +Reply Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). (The reply message has the same format as in [4]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [4]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + validate the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | edata / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [4]): + The result code must have one of the following values (network + byte order): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; + the result string should include a text message to be presented + to the user. + KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist + (only in response to a set password request). + KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence + containing at least one etype that is not supported by the KDC. + The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO + type that specifies the etypes that the KDC supports: + + KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { + encryption-type[0] INTEGER, + salt[1] OCTET STRING OPTIONAL -- not sent + } + + PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY + + The client should retry the request using only etypes (keytypes) + that are contained within the PKERB-ETYPE-INFO structure in the + previous response. + 0xFFFF if the request fails for some other reason. + The client must interpret any non-zero result code as a failure. + result string - from [4]: + This field is a UTF-8 encoded string which should be displayed + to the user by the client. Specific reasons for a password + set/change policy failure is one use for this string. + edata: used to convey additional information as defined by the + result code. + +4. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5), Request for Comments 1510. + + [4] M. Horowitz. Kerberos Change Password Protocol, + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +5. Expiration Date + + This draft expires in September 2000. + +6. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + Email: mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + Email: jbrezak@microsoft.com + + Bill Gossman + Cybersafe Corporation + 1605 NW Sammamish Rd. + Issaquah, WA 98027-5378 + Email: bill.gossman@cybersafe.com + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt new file mode 100644 index 0000000..0319f8b --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt @@ -0,0 +1,345 @@ + +INTERNET-DRAFT Mike Swift +draft-ietf-cat-kerberos-set-passwd-03.txt Microsoft +April 2000 Jonathan Trostle + Cisco Systems + John Brezak + Microsoft + Bill Gossman + Cybersafe + + Kerberos Set/Change Password: Version 2 + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), + does not allow for an administrator to set a password for a new user. + This functionality is useful in some environments, and this proposal + extends [4] to allow password setting. The changes are: adding new + fields to the request message to indicate the principal which is + having its password set, not requiring the initial flag in the service + ticket, using a new protocol version number, and adding three new + result codes. We also extend the set/change protocol to allow a + client to send a sequence of keys to the KDC instead of a cleartext + password. If in the cleartext password case, the cleartext password + fails to satisfy password policy, the server should use the result + code KRB5_KPASSWD_POLICY_REJECT. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + requirement is consistent with the TCP transport header in 1510bis. + +Request Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP-REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [3]) For a change password/key request, the AP-REQ + message service ticket sname, srealm principal identifier is + kadmin/changepw@REALM where REALM is the realm of the change password + service. The same applies to a set password/key request except the + principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ + must include a subkey in the Authenticator. To enable setting of + passwords/keys, it is not required that the initial flag be set in the + Kerberos service ticket. The initial flag is required for change requests, + but not for set requests. We have the following definitions: + + old passwd initial flag target principal can be + in request? required? distinct from + authenticating principal? + + change password: yes yes no + + set password: no policy (*) yes + + set key: no policy (*) yes + + change key: no yes no + + policy (*): implementations SHOULD allow administrators to set the + initial flag required for set requests policy to either yes or no. + Clients MUST be able to retry set requests that fail due to error 7 + (initial flag required) with an initial ticket. Clients SHOULD NOT + cache service tickets targetted at kadmin/changepw. + + KRB-PRIV message (see [3]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData :: = SEQUENCE { + newpasswdorkeys[0] NewPasswdOrKeys, + targname[1] PrincipalName OPTIONAL, + -- only present in set password/key: the principal + -- which will have its password or keys set. Not + -- present in a set request if the client principal + -- from the ticket is the principal having its + -- passwords or keys set. + targrealm[2] Realm OPTIONAL, + -- only present in set password/key: the realm for + -- the principal which will have its password or + -- keys set. Not present in a set request if the + -- client principal from the ticket is the principal + -- having its passwords or keys set. + } + + NewPasswdOrKeys :: = CHOICE { + passwords[0] PasswordSequence, -- change/set passwd + keyseq[1] KeySequences -- change/set key + } + + KeySequences :: = SEQUENCE OF KeySequence + + KeySequence :: = SEQUENCE { + key[0] EncryptionKey, + salt[1] OCTET STRING OPTIONAL, + salt-type[2] INTEGER OPTIONAL + } + + PasswordSequence :: = SEQUENCE { + newpasswd[0] OCTET STRING, + oldpasswd[1] OCTET STRING OPTIONAL + -- oldpasswd always present for change password + -- but not present for set password, set key, or + -- change key + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set or change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password/keys. The server + also checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswdorkeys field contains either the new cleartext password + (with the old cleartext password for a change password operation), + or a sequence of encryption keys with their respective salts. + + In the cleartext password case, if the old password is sent in the + request, the request MUST be a change password request. If the old + password is not present in the request, the request MUST be a set + password request. The server should apply policy checks to the old + and new password after verifying that the old password is valid. + The server can check validity by obtaining a key from the old + password with a keytype that is present in the KDC database for the + user and comparing the keys for equality. The server then generates + the appropriate keytypes from the password and stores them in the KDC + database. If all goes well, status 0x0000 is returned to the client + in the reply message (see below). For a change password operation, + the initial flag in the service ticket MUST be set. + + In the key sequence case, the sequence of keys is sent to the change + or set password service (kadmin/changepw or kadmin/setpw respectively). + For a principal that can act as a server, its preferred keytype should + be sent as the first key in the sequence, but the KDC is not required + to honor this preference. Application servers should use the key + sequence option for changing/setting their keys. The change/set password + services should check that all keys are in the proper format, returning + the KRB5_KPASSWD_MALFORMED error otherwise. + +Reply Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). (The reply message has the same format as in [4]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [4]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + validate the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | edata / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [4]): + The result code must have one of the following values (network + byte order): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; + the result string should include a text message to be presented + to the user. + KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist + (only in response to a set password request). + KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence + containing at least one etype that is not supported by the KDC. + The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO + type that specifies the etypes that the KDC supports: + + KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { + encryption-type[0] INTEGER, + salt[1] OCTET STRING OPTIONAL -- not sent + } + + PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY + + The client should retry the request using only etypes (keytypes) + that are contained within the PKERB-ETYPE-INFO structure in the + previous response. + 0xFFFF if the request fails for some other reason. + The client must interpret any non-zero result code as a failure. + result string - from [4]: + This field is a UTF-8 encoded string which should be displayed + to the user by the client. Specific reasons for a password + + set/change policy failure is one use for this string. + edata: used to convey additional information as defined by the + result code. + +4. Acknowledgements + + The authors thank Tony Andrea for his input to the document. + +5. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5), Request for Comments 1510. + + [4] M. Horowitz. Kerberos Change Password Protocol, + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +6. Expiration Date + + This draft expires in October 2000. + +7. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + Email: mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + Email: jbrezak@microsoft.com + + Bill Gossman + Cybersafe Corporation + 1605 NW Sammamish Rd. + Issaquah, WA 98027-5378 + Email: bill.gossman@cybersafe.com + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt new file mode 100644 index 0000000..bd31750 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt @@ -0,0 +1,339 @@ + + + + + + +INTERNET-DRAFT Ken Hornstein +<draft-ietf-cat-krb-dns-locate-02.txt> NRL +March 10, 2000 Jeffrey Altman +Expires: September 10, 2000 Columbia University + + + + Distributing Kerberos KDC and Realm Information with DNS + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Distribution of this memo is unlimited. It is filed as <draft-ietf- + cat-krb-dns-locate-02.txt>, and expires on September 10, 2000. Please + send comments to the authors. + +Abstract + + Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- + col [RFC????] describe any mechanism for clients to learn critical + configuration information necessary for proper operation of the pro- + tocol. Such information includes the location of Kerberos key dis- + tribution centers or a mapping between DNS domains and Kerberos + realms. + + Current Kerberos implementations generally store such configuration + information in a file on each client machine. Experience has shown + this method of storing configuration information presents problems + with out-of-date information and scaling problems, especially when + + + +Hornstein, Altman [Page 1] + +RFC DRAFT March 10, 2000 + + + using cross-realm authentication. + + This memo describes a method for using the Domain Name System + [RFC1035] for storing such configuration information. Specifically, + methods for storing KDC location and hostname/domain name to realm + mapping information are discussed. + +DNS vs. Kerberos - Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. While it is strongly + encouraged that all realm names be all upper case this recommendation + has not been adopted by all sites. Some sites use all lower case + names and other use mixed case. DNS on the other hand is case insen- + sitive for queries but is case preserving for responses to TXT + queries. Since "MYREALM", "myrealm", and "MyRealm" are all different + it is necessary that the DNS entries be distinguishable. + + Since the recommend realm names are all upper case, we will not + require any quoting to be applied to upper case names. If the realm + name contains lower case characters each character is to be quoted by + a '=' character. So "MyRealm" would be represented as "M=yR=e=a=l=m" + and "myrealm" as "=m=y=r=e=a=l=m". If the realm name contains the + '=' character it will be represented as "==". + + +Overview - KDC location information + + KDC location information is to be stored using the DNS SRV RR [RFC + 2052]. The format of this RR is as follows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for Kerberos is always "_kerberos". + + The Proto can be either "_udp" or "_tcp". If these records are to be + used, a "_udp" record MUST be included. If the Kerberos implementa- + tion supports TCP transport, a "_tcp" record SHOULD be included. + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + +Example - KDC location information + + These are DNS records for a Kerberos realm ASDF.COM. It has two Ker- + beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be + directed to kdc1.asdf.com first as per the specified priority. + + + +Hornstein, Altman [Page 2] + +RFC DRAFT March 10, 2000 + + + Weights are not used in these records. + + _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. + _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. + +Overview - Kerberos password changing server location information + + Kerberos password changing server [KERB-CHG] location is to be stored + using the DNS SRV RR [RFC 2052]. The format of this RR is as fol- + lows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for the password server is always "_kpasswd". + + The Proto MUST be "_udp". + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + +Overview - Kerberos admin server location information + + Kerberos admin location information is to be stored using the DNS SRV + RR [RFC 2052]. The format of this RR is as follows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for the admin server is always "_kerberos-adm". + + The Proto can be either "_udp" or "_tcp". If these records are to be + used, a "_tcp" record MUST be included. If the Kerberos admin imple- + mentation supports UDP transport, a "_udp" record SHOULD be included. + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + + Note that there is no formal definition of a Kerberos admin protocol, + so the use of this record is optional and implementation-dependent. + +Example - Kerberos administrative server location information + + These are DNS records for a Kerberos realm ASDF.COM. It has one + administrative server, kdc1.asdf.com. + + + + +Hornstein, Altman [Page 3] + +RFC DRAFT March 10, 2000 + + + _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. + +Overview - Hostname/domain name to Kerberos realm mapping + + Information on the mapping of DNS hostnames and domain names to Ker- + beros realms is stored using DNS TXT records [RFC 1035]. These + records have the following format. + + Service.Name TTL Class TXT Realm + + The Service field is always "_kerberos", and prefixes all entries of + this type. + + The Name is a DNS hostname or domain name. This is explained in + greater detail below. + + TTL, Class, and TXT have the standard DNS meaning as defined in RFC + 1035. + + The Realm is the data for the TXT RR, and consists simply of the Ker- + beros realm that corresponds to the Name specified. + + When a Kerberos client wishes to utilize a host-specific service, it + will perform a DNS TXT query, using the hostname in the Name field of + the DNS query. If the record is not found, the first label of the + name is stripped and the query is retried. + + Compliant implementations MUST query the full hostname and the most + specific domain name (the hostname with the first label removed). + Compliant implementations SHOULD try stripping all subsequent labels + until a match is found or the Name field is empty. + +Example - Hostname/domain name to Kerberos realm mapping + + For the previously mentioned ASDF.COM realm and domain, some sample + records might be as follows: + + _kerberos.asdf.com. IN TXT "ASDF.COM" + _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM" + _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM" + + Let us suppose that in this case, a Kerberos client wishes to use a + Kerberized service on the host foo.asdf.com. It would first query: + + _kerberos.foo.asdf.com. IN TXT + + Finding no match, it would then query: + + + + +Hornstein, Altman [Page 4] + +RFC DRAFT March 10, 2000 + + + _kerberos.asdf.com. IN TXT + + And find an answer of ASDF.COM. This would be the realm that + foo.asdf.com resides in. + + If another Kerberos client wishes to use a Kerberized service on the + host salesserver.asdf.com, it would query: + + _kerberos.salesserver.asdf.com IN TXT + + And find an answer of SALES.ASDF.COM. + +Security considerations + + As DNS is deployed today, it is an unsecure service. Thus the infor- + mation returned by it cannot be trusted. + + Current practice for REALM to KDC mapping is to use hostnames to + indicate KDC hosts (stored in some implementation-dependent location, + but generally a local config file). These hostnames are vulnerable + to the standard set of DNS attacks (denial of service, spoofed + entries, etc). The design of the Kerberos protocol limits attacks of + this sort to denial of service. However, the use of SRV records does + not change this attack in any way. They have the same vulnerabili- + ties that already exist in the common practice of using hostnames for + KDC locations. + + Current practice for HOSTNAME to REALM mapping is to provide a local + configuration of mappings of hostname or domain name to realm which + are then mapped to KDCs. But this again is vulnerable to spoofing + via CNAME records that point to hosts in other domains. This has the + same effect as when a TXT record is spoofed. In a realm with no + cross-realm trusts this is a DoS attack. However, when cross-realm + trusts are used it is possible to redirect a client to use a comprom- + ised realm. + + This is not an exploit of the Kerberos protocol but of the Kerberos + trust model. The same can be done to any application that must + resolve the hostname in order to determine which domain a non-FQDN + belongs to. + + Implementations SHOULD provide a way of specifying this information + locally without the use of DNS. However, to make this feature + worthwhile a lack of any configuration information on a client should + be interpretted as permission to use DNS. + + + + + + +Hornstein, Altman [Page 5] + +RFC DRAFT March 10, 2000 + + +Expiration + + This Internet-Draft expires on September 10, 2000. + +References + + + [RFC1510] + The Kerberos Network Authentication System; Kohl, Newman; Sep- + tember 1993. + + [RFC1035] + Domain Names - Implementation and Specification; Mockapetris; + November 1987 + + [RFC2782] + A DNS RR for specifying the location of services (DNS SRV); Gul- + brandsen, Vixie; Feburary 2000 + + [KERB-CHG] + Kerberos Change Password Protocol; Horowitz; + ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg- + password-02.txt + +Authors' Addresses + + Ken Hornstein + US Naval Research Laboratory + Bldg A-49, Room 2 + 4555 Overlook Avenue + Washington DC 20375 USA + + Phone: +1 (202) 404-4765 + EMail: kenh@cmf.nrl.navy.mil + + Jeffrey Altman + The Kermit Project + Columbia University + 612 West 115th Street #716 + New York NY 10025-7799 USA + + Phone: +1 (212) 854-1344 + EMail: jaltman@columbia.edu + + + + + + + + +Hornstein, Altman [Page 6] + diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt new file mode 100644 index 0000000..11e5dc9 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt @@ -0,0 +1,1333 @@ + +INTERNET-DRAFT Tom Yu +Common Authentication Technology WG MIT +draft-ietf-cat-krb5gss-mech2-03.txt 04 March 2000 + + The Kerberos Version 5 GSSAPI Mechanism, Version 2 + +Status of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments on this document should be sent to + "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication + Technology WG discussion list. + +Abstract + + This document defines protocols, procedures, and conventions to be + employed by peers implementing the Generic Security Service + Application Program Interface (as specified in RFC 2743) when using + Kerberos Version 5 technology (as specified in RFC 1510). This + obsoletes RFC 1964. + +Acknowledgements + + Much of the material in this specification is based on work done for + Cygnus Solutions by Marc Horowitz. + +Table of Contents + + Status of This Memo ............................................ 1 + Abstract ....................................................... 1 + Acknowledgements ............................................... 1 + Table of Contents .............................................. 1 + 1. Introduction ............................................... 3 + 2. Token Formats .............................................. 3 + 2.1. Packet Notation ....................................... 3 + +Yu Document Expiration: 04 Sep 2000 [Page 1] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + 2.2. Mechanism OID ......................................... 4 + 2.3. Context Establishment ................................. 4 + 2.3.1. Option Format .................................... 4 + 2.3.1.1. Delegated Credentials Option ................ 5 + 2.3.1.2. Null Option ................................. 5 + 2.3.2. Initial Token .................................... 6 + 2.3.2.1. Data to be Checksummed in APREQ ............. 8 + 2.3.3. Response Token ................................... 10 + 2.4. Per-message Tokens .................................... 12 + 2.4.1. Sequence Number Usage ............................ 12 + 2.4.2. MIC Token ........................................ 12 + 2.4.2.1. Data to be Checksummed in MIC Token ......... 13 + 2.4.3. Wrap Token ....................................... 14 + 2.4.3.1. Wrap Token With Integrity Only .............. 14 + 2.4.3.2. Wrap Token With Integrity and Encryption + ............................................. 15 + 2.4.3.2.1. Data to be Encrypted in Wrap Token ..... 16 + 3. ASN.1 Encoding of Octet Strings ............................ 17 + 4. Name Types ................................................. 18 + 4.1. Mandatory Name Forms .................................. 18 + 4.1.1. Kerberos Principal Name Form ..................... 18 + 4.1.2. Exported Name Object Form for Kerberos5 + Mechanism ........................................ 19 + 5. Credentials ................................................ 20 + 6. Parameter Definitions ...................................... 20 + 6.1. Minor Status Codes .................................... 20 + 6.1.1. Non-Kerberos-specific codes ...................... 21 + 6.1.2. Kerberos-specific-codes .......................... 21 + 7. Kerberos Protocol Dependencies ............................. 22 + 8. Security Considerations .................................... 22 + 9. References ................................................. 22 + 10. Author's Address .......................................... 23 + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 2] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +1. Introduction + + The original Kerberos 5 GSSAPI mechanism[RFC1964] has a number of + shortcomings. This document attempts to remedy them by defining a + completely new Kerberos 5 GSSAPI mechanism. + + The context establishment token format requires that the + authenticator of AP-REQ messages contain a cleartext data structure + in its checksum field, which is a needless and potentially confusing + overloading of that field. This is implemented by a special checksum + algorithm whose purpose is to copy the input data directly into the + checksum field of the authenticator. + + The number assignments for checksum algorithms and for encryption + types are inconsistent between the Kerberos protocol and the original + GSSAPI mechanism. If new encryption or checksum algorithms are added + to the Kerberos protocol at some point, the GSSAPI mechanism will + need to be separately updated to use these new algorithms. + + The original mechanism specifies a crude method of key derivation (by + using the XOR of the context key with a fixed constant), which is + incompatible with newer cryptosystems which specify key derivation + procedures themselves. The original mechanism also assumes that both + checksums and cryptosystem blocksizes are eight bytes. + + Defining all GSSAPI tokens for the new Kerberos 5 mechanism in terms + of the Kerberos protocol specification ensures that new encryption + types and checksum types may be automatically used as they are + defined for the Kerberos protocol. + +2. Token Formats + + All tokens, not just the initial token, are framed as the + InitialContextToken described in RFC 2743 section 3.1. The + innerContextToken element of the token will not itself be encoded in + ASN.1, with the exception of caller-provided application data. + + One rationale for avoiding the use of ASN.1 in the inner token is + that some implementors may wish to implement this mechanism in a + kernel or other similarly constrained application where handling of + full ASN.1 encoding may be cumbersome. Also, due to the poor + availability of the relevant standards documents, ASN.1 encoders and + decoders are difficult to implement completely correctly, so keeping + ASN.1 usage to a minimum decreases the probability of bugs in the + implementation of the mechanism. In particular, bit strings need to + be transferred at certain points in this mechanism. There are many + conflicting common misunderstandings of how to encode and decode + ASN.1 bit strings, which have led difficulties in the implementaion + of the Kerberos protocol. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 3] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.1. Packet Notation + + The order of transmission of this protocol is described at the octet + level. Packet diagrams depict bits in the order of transmission, + assuming that individual octets are transmitted with the most + significant bit (MSB) first. The diagrams read from left to right + and from top to bottom, as in printed English. In each octet, bit + number 7 is the MSB and bit number 0 is the LSB. + + Numbers prefixed by the characters "0x" are in hexadecimal notation, + as in the C programming language. Even though packet diagrams are + drawn 16 bits wide, no padding should be used to align the ends of + variable-length fields to a 32-bit or 16-bit boundary. + + All integer fields are in network byte order. All other fields have + the size shown in the diagrams, with the exception of variable length + fields. + +2.2. Mechanism OID + + The Object Identifier (OID) of the new krb5 v2 mechanism is: + + {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2) + krb5v2(3)} + + +2.3. Context Establishment + +2.3.1. Option Format + + Context establishment tokens, i.e., the initial ones that the + GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit + while a security context is being set up, may contain options that + influence the subsequent behavior of the context. This document + describes only a small set of options, but additional types may be + added by documents intended to supplement this one. The generic + format is as follows: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type | + +-------------------------------+-------------------------------+ + 2 | | + +-- option length (32 bits) --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / option data (variable length) / + | . | + +-------------------------------+-------------------------------+ + + + + +Yu Document Expiration: 04 Sep 2000 [Page 4] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + option type (16 bits) + The type identifier of the following option. + + option length (32 bits) + The length in bytes of the following option. + + option data (variable length) + The actual option data. + + Any number of options may appear in an initator or acceptor token. + The final option in a token must be the null option, in order to mark + the end of the list. Option type 0xffff is reserved. + + The initiator and acceptor shall ignore any options that they do not + understand. + +2.3.1.1. Delegated Credentials Option + + Only the initiator may use this option. The format of the delegated + credentials option is as follows: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type = 0x00001 | + +-------------------------------+-------------------------------+ + 2 | | + +-- KRB-CRED length --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / KRB-CRED message / + | . | + +-------------------------------+-------------------------------+ + + + option type (16 bits) + The option type for this option shall be 0x0001. + + KRB-CRED length (32 bits) + The length in bytes of the following KRB-CRED message. + + KRB-CRED message (variable length) + The option data for this option shall be the KRB-CRED message + that contains the credentials being delegated (forwarded) to the + context acceptor. Only the initiator may use this option. + +2.3.1.2. Null Option + + The Null option terminates the option list, and must be used by both + the initiator and the acceptor. Its format is as follows: + + + + +Yu Document Expiration: 04 Sep 2000 [Page 5] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type = 0 | + +-------------------------------+-------------------------------+ + 2 | | + +-- length = 0 --+ + 4 | | + +-------------------------------+-------------------------------+ + + + option type (16 bits) + The option type of this option must be zero. + + option length (32 bits) + The length of this option must be zero. + +2.3.2. Initial Token + + This is the initial token sent by the context initiator, generated by + GSS_Init_sec_context(). + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | initial token id = 0x0101 | + +-------------------------------+-------------------------------+ + 2 | | + +-- reserved flag bits +-----------------------+ + 4 | | I | C | S | R | M | D | + +-------------------------------+-------------------------------+ + 6 | checksum type count | + +-------------------------------+-------------------------------+ + 8 | . | + / checksum type list / + | . | + +-------------------------------+-------------------------------+ + n | . | + / options / + | . | + +-------------------------------+-------------------------------+ + m | | + +-- AP-REQ length --+ + m+2 | | + +-------------------------------+-------------------------------+ + m+4 | . | + / AP-REQ data / + | . | + +-------------------------------+-------------------------------+ + + + initial token ID (16 bits) + Contains the integer 0x0101, which identifies this as the + initial token in the context setup. + + +Yu Document Expiration: 04 Sep 2000 [Page 6] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + reserved flag bits (26 bits) + These bits are reserved for future expansion. They must be set + to zero by the initiator and be ignored by the acceptor. + + I flag (1 bit) + 0x00000020 -- GSS_C_INTEG_FLAG + + C flag (1 bit) + 0x00000010 -- GSS_C_CONF_FLAG + + S flag (1 bit) + 0x00000008 -- GSS_C_SEQUENCE_FLAG + + R flag (1 bit) + 0x00000004 -- GSS_C_REPLAY_FLAG + + M flag (1 bit) + 0x00000002 -- GSS_C_MUTUAL_FLAG + + D flag (1 bit) + 0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the + "delegated credentials" option is included. + + checksum type count (16 bits) + The number of checksum types supported by the initiator. + + checksum type list (variable length) + A list of Kerberos checksum types, as defined in RFC 1510 + section 6.4. These checksum types must be collision-proof and + keyed with the context key; no checksum types that are + incompatible with the encryption key shall be used. Each + checksum type number shall be 32 bits wide. This list should + contain all the checksum types supported by the initiator. If + mutual authentication is not used, then this list shall contain + only one checksum type. + + options (variable length) + The context initiation options, described in section 2.3.1. + + AP-REQ length (32 bits) + The length of the following KRB_AP_REQ message. + + AP-REQ data (variable length) + The AP-REQ message as described in RFC 1510. The checksum in + the authenticator will be computed over the items listed in the + next section. + + The optional sequence number field shall be used in the AP-REQ. The + initiator should generate a subkey in the authenticator, and the + acceptor should generate a subkey in the AP-REP. The key used for + the per-message tokens will be the AP-REP subkey, or if that is not + present, the authenticator subkey, or if that is not present, the + session key. When subkeys are generated, it is strongly recommended + +Yu Document Expiration: 04 Sep 2000 [Page 7] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + that they be of the same type as the associated session key. + + XXX The above is not secure. There should be an algorithmic process + to arrive at a subsession key which both sides of the authentication + exchange can perform based on the ticket sessions key and data known + to both parties, and this should probably be part of the revised + Kerberos protocol rather than bound to the GSSAPI mechanism. + +2.3.2.1. Data to be Checksummed in AP-REQ + + The checksum in the AP-REQ message is calculated over the following + items. Like in the actual tokens, no padding should be added to + force integer fields to align on 32 bit boundaries. This particular + set of data should not be sent as a part of any token; it merely + specifies what is to be checksummed in the AP-REQ. The items in this + encoding that precede the initial token ID correspond to the channel + bindings passed to GSS_Init_sec_context(). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 8] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | | + +-- initiator address type --+ + 2 | | + +-------------------------------+-------------------------------+ + 4 | initiator address length | + +-------------------------------+-------------------------------+ + 6 | . | + / initiator address / + | . | + +-------------------------------+-------------------------------+ + n | | + +-- acceptor address type --+ + | | + +-------------------------------+-------------------------------+ + n+4 | acceptor address length | + +-------------------------------+-------------------------------+ + n+6 | . | + / acceptor address / + | . | + +-------------------------------+-------------------------------+ + m | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + k | initial token id = 0x0101 | + +-------------------------------+-------------------------------+ + k+2 | | + +-- flags --+ + k+4 | | + +-------------------------------+-------------------------------+ + k+6 | checksum type count | + +-------------------------------+-------------------------------+ + k+8 | . | + / checksum type list / + | . | + +-------------------------------+-------------------------------+ + j | . | + / options / + | . | + +-------------------------------+-------------------------------+ + + + initiator address type (32 bits) + The initiator address type, as defined in the Kerberos protocol + specification. If no initiator address is provided, this must + be zero. + + initiator address length (16 bits) + The length in bytes of the following initiator address. If + there is no inititator address provided, this must be zero. + + +Yu Document Expiration: 04 Sep 2000 [Page 9] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + initiator address (variable length) + The actual initiator address, in network byte order. + + acceptor address type (32 bits) + The acceptor address type, as defined in the Kerberos protocol + specification. If no acceptor address is provided, this must be + zero. + + acceptor address length (16 bits) + The length in bytes of the following acceptor address. This + must be zero is there is no acceptor address provided. + + initiator address (variable length) + The actual acceptor address, in network byte order. + + applicatation data (variable length) + The application data, if provided, encoded as a ASN.1 octet + string using DER. If no application data are passed as input + channel bindings, this shall be a zero-length ASN.1 octet + string. + + initial token ID (16 bits) + The initial token ID from the initial token. + + flags (32 bits) + The context establishment flags from the initial token. + + checksum type count (16 bits) + The number of checksum types supported by the initiator. + + checksum type list (variable length) + The same list of checksum types contained in the initial token. + + options (variable length) + The options list from the initial token. + +2.3.3. Response Token + + This is the reponse token sent by the context acceptor, if mutual + authentication is enabled. + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 10] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | response token id = 0x0202 | + +-------------------------------+-------------------------------+ + 2 | | + +-- reserved flag bits +-------+ + 4 | | D | E | + +-------------------------------+-------------------------------+ + 6 | | + +-- checksum type --+ + 8 | | + +-------------------------------+-------------------------------+ + 10 | . | + / options / + | . | + +-------------------------------+-------------------------------+ + n | | + +-- AP-REP or KRB-ERROR length --+ + n+2 | | + +-------------------------------+-------------------------------+ + n+4 | . | + / AP-REP or KRB-ERROR data / + | . | + +-------------------------------+-------------------------------+ + m | . | + / MIC data / + | . | + +-------------------------------+-------------------------------+ + + + response token id (16 bits) + Contains the integer 0x0202, which identifies this as the + response token in the context setup. + + reserved flag bits (30 bits) + These bits are reserved for future expansion. They must be set + to zero by the acceptor and be ignored by the initiator. + + D flag -- delegated creds accepted (1 bit) + 0x00000002 -- If this flag is set, the acceptor processed the + delegated credentials, and GSS_C_DELEG_FLAG should be returned + to the caller. + + E flag -- error (1 bit) + 0x00000001 -- If this flag is set, a KRB-ERROR message shall be + present, rather than an AP-REP message. If this flag is not + set, an AP-REP message shall be present. + + checksum type count (16 bits) + The number of checksum types supported by both the initiator and + the acceptor. + + + +Yu Document Expiration: 04 Sep 2000 [Page 11] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + checksum type (32 bits) + A Kerberos checksum type, as defined in RFC 1510 section 6.4. + This checksum type must be among the types listed by the + initiator, and will be used in for subsequent checksums + generated during this security context. + + options (variable length) + The option list, as described earlier. At this time, no options + are defined for the acceptor, but an implementation might make + use of these options to acknowledge an option from the initial + token. After all the options are specified, a null option must + be used to terminate the list. + + AP-REP or KRB-ERROR length (32 bits) + Depending on the value of the error flag, length in bytes of the + AP-REP or KRB-ERROR message. + + AP-REP or KRB-ERROR data (variable length) + Depending on the value of the error flag, the AP-REP or + KRB-ERROR message as described in RFC 1510. If this field + contains an AP-REP message, the sequence number field in the + AP-REP shall be filled. If this is a KRB-ERROR message, no + further fields will be in this message. + + MIC data (variable length) + A MIC token, as described in section 2.4.2, computed over the + concatentation of the response token ID, flags, checksum length + and type fields, and all option fields. This field and the + preceding length field must not be present if the error flag is + set. + +2.4. Per-message Tokens + +2.4.1. Sequence Number Usage + + Sequence numbers for per-message tokens are 31 bit unsigned integers, + which are incremented by 1 after each token. An overflow condition + should result in a wraparound of the sequence number to zero. The + initiator and acceptor each keep their own sequence numbers per + connection. + + The intial sequence number for tokens sent from the initiator to the + acceptor shall be the least significant 31 bits of sequence number in + the AP-REQ message. The initial sequence number for tokens sent from + the acceptor to the initiator shall be the least significant 31 bits + of the sequence number in the AP-REP message if mutual authentication + is used; if mutual authentication is not used, the initial sequence + number from acceptor to initiator shall be the least significant 31 + bits of the sequence number in the AP-REQ message. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 12] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.2. MIC Token + + Use of the GSS_GetMIC() call yields a token, separate from the user + data being protected, which can be used to verify the integrity of + that data when it is received. The MIC token has the following + format: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | MIC token id = 0x0303 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | checksum length | + +-------------------------------+-------------------------------+ + 8 | . | + / checksum data / + | . | + +-------------------------------+-------------------------------+ + + + MIC token id (16 bits) + Contains the integer 0x0303, which identifies this as a MIC + token. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + checksum length (16 bits) + The number of bytes in the following checksum data field. + + checksum data (variable length) + The checksum itself, as defined in RFC 1510 section 6.4. The + checksum is calculated over the encoding described in the + following section. The key usage GSS_TOK_MIC -- 22 [XXX need to + register this] shall be used in cryptosystems that support key + derivation. + + The mechanism implementation shall only use the checksum type + returned by the acceptor in the case of mutual authentication. If + mutual authentication is not requested, then only the checksum type + in the initiator token shall be used. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 13] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.2.1. Data to be Checksummed in MIC Token + + The checksum in the MIC token shall be calculated over the following + elements. This set of data is not actually included in the token as + is; the description only appears for the purpose of specifying the + method of calculating the checksum. + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | MIC token id = 0x0303 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + + + MIC token ID (16 bits) + The MIC token ID from the MIC message. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + using DER. + +2.4.3. Wrap Token + + Use of the GSS_Wrap() call yields a token which encapsulates the + input user data (optionally encrypted) along with associated + integrity check quantities. + +2.4.3.1. Wrap Token With Integrity Only + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 14] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | integrity wrap token id = 0x0404 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + n | checksum length | + +-------------------------------+-------------------------------+ + n+2 | . | + / checksum data / + | . | + +-------------------------------+-------------------------------+ + + + integrity wrap token id (16 bits) + Contains the integer 0x0404, which identifies this as a Wrap + token with integrity only. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + using DER. + + checksum length (16 bits) + The number of bytes in the following checksum data field. + + checksum data (variable length) + The checksum itself, as defined in RFC 1510 section 6.4, + computed over the concatenation of the token ID, sequence + number, direction field, application data length, and + application data, as in the MIC token checksum in the previous + section. The key usage GSS_TOK_WRAP_INTEG -- 23 [XXX need to + register this] shall be used in cryptosystems that support key + derivation. + + The mechanism implementation should only use checksum types which it + knows to be valid for both peers, as described for MIC tokens. + + + + +Yu Document Expiration: 04 Sep 2000 [Page 15] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.3.2. Wrap Token With Integrity and Encryption + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + | encrypted wrap token id = 0x0505 | + +-------------------------------+-------------------------------+ + 2 | . | + / encrypted data / + | . | + +-------------------------------+-------------------------------+ + + + encrypted wrap token id (16 bits) + Contains the integer 0x0505, which identifies this as a Wrap + token with integrity and encryption. + + encrypted data (variable length) + The encrypted data itself, as defined in RFC 1510 section 6.3, + encoded as an ASN.1 octet string using DER. Note that this is + not the ASN.1 type EncryptedData as defined in RFC 1510 + section 6.1, but rather the ciphertext without encryption type + or kvno information. The encryption is performed using the + key/enctype exchanged during context setup. The confounder and + checksum are as specified in the Kerberos protocol + specification. The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need + to register this] shall be used in cryptosystems that support + key derivation. The actual data to be encrypted are specified + below. + +2.4.3.2.1. Data to be Encrypted in Wrap Token + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | D | | + +---+ sequence number --+ + 2 | | + +-------------------------------+-------------------------------+ + 4 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + +Yu Document Expiration: 04 Sep 2000 [Page 16] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + using DER. + +3. ASN.1 Encoding of Octet Strings + + In order to encode arbitirarly-sized application data, ASN.1 octet + string encoding is in this protocol. The Distinguished Encoding + Rules (DER) shall always be used in such cases. For reference + purposes, the DER encoding of an ASN.1 octet string, adapted from + ITU-T X.690, follows: + + +--------+-------//-------+-------//-------+ + |00000100| length octets |contents octets | + +--------+-------//-------+-------//-------+ + | + +-- identifier octet = 0x04 = [UNIVERSAL 4] + + + In this section only, the bits in each octet shall be numbered as in + the ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the + octet, and with bit 1 being the LSB of the octet. + + identifier octet (8 bits) + Contains the constant 0x04, the tag for primitive encoding of an + octet string with the default (UNIVERSAL 4) tag. + + length octets (variable length) + Contains the length of the contents octets, in definite form + (since this encoding uses DER). + + contents octets (variable length) + The contents of the octet string. + + The length octets shall consist of either a short form (one byte + only), which is to be used only if the number of octets in the + contents octets is less than or equal to 127, or a long form, which + is to be used in all other cases. The short form shall consist of a + single octet with bit 8 (the MSB) equal to zero, and the remaining + bits encoding the number of contents octets (which may be zero) as an + unsigned binary integer. + + The long form shall consist of an initial octet and one or more + subsequent octets. The first octet shall have bit 8 (the MSB) set to + one, and the remaining bits shall encode the number of subsequent + octets in the length encoding as an unsigned binary integer. The + length must be encoded in the minimum number of octets. An initial + octet of 0xFF is reserved by the ASN.1 specification. Bits 8 to 1 of + the first subsequent octet, followed by bits 8 to 1 of each + subsequent octet in order, shall be the encoding of an unsigned + binary integer, with bit 8 of the first octet being the most + significant bit. Thus, the length encoding within is in network byte + order. + + + +Yu Document Expiration: 04 Sep 2000 [Page 17] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + An initial length octet of 0x80 shall not be used, as that is + reserved by the ASN.1 specification for indefinite lengths in + conjunction with constructed contents encodings, which are not to be + used with DER. + +4. Name Types + + This section discusses the name types which may be passed as input to + the Kerberos 5 GSSAPI mechanism's GSS_Import_name() call, and their + associated identifier values. It defines interface elements in + support of portability, and assumes use of C language bindings per + RFC 2744. In addition to specifying OID values for name type + identifiers, symbolic names are included and recommended to GSSAPI + implementors in the interests of convenience to callers. It is + understood that not all implementations of the Kerberos 5 GSSAPI + mechanism need support all name types in this list, and that + additional name forms will likely be added to this list over time. + Further, the definitions of some or all name types may later migrate + to other, mechanism-independent, specifications. The occurrence of a + name type in this specification is specifically not intended to + suggest that the type may be supported only by an implementation of + the Kerberos 5 mechanism. In particular, the occurrence of the + string "_KRB5_" in the symbolic name strings constitutes a means to + unambiguously register the name strings, avoiding collision with + other documents; it is not meant to limit the name types' usage or + applicability. + + For purposes of clarification to GSSAPI implementors, this section's + discussion of some name forms describes means through which those + forms can be supported with existing Kerberos technology. These + discussions are not intended to preclude alternative implementation + strategies for support of the name forms within Kerberos mechanisms + or mechanisms based on other technologies. To enhance application + portability, implementors of mechanisms are encouraged to support + name forms as defined in this section, even if their mechanisms are + independent of Kerberos 5. + +4.1. Mandatory Name Forms + + This section discusses name forms which are to be supported by all + conformant implementations of the Kerberos 5 GSSAPI mechanism. + +4.1.1. Kerberos Principal Name Form + + This name form shall be represented by the Object Identifier {iso(1) + member-body(2) us(840) mit(113554) infosys(1) gssapi(2) krb5(2) + krb5_name(1)}. The recommended symbolic name for this type is + "GSS_KRB5_NT_PRINCIPAL_NAME". + + This name type corresponds to the single-string representation of a + Kerberos name. (Within the MIT Kerberos 5 implementation, such names + are parseable with the krb5_parse_name() function.) The elements + included within this name representation are as follows, proceeding + +Yu Document Expiration: 04 Sep 2000 [Page 18] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + from the beginning of the string: + + (1) One or more principal name components; if more than one + principal name component is included, the components are + separated by '/'. Arbitrary octets may be included within + principal name components, with the following constraints and + special considerations: + + (1a) Any occurrence of the characters '@' or '/' within a + name component must be immediately preceded by the '\' + quoting character, to prevent interpretation as a component + or realm separator. + + (1b) The ASCII newline, tab, backspace, and null characters + may occur directly within the component or may be + represented, respectively, by '\n', '\t', '\b', or '\0'. + + (1c) If the '\' quoting character occurs outside the contexts + described in (1a) and (1b) above, the following character is + interpreted literally. As a special case, this allows the + doubled representation '\\' to represent a single occurrence + of the quoting character. + + (1d) An occurrence of the '\' quoting character as the last + character of a component is illegal. + + (2) Optionally, a '@' character, signifying that a realm name + immediately follows. If no realm name element is included, the + local realm name is assumed. The '/' , ':', and null characters + may not occur within a realm name; the '@', newline, tab, and + backspace characters may be included using the quoting + conventions described in (1a), (1b), and (1c) above. + +4.1.2. Exported Name Object Form for Kerberos 5 Mechanism + + When generated by the Kerberos 5 mechanism, the Mechanism OID within + the exportable name shall be that of the original Kerberos 5 + mechanism[RFC1964]. The Mechanism OID for the original Kerberos 5 + mechanism is: + + {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2) + krb5(2)} + + The name component within the exportable name shall be a contiguous + string with structure as defined for the Kerberos Principal Name + Form. + + In order to achieve a distinguished encoding for comparison purposes, + the following additional constraints are imposed on the export + operation: + + (1) all occurrences of the characters '@', '/', and '\' within + principal components or realm names shall be quoted with an + +Yu Document Expiration: 04 Sep 2000 [Page 19] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + immediately-preceding '\'. + + (2) all occurrences of the null, backspace, tab, or newline + characters within principal components or realm names will be + represented, respectively, with '\0', '\b', '\t', or '\n'. + + (3) the '\' quoting character shall not be emitted within an + exported name except to accomodate cases (1) and (2). + +5. Credentials + + The Kerberos 5 protocol uses different credentials (in the GSSAPI + sense) for initiating and accepting security contexts. Normal + clients receive a ticket-granting ticket (TGT) and an associated + session key at "login" time; the pair of a TGT and its corresponding + session key forms a credential which is suitable for initiating + security contexts. A ticket-granting ticket, its session key, and + any other (ticket, key) pairs obtained through use of the + ticket-granting-ticket, are typically stored in a Kerberos 5 + credentials cache, sometimes known as a ticket file. + + The encryption key used by the Kerberos server to seal tickets for a + particular application service forms the credentials suitable for + accepting security contexts. These service keys are typically stored + in a Kerberos 5 key table (keytab), or srvtab file (the Kerberos 4 + terminology). In addition to their use as accepting credentials, + these service keys may also be used to obtain initiating credentials + for their service principal. + + The Kerberos 5 mechanism's credential handle may contain references + to either or both types of credentials. It is a local matter how the + Kerberos 5 mechanism implementation finds the appropriate Kerberos 5 + credentials cache or key table. + + However, when the Kerberos 5 mechanism attempts to obtain initiating + credentials for a service principal which are not available in a + credentials cache, and the key for that service principal is + available in a Kerberos 5 key table, the mechanism should use the + service key to obtain initiating credentials for that service. This + should be accomplished by requesting a ticket-granting-ticket from + the Kerberos Key Distribution Center (KDC), and decrypting the KDC's + reply using the service key. + +6. Parameter Definitions + + This section defines parameter values used by the Kerberos V5 GSSAPI + mechanism. It defines interface elements in support of portability, + and assumes use of C language bindings per RFC 2744. + +6.1. Minor Status Codes + + This section recommends common symbolic names for minor_status values + to be returned by the Kerberos 5 GSSAPI mechanism. Use of these + +Yu Document Expiration: 04 Sep 2000 [Page 20] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + definitions will enable independent implementors to enhance + application portability across different implementations of the + mechanism defined in this specification. (In all cases, + implementations of GSS_Display_status() will enable callers to + convert minor_status indicators to text representations.) Each + implementation should make available, through include files or other + means, a facility to translate these symbolic names into the concrete + values which a particular GSSAPI implementation uses to represent the + minor_status values specified in this section. + + It is recognized that this list may grow over time, and that the need + for additional minor_status codes specific to particular + implementations may arise. It is recommended, however, that + implementations should return a minor_status value as defined on a + mechanism-wide basis within this section when that code is accurately + representative of reportable status rather than using a separate, + implementation-defined code. + +6.1.1. Non-Kerberos-specific codes + + These symbols should likely be incorporated into the generic GSSAPI + C-bindings document, since they really are more general. + +GSS_KRB5_S_G_BAD_SERVICE_NAME + /* "No @ in SERVICE-NAME name string" */ +GSS_KRB5_S_G_BAD_STRING_UID + /* "STRING-UID-NAME contains nondigits" */ +GSS_KRB5_S_G_NOUSER + /* "UID does not resolve to username" */ +GSS_KRB5_S_G_VALIDATE_FAILED + /* "Validation error" */ +GSS_KRB5_S_G_BUFFER_ALLOC + /* "Couldn't allocate gss_buffer_t data" */ +GSS_KRB5_S_G_BAD_MSG_CTX + /* "Message context invalid" */ +GSS_KRB5_S_G_WRONG_SIZE + /* "Buffer is the wrong size" */ +GSS_KRB5_S_G_BAD_USAGE + /* "Credential usage type is unknown" */ +GSS_KRB5_S_G_UNKNOWN_QOP + /* "Unknown quality of protection specified" */ + + +6.1.2. Kerberos-specific-codes + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 21] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +GSS_KRB5_S_KG_CCACHE_NOMATCH + /* "Principal in credential cache does not match desired name" */ +GSS_KRB5_S_KG_KEYTAB_NOMATCH + /* "No principal in keytab matches desired name" */ +GSS_KRB5_S_KG_TGT_MISSING + /* "Credential cache has no TGT" */ +GSS_KRB5_S_KG_NO_SUBKEY + /* "Authenticator has no subkey" */ +GSS_KRB5_S_KG_CONTEXT_ESTABLISHED + /* "Context is already fully established" */ +GSS_KRB5_S_KG_BAD_SIGN_TYPE + /* "Unknown signature type in token" */ +GSS_KRB5_S_KG_BAD_LENGTH + /* "Invalid field length in token" */ +GSS_KRB5_S_KG_CTX_INCOMPLETE + /* "Attempt to use incomplete security context" */ + + +7. Kerberos Protocol Dependencies + + This protocol makes several assumptions about the Kerberos protocol, + which may require changes to the successor of RFC 1510. + + Sequence numbers, checksum types, and address types are assumed to be + no wider than 32 bits. The Kerberos protocol specification might + need to be modified to accomodate this. This obviously requires some + further discussion. + + Key usages need to be registered within the Kerberos protocol for use + with GSSAPI per-message tokens. The current specification of the + Kerberos protocol does not include descriptions of key derivations or + key usages, but planned revisions to the protocol will include them. + + This protocol also makes the assumption that any cryptosystem used + with the session key will include integrity protection, i.e., it + assumes that no "raw" cryptosystems will be used. + +8. Security Considerations + + The GSSAPI is a security protocol; therefore, security considerations + are discussed throughout this document. The original Kerberos 5 + GSSAPI mechanism's constraints on possible cryptosystems and checksum + types do not permit it to be readily extended to accomodate more + secure cryptographic technologies with larger checksums or encryption + block sizes. Sites are strongly encouraged to adopt the mechanism + specified in this document in the light of recent publicity about the + deficiencies of DES. + +9. References + + [X.680] ISO/IEC, "Information technology -- Abstract Syntax Notation + One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) | + ISO/IEC 8824-1:1998 + +Yu Document Expiration: 04 Sep 2000 [Page 22] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + [X.690] ISO/IEC, "Information technology -- ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical Encoding Rules + (CER) and Distinguished Encoding Rules (DER)", ITU-T X.690 (1997) | + ISO/IEC 8825-1:1998. + + [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface, Version 2, Update 1", RFC 2743. + + [RFC2744] Wray, J., "Generic Security Service API Version 2: + C-bindings", RFC 2744. + +10. Author's Address + + Tom Yu + Massachusetts Institute of Technology + Room E40-345 + 77 Massachusetts Avenue + Cambridge, MA 02139 + USA + + email: tlyu@mit.edu + phone: +1 617 253 1753 + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 23] + diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt new file mode 100644 index 0000000..24325fd --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt @@ -0,0 +1,281 @@ +CAT Working Group K. Raeburn +Internet-draft MIT +Category: July 14, 2000 +Updates: RFC 1964 +Document: draft-raeburn-cat-gssapi-krb5-3des-00.txt + + Triple-DES Support for the Kerberos 5 GSSAPI Mechanism + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts + are working documents of the Internet Engineering Task Force + (IETF), its areas, and its working groups. Note that other groups + may also distribute working documents as + Internet-Drafts. Internet-Drafts are draft documents valid for a + maximum of six months and may be updated, replaced, or obsoleted by + other documents at any time. It is inappropriate to use + Internet-Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The MIT Kerberos 5 release version 1.2 includes support for + triple-DES with key derivation [KrbRev]. Recent work by the EFF + [EFF] has demonstrated the vulnerability of single-DES mechanisms + to brute-force attacks by sufficiently motivated and well-funded + parties. + + The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] + specifically enumerates encryption and checksum types, + independently of how such schemes may be used in Kerberos. In the + long run, a new Kerberos-based mechanism, which does not require + separately enumerating for the GSSAPI mechanism each of the + encryption types defined by Kerberos, appears to be a better + approach. Efforts to produce such a specification are under way. + + In the interest of providing increased security in the interim, + however, MIT is proposing adding support for triple-DES to the + existing mechanism, as described here. + +2. Conventions Used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC 2119. + +3. New Algorithm Identifiers + + One new sealing algorithm is defined, for use in WRAP tokens: + + 02 00 - DES3-KD + + This algorithm uses triple-DES with key derivation, with a usage + value KG_USAGE_SEAL. Padding is still to 8-byte multiples, and the + IV for encrypting application data is zero. + + One new signing algorithm is defined, for use in MIC, Wrap, and + Delete tokens: + + 04 00 - HMAC SHA1 DES3-KD + + This algorithm generates an HMAC using SHA-1 and a derived DES3 key + with usage KG_USAGE_SIGN, as (ought to be described) in [KrbRev]. + + [XXX: The current [KrbRev] description refers to expired I-Ds from + Marc Horowitz. The text in [KrbRev] may be inadequate to produce + an interoperable implementation.] + + The checksum size for this algorithm is 20 octets. See section 5.3 + below for the use of checksum lengths of other than eight bytes. + +4. Key Derivation + + For purposes of key derivation, we add three new usage values to the + list defined in [KrbRev]; one for signing messages, one for + sealing messages, and one for encrypting sequence numbers: + + #define KG_USAGE_SEAL 22 + #define KG_USAGE_SIGN 23 + #define KG_USAGE_SEQ 24 + +5. Adjustments to Previous Definitions + +5.1. Quality of Protection + + The GSSAPI specification [GSSAPI] says that a zero QOP value + indicates the "default". The original specification for the + Kerberos 5 mechanism says that a zero QOP value (or a QOP value + with the appropriate bits clear) means DES encryption. + + Rather than continue to force the use of plain DES when the + application doesn't use mechanism-specific QOP values, the better + choice appears to be to redefine the DES QOP value as some non-zero + value, and define a triple-DES value as well. Then a zero value + continues to imply the default, which would be triple-DES + protection when given a triple-DES session key. + + Our values are: + + GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 + /* SHA-1 checksum encrypted with key derivation */ + + GSS_KRB5_CONF_C_QOP_DES 0x0100 + /* plain DES encryption */ + GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 + /* triple-DES with key derivation */ + + Rather than open the question of whether to specify means for + deriving a key of one type given a key of another type, and the + security implications of whether to generate a long key from a + shorter one, our implementation will simply return an error if the + QOP value specified does not correspond to the session key type. + + [Implementation note: MIT's code does not implement QoP, and + returns an error for any non-zero QoP value.] + +5.2. MIC Sequence Number Encryption + + The sequence numbers are encrypted in the context key (as defined + in [GSSAPI-KRB5] -- this will be either the Kerberos session key or + asubkey provided by the context initiator), using whatever + encryption system is designated by the type of that context key. + The IV is formed from the first N bytes of the SGN_CKSUM field, + where N is the number of bytes needed for the IV. (With all + algorithms described here and in [GSSAPI-KRB5], the checksum is at + least as large as the IV.) + +5.3. Message Layout + + Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an + checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was + specified as being 8 bytes long. We now change this size to be + "defined by the checksum algorithm", and retroactively amend the + descriptions of all the checksum algorithms described in + [GSSAPI-KRB5] to explicitly specify 8-byte output. Application + data continues to immediately follow the checksum field in the Wrap + token. + + The revised message descriptions are thus: + + MIC: + + Byte no Name Description + 0..1 TOK_ID Identification field. + 2..3 SGN_ALG Integrity algorithm indicator. + 4..7 Filler Contains ff ff ff ff + 8..15 SND_SEQ Sequence number field. + 16..s+15 SGN_CKSUM Checksum of "to-be-signed data", + calculated according to algorithm + specified in SGN_ALG field. + + Wrap: + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_Wrap() contain + the hex value 02 01 in this field. + 2..3 SGN_ALG Checksum algorithm indicator. + 4..5 SEAL_ALG Sealing algorithm indicator. + 6..7 Filler Contains ff ff + 8..15 SND_SEQ Encrypted sequence number field. + 16..s+15 SGN_CKSUM Checksum of plaintext padded data, + calculated according to algorithm + specified in SGN_ALG field. + s+16..last Data encrypted or plaintext padded data + + Where "s" indicates the size of the checksum. + + As indicated above in section 2, we define the HMAC SHA1 DES3-KD + checksum algorithm to produce a 20-byte output, so encrypted data + begins at byte 36. + +6. Backwards Compatibility Considerations + + The context initiator SHOULD request of the KDC credentials using + session-key cryptosystem types supported by that implementation; if + the only types returned by the KDC are not supported by the + mechanism implementation, it MUST indicate a failure. This may + seem obvious, but early implementations of both Kerberos and the + GSSAPI Kerberos mechanism supported only DES keys, so the + cryptosystem compatibility question was easy to overlook. + + Under the current mechanism, no negotiation of algorithm types + occurs, so server-side (acceptor) implementations cannot request + that clients not use algorithm types not understood by the server. + However, administration of the server's Kerberos data has to be + done in communication with the KDC, and it is from the KDC that the + client will request credentials. The KDC could therefore be tasked + with limiting session keys for a given service to types actually + supported by the Kerberos and GSSAPI software on the server. + + This does have a drawback for cases where a service principal name + is used both for GSSAPI-based and non-GSSAPI-based communication, + if the GSSAPI implementation does not understand triple-DES but the + Kerberos implementation does. It means that triple-DES session + keys cannot be issued for that service principal, which keeps the + protection of non-GSSAPI services weaker than necessary. However, + in the most recent MIT releases thus far, while triple-DES support + has been present, it has required additional work to enable, so it + is not likely to be in use for many services. + + It would also be possible to have clients attempt to get single-DES + session keys before trying to get triple-DES session keys, and have + the KDC refuse to issue the single-DES keys only for the most + critical of services, for which single-DES protection is considered + inadequate. However, that would eliminate the possibility of + connecting with the more secure cryptosystem to any service that + can be accessed with the weaker cryptosystem. + + We have chosen to go with the former approach, putting the burden + on the KDC administration and gaining the best protection possible + for GSSAPI services, possibly at the cost of protection of + non-GSSAPI Kerberos services running earlier versions of the + software. + +6. Security Considerations + + Various tradeoffs arise regarding the mixing of new and old + software, or GSSAPI-based and non-GSSAPI Kerberos authentication. + They are discussed in section 5. + +7. References + + [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of + Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & + Associates, Inc., May, 1998. + + [GSSAPI] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January, 2000. + + [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June, 1996. + + [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", + draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", RFC 2026, October, 1996. + +8. Author's Address + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt new file mode 100644 index 0000000..64ca1ac --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt @@ -0,0 +1,395 @@ + + + + + + +Kerberos Working Group K. Raeburn +Category: Informational MIT +Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt November 24, 2000 + + + Triple-DES Support for the Kerberos 5 GSSAPI Mechanism + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be updated, + replaced, or obsoleted by other documents at any time. It is + inappropriate to use Internet-Drafts as reference material or to cite + them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically + enumerates encryption and checksum types, independently of how such + schemes may be used in Kerberos. In the long run, a new Kerberos- + based mechanism, which does not require separately enumerating for + the GSSAPI mechanism each of the various encryption types defined by + Kerberos, is probably a better approach. Various people have + expressed interest in designing one, but the work has not yet been + completed. + + The MIT Kerberos 5 release version 1.2 includes support for triple- + DES with key derivation [KrbRev]. Recent work by the EFF [EFF] has + demonstrated the vulnerability of single-DES mechanisms to brute- + force attacks by sufficiently motivated and well-funded parties. So, + in the interest of providing increased security in the near term, MIT + is adding support for triple-DES to the existing mechanism + implementation we ship, as an interim measure. + + + + + + + + +Raeburn [Page 1] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + +2. New Algorithm Identifiers + + One new sealing algorithm is defined, for use in Wrap tokens. + + + +--------------------------------------------------------------------+ + | name octet values | + +--------------------------------------------------------------------+ + | DES3-KD 02 00 | + +--------------------------------------------------------------------+ + + This algorithm uses triple-DES with key derivation, with a usage + value KG_USAGE_SEAL. (Unlike the EncryptedData definition in + [KrbRev], no integrity protection is needed, so this is "raw" triple- + DES, with no checksum attached to the encrypted data.) Padding is + still to 8-byte multiples, and the IV for encrypting application data + is zero. + + One new signing algorithm is defined, for use in MIC, Wrap, and + Delete tokens. + + + +--------------------------------------------------------------------+ + | name octet values | + +--------------------------------------------------------------------+ + | HMAC SHA1 DES3-KD 04 00 | + +--------------------------------------------------------------------+ + + This algorithm generates an HMAC using SHA-1 and a derived DES3 key + with usage KG_USAGE_SIGN, as described in [KrbRev]. + + [N.B.: The current [KrbRev] description refers to expired I-Ds from + Marc Horowitz. The text in [KrbRev] may be inadequate to produce an + interoperable implementation.] + + The checksum size for this algorithm is 20 octets. See section 4.3 + below for the use of checksum lengths of other than eight bytes. + + + + + + + + + + + + + + +Raeburn [Page 2] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + +3. Key Derivation + + For purposes of key derivation, we add three new usage values to the + list defined in [KrbRev]; one for signing messages, one for sealing + messages, and one for encrypting sequence numbers: + + + +--------------------------------------------------------------------+ + | name value | + +--------------------------------------------------------------------+ + | KG_USAGE_SEAL 22 | + | KG_USAGE_SIGN 23 | + | KG_USAGE_SEQ 24 | + +--------------------------------------------------------------------+ + +4. Adjustments to Previous Definitions + +4.1. Quality of Protection + + The GSSAPI specification [GSSAPI] says that a zero QOP value + indicates the "default". The original specification for the Kerberos + 5 mechanism says that a zero QOP value (or a QOP value with the + appropriate bits clear) means DES encryption. + + Rather than forcing the use of plain DES when the application doesn't + use mechanism-specific QOP values, we redefine the explicit DES QOP + value as a non-zero value, and define a triple-DES value as well. + Then a zero value continues to imply the default, which would be + triple-DES protection when given a triple-DES session key. + + Our values are: + + +--------------------------------------------------------------------+ + | name value meaning | + +--------------------------------------------------------------------+ + | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 SHA-1 HMAC, using | + | key derivation | + | | + | GSS_KRB5_CONF_C_QOP_DES 0x0100 plain DES encryption | + | | + | GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 triple-DES with key | + | derivation | + +--------------------------------------------------------------------+ + + Rather than attempt to specify a generic mechanism for deriving a key + of one type given a key of another type, and evaluate the security + implications of using a short key to generate a longer key to satisfy + the requested quality of protection, our implementation will simply + + + +Raeburn [Page 3] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + return an error if the nonzero QOP value specified does not + correspond to the session key type. + +4.2. MIC Sequence Number Encryption + + The sequence numbers are encrypted in the context key (as defined in + [GSSAPI-KRB5] -- this will be either the Kerberos session key or + asubkey provided by the context initiator), using whatever encryption + system is designated by the type of that context key. The IV is + formed from the first N bytes of the SGN_CKSUM field, where N is the + number of bytes needed for the IV. (With all algorithms described + here and in [GSSAPI-KRB5], the checksum is at least as large as the + IV.) + +4.3. Message Layout + + Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an + checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was specified + as being 8 bytes long. We now change this size to be "defined by the + checksum algorithm", and retroactively amend the descriptions of all + the checksum algorithms described in [GSSAPI-KRB5] to explicitly + specify 8-byte output. Application data continues to immediately + follow the checksum field in the Wrap token. + + The revised message descriptions are thus: + + MIC token: + + Byte # Name Description + ---------------------------------------------------------------------- + 0..1 TOK_ID Identification field. + 2..3 SGN_ALG Integrity algorithm indicator. + 4..7 Filler Contains ff ff ff ff + 8..15 SND_SEQ Sequence number field. + 16..s+15 SGN_CKSUM Checksum of "to-be-signed + data", calculated according to + algorithm specified in SGN_ALG + field. + + + + + + + + + + + + + +Raeburn [Page 4] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + Wrap token: + + Byte # Name Description + ---------------------------------------------------------------------- + 0..1 TOK_ID Identification field. Tokens + emitted by GSS_Wrap() contain the + hex value 02 01 in this field. + 2..3 SGN_ALG Checksum algorithm indicator. + 4..5 SEAL_ALG Sealing algorithm indicator. + 6..7 Filler Contains ff ff + 8..15 SND_SEQ Encrypted sequence number field. + 16..s+15 SGN_CKSUM Checksum of plaintext padded data, + calculated according to algorithm + specified in SGN_ALG field. + s+16..last Data encrypted or plaintext padded data + + + Where "s" indicates the size of the checksum. + + As indicated above in section 2, we define the HMAC SHA1 DES3-KD + checksum algorithm to produce a 20-byte output, so encrypted data + begins at byte 36. + +5. Backwards Compatibility Considerations + + The context initiator should request of the KDC credentials using + session-key cryptosystem types supported by that implementation; if + the only types returned by the KDC are not supported by the mechanism + implementation, it should indicate a failure. This may seem obvious, + but early implementations of both Kerberos and the GSSAPI Kerberos + mechanism supported only DES keys, so the cryptosystem compatibility + question was easy to overlook. + + Under the current mechanism, no negotiation of algorithm types + occurs, so server-side (acceptor) implementations cannot request that + clients not use algorithm types not understood by the server. + However, administration of the server's Kerberos data (e.g., the + service key) has to be done in communication with the KDC, and it is + from the KDC that the client will request credentials. The KDC could + therefore be tasked with limiting session keys for a given service to + types actually supported by the Kerberos and GSSAPI software on the + server. + + This does have a drawback for cases where a service principal name is + used both for GSSAPI-based and non-GSSAPI-based communication (most + notably the "host" service key), if the GSSAPI implementation does + not understand triple-DES but the Kerberos implementation does. It + means that triple-DES session keys cannot be issued for that service + + + +Raeburn [Page 5] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + principal, which keeps the protection of non-GSSAPI services weaker + than necessary. + + It would also be possible to have clients attempt to get single-DES + session keys before trying to get triple-DES session keys, and have + the KDC refuse to issue the single-DES keys only for the most + critical of services, for which single-DES protection is considered + inadequate. However, that would eliminate the possibility of + connecting with the more secure cryptosystem to any service that can + be accessed with the weaker cryptosystem. + + For MIT's 1.2 release, we chose to go with the former approach, + putting the burden on the KDC administration and gaining the best + protection possible for GSSAPI services, possibly at the cost of + weaker protection of non-GSSAPI Kerberos services running earlier + versions of the software. + +6. Security Considerations + + Various tradeoffs arise regarding the mixing of new and old software, + or GSSAPI-based and non-GSSAPI Kerberos authentication. They are + discussed in section 5. + +7. References + + [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of + Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & + Associates, Inc., May, 1998. + + [GSSAPI] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January, 2000. + + [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June, 1996. + + [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos- + revisions-06.txt, July 4, 2000. + +8. Author's Address + + Kenneth Raeburn Massachusetts Institute of Technology 77 + Massachusetts Avenue Cambridge, MA 02139 + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + + + +Raeburn [Page 6] + +INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 + + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +10. Document Change History + +>From -00 to -01: + + Converted master to GNU troff and tbl, rewriting tables in the + process. + + Specify informational category only. Modify some text to emphasize + that this document intends to describe MIT's extensions. + + Point out that while EncryptedData for 3des-kd includes a checksum, + DES3-KD GSS encryption does not. + + Shorten backwards-compatibility descriptions a little. + + Submit to Kerberos working group rather than CAT. + + + + + + + + + + + +Raeburn [Page 7] + diff --git a/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt new file mode 100644 index 0000000..321c5ba --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt @@ -0,0 +1,929 @@ + + +DHC Working Group S. Medvinsky +Internet Draft Motorola +Document: <draft-smedvinsky-dhc-kerbauth-01.txt> +Category: Standards Track P.Lalwaney +Expires: January 2001 Nokia + + July 2000 + + + Kerberos V Authentication Mode for Uninitialized Clients + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + The distribution of this memo is unlimited. It is filed as <draft- + smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please + send comments to the authors. + + + +1. Abstract + + The Dynamic Host Configuration Protocol (DHCP) [1] includes an + option that allows authentication of all DHCP messages, as specified + in [2]. This document specifies a DHCP authentication mode based on + Kerberos V tickets. This provides mutual authentication between a + DHCP client and server, as well as authentication of all DHCP + messages. + + This document specifies Kerberos message exchanges between an + uninitialized client and the KDC (Key Distribution Center) using an + IAKERB proxy [7] so that the Kerberos key management phase is + decoupled from, and precedes the address allocation and network + configuration phase that uses the DHCP authentication option. In + order to make use of the IAKERB proxy, this document specifies a + transport mechanism that works with an uninitialized client (i.e. a + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + client without an assigned IP address). In addition, the document + specifies the format of the Kerberos authenticator to be used with + the DHCP authentication option. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119. + +3. Introduction + + 3.1 Terminology + + o "DHCP client" + + A DHCP client is an Internet host using DHCP to obtain configuration + parameters such as a network address. + + o "DHCP server" + + A DHCP server is an Internet host that returns configuration + parameters to DHCP clients. + + O "Ticket" + + A Kerberos term for a record that helps a client authenticate itself + to a server; it contains the client's identity, a session key, a + timestamp, and other information, all sealed using the server's + secret key. It only serves to authenticate a client when presented + along with a fresh Authenticator. + + o "Key Distribution Center" + + Key Distribution Center, a network service that supplies tickets and + temporary session keys; or an instance of that service or the host + on which it runs. The KDC services both initial ticket and Ticket- + Granting Ticket (TGT) requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service. The + Ticket-Granting Ticket portion is sometimes referred to as the + Ticket-Granting Server (or service). + + o "Realm" + + A Kerberos administrative domain that represents a group of + principals registered at a KDC. A single KDC may be responsible for + one or more realms. A fully qualified principal name includes a + realm name along with a principal name unique within that realm. + +3.2 Protocol Overview + + + +S. Medvinsky, P. Lalwaney -2- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + DHCP as defined in [1] defines the protocol exchanges for a client + to obtain its IP address and network configuration information from + a DHCP Server. Kerberos V5 as described in [6] defines the protocol + and message exchanges to mutually authenticate two parties. It is + our goal to provide authentication support for DHCP using Kerberos. + This implies that the Kerberos key management exchange has to take + place before a client gets its IP address from the DHCP Server. + Kerberos assumes that the client has a network address and can + contact the Key Distribution Center to obtain its credentials for + authenticated communication with an application server. + + In this specification we utilize the key exchange using an IAKERB + proxy described in [7]. This does not require any changes to either + the IAKERB or the Kerberos V5 specification. This document also + specifies a particular transport that allows an uninitialized client + to contact an IAKERB proxy. + + The Kerberos ticket returned from the key management exchange + discussed in Section 5 of this document is passed to the DHCP Server + inside the DHCP authentication option with the new Kerberos + authenticator type. This is described in Section 6 of this draft. + + +3.3 Related Work + + A prior Internet Draft [3] outlined the use of Kerberos-based + authentication for DHCP. The proposal tightly coupled the Kerberos + client state machines and the DHCP client state machines. As a + result, the Kerberos key management messages were carried in DHCP + messages, along with the Kerberos authenticators. In addition, the + first DHCP message exchange (request, offer) is not authenticated. + + We propose a protocol exchange where Kerberos key management is + decoupled from and precedes authenticated DHCP exchanges. This + implies that the Kerberos ticket returned in the initial key + management exchange could be used to authenticate servers assigning + addresses by non-DHCP address assignment mechanisms like RSIP [4] + and for service specific parameter provisioning mechanisms using SLP + [5]. + + + + + + + + + + + + + + +S. Medvinsky, P. Lalwaney -3- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + +4. System Architecture + + + Client + -------- -------- + | | 5.Authenticated DHCP | | + | DHCP |<------------------------>| DHCP | + | client | | server | + | | | | + | | | | + |Kerberos| | | + | Client | | | + -------- -------- + ^ + | + | + | + | ------- + ------------------------------>| | + Kerberos Key Mgmt | Proxy | + messages: | | + 1. AS Request / 2.AS Reply ------- + 3. TGS Request / 4.TGS Reply ^ + | Kerberos + | Key Mgmt messages + v (1, 2, 3, 4) + -------- + | | + | KDC | + | | + -------- + + Figure 1: System blocks and message interactions between them + + + In this architecture, the DHCP client obtains a Kerberos ticket from + the Key Distribution Center (KDC) using standard Kerberos messages, + as specified in [6]. The client, however, contacts the KDC via a + proxy server, according to the IAKERB mechanism, described in [7]. + The are several reasons why a client has to go through this proxy in + order to contact the KDC: + + a)The client may not know the host address of the KDC and may be + sending its first request message as a broadcast on a local + network. The KDC may not be located on the local network, and + even if it were - it will be unable to communicate with a client + without an IP address. This document describes a specific + mechanism that may be used by a client to communicate with the + Kerberos proxy. + + + +S. Medvinsky, P. Lalwaney -4- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + b)The client may not know its Kerberos realm name. The proxy is + able to fill in the missing client realm name in an AS Request + message, as specified in IAKERB. Note that in the case that + PKINIT pre-authenticator is used [8], the realm name in the AS + Request may be the KDC realm name and not the clientÆs realm name. + + c) The client does not know the realm name of the DHCP server. + + According to IAKERB, when the client sends a TGS Request with a + missing server realm name, the proxy will return to the client an + error message containing the missing realm name. + + Note that in this case the proxy could return the client a wrong + realm name and the client could be fooled into obtaining a ticket + for the wrong DHCP server (on the same local network). However, + the wrong DHCP server must still be a registered principal in a + KDC database. In some circumstances this may be an acceptable + compromise. Also, see the security considerations section. + + IAKERB describes the proxy as part of an application server - the + DHCP server in this case. However, in this document we are not + requiring the proxy to be integrated with the DHCP server. The + same IAKERB mechanisms apply in the more general case, where the + proxy is an independent application. This proxy, however, MUST be + reachable by a client via a local network broadcast. + + After a client has obtained a Kerberos ticket for the DHCP server, + it will use it as part of an authentication option in the DHCP + messages. The only extension to the DHCP protocol is the addition + of a new authenticator type based on Kerberos tickets. + +4.1 Cross-Realm Authentication + + Figure 1 shows a client communicating with a single KDC via a proxy. + However, the DHCP clientÆs realm may be different from the DHCP + serverÆs realm. In that case, the client may need to first contact + the KDC in its local realm to obtain a cross-realm TGT. Then, the + client would use the cross-realm TGT to contact the KDC in the DHCP + serverÆs realm, as specified in [6]. + + In the following example a client doesnÆt know its realm or the DHCP + serverÆs realm, which happens to be different from the clientÆs + realm. Here are the steps in obtaining the ticket for the DHCP + server (based on [6] and [7]): + + 1) The client sends AS Request with NULL realm to the proxy. + 2) The proxy fills in the realm and forwards the AS Request to + the KDC in the clientÆs realm. + 3) The KDC issues a TGT and sends back an AS Reply to the + proxy. + 4) The proxy forwards AS Reply to the client. + + +S. Medvinsky, P. Lalwaney -5- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + 5) The client sends TGS Request for a principal name "dhcpsrvr" + with NULL realm to the proxy. + 6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the + DHCP serverÆs realm to the client. + 7) The client sends another TGS Request for a cross-realm TGT + to the proxy. + 8) The proxy forwards the TGS Request to the KDC in the + clientÆs realm. + 9) The KDC issues a cross-realm TGT and sends back a TGS Reply + to the proxy. + 10) The proxy forwards TGS Reply to the client. + 11) The client sends a TGS Request to the proxy for a principal + "dhcpsrvr" with the realm name filled in, using a cross-realm + TGT. + 12) The proxy forwards TGS Request to the KDC in the DHCP + server's realm. + 13) The KDC issues a ticket for the DHCP server and sends TGS + Reply back to the proxy. + 14) The proxy forwards TGS Reply to the client. + + In a most general case, the client may need to contact any number of + KDCs in different realms before it can get a ticket for the DHCP + server. In each case, the client would contact a KDC via the proxy + server, as specified in Section 5 of this document. + +4.2 Public Key Authentication + + This specification also allows clients to perform public key + authentication to the KDC, based on the PKINIT specification [8]. + In this case, the size of an AS Request and AS Reply messages is + likely to exceed the size of typical link MTU's. + + Here is an example, where PKINIT is used by a DHCP client that is + not a registered principal in the KDC principal database: + + 1) The client sends AS Request with a PKINIT Request pre- + authenticator to the proxy. This includes the clientÆs + signature and X.509 certificate. The KDC realm field is + left as NULL. + 2) The proxy fills in the realm and forwards the AS Request to + the KDC in the filled in realm. This is the realm of the + DHCP server. Here, the clientÆs realm is the name of a + Certification Authority - not the same as the KDC realm. + 3) The KDC issues a TGT and sends back an AS Reply with a + PKINIT Reply pre-authenticator to the proxy. + 4) The proxy forwards the AS Reply to the client. + 5) The client sends TGS Request for a principal name "dhcpsrvr" + with the realm found in the TGT to the proxy. + 6) The proxy forwards TGS Request to the KDC in the DHCP + serverÆs realm. + 7) The KDC issues a ticket for the DHCP server and sends TGS + Reply back to the proxy. + +S. Medvinsky, P. Lalwaney -6- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + 8) The proxy forwards TGS Reply to the client. + + + 5. Key Management Exchange that Precedes Network Address Allocation + + An uninitialized host (e.g. on power-on and reset) does not have a + network address. It does have a link layer address or hardware + address. At this time, the client may not have any information on + its realm or the realm of the address allocation server (DHCP + Server). + + In the Kerberos key management exchange, a client gets its ticket + granting ticket (TGT) by contacting the Authentication Server in the + KDC using the AS_Request / Reply messages (shown as messages 1 and 2 + in Figure 1). The client then contacts the Ticket Granting Server in + the KDC to get the DHCP server ticket (to be used for mutual + authentication with the DHCP server) using the TGS_REQ / TGS_REP + messages (shown as messages 3 and 4 in the above figure). It is + also possible for the client to obtain a DHCP server ticket directly + with the AS Request / Reply exchange, without the use of the TGT. + + In the use of Kerberos for DHCP authentication, the client (a) does + not have an IP/network address (b) does not know he KDCÆs IP address + (c) the KDC may not be on the local network and (d) the client may + not know the DHCP ServerÆs IP address and realm. We therefore + require a Kerberos proxy on the local network to accept broadcast + Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized + clients and relay them to the appropriate KDC. + + The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as + follows: + + The request payload contains the client hardware address in + addresses field with a negative value for the address type. Kerberos + v5 [6] allows for the usage of negative address types for "local" + use. Note that IAKERB [7] discourages the use of the addresses field + as network addresses may not be known or may change in situation + where proxies are used. In this draft we incorporate the negative + values permitted in the Kerberos transport in the address type field + of both the AS_REQ and TGS_REQ messages. The negative value SHOULD + be the negative number of the hardware address type "htype" value + (from assigned numbers RFC) used in RFC 2131. The address field of + the message contains the clients hardware address. + + The request payload is UDP encapsulated and addressed to port 88 on + the server/proxy. The UDP source port is selected by the client. The + source and destination network addresses are the all-zeroÆs address + and the broadcast address, respectively. For IPv4, the source IP + address is set to 0.0.0.0 and the destination IP address is set to + 255.255.255.255. The data link layer header source address + corresponds to the link layer/hardware address of the client. The + + +S. Medvinsky, P. Lalwaney -7- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + destination link layer address is the broadcast address at the link + layer (e.g. for Ethernet the address is ffffffff). + + In the case where AS_REQ message contains a PKINIT pre-authenticator + for public key-based client authentication (based on [8]), the + message will probably not fit into a single UDP packet given typical + link MTU's. + + It is assumed that the proxy server on a network is configured with + a list of KDCÆs, their realms and their IP addresses. The proxy + server will act as a client to the KDC and forward standard Kerberos + messages to/from the KDC using unicast UDP or TCP transport + mechanisms, according to [6]. + + Upon receiving a broadcast request from a client, the proxy MUST + record the clientÆs hardware address that appears as the source + address on the frame as well as in the addresses field of the + request message. Based on the realm of the KDC specified in the + request, the proxy determines the KDC to which this message is + relayed as a unicast message from the proxy to the KDC. In the case + that the client left the KDC realm name as NULL, it is up to the + proxy to first determine the correct realm name and fill it in the + request (according to [7]). + + On receiving a request, the KDC formulates a response (AS_REP or + TGS_REP). It includes the clientÆs addresses field in the encrypted + part of the ticket (according to [6]). This response is unicast to + the proxy. + + Upon receiving the reply, the proxy MUST first determine the + previously saved hardware address of the client. The proxy + broadcasts the reply on its local network. This is a network layer + broadcast. At the link level, it uses the hardware address obtained + from the addresses field of the request. + + The client on receiving the response (link layer destination address + as its hardware address, network layer address is the broadcast + address) must verify that the hardware address in the ticket + corresponds to its link layer address. + + Upon receiving a TGS_REP (or an AS_REP with the application server + ticket) from the proxy, the client will have enough information to + securely communicate with the application server (the DHCP Server in + this case), as specified in the following section. + + + + + + + + + +S. Medvinsky, P. Lalwaney -8- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + 6. Authenticated Message Exchange Between the DHCP Client and the + DHCP Server + + The ticket returned in the TGS response is used by the DHCP client + in the construction of the Kerberos authenticator. The Kerberos + ticket serves two purposes: to establish a shared session key with + the DHCP server, and is also included as part of a Kerberos + authenticator in the DHCP request. + + If the size of the authenticator is greater than 255 bytes, the DHCP + authentication option is repeated multiple times. When the values + of all the authentication options are concatenated together, they + will make up the complete authenticator. + + Once the session key is established, the Kerberos structure + containing the ticket (AP REQ) can be omitted from the authenticator + for subsequent messages sent by both the DHCP client and the DHCP + server. + + The Kerberos authenticator for a DHCP request message is specified + below: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Length | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Replay Detection (64 bits) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Authentication token (n octets) ... + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format of this authenticator is in accordance with [2]. The code + for the authentication option is TBD, and the length field contains + the length of the remainder of the option, starting with the + protocol field. + + The value of the protocol field for this authenticator MUST be set + to 2. + + The algorithm field MUST take one of the following values: + 1 - HMAC-MD5 + 2 - HMAC-SHA-1 + + Replay protection field is a monotonically increasing counter field. + When the Kerberos AP REQ structure is present in the authenticator + the counter may be set to any value. The AP REQ contains its own + replay protection mechanism in the form of a timestamp. + +S. Medvinsky, P. Lalwaney -9- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + Once the session key has been established and the AP REQ is not + included in the authenticator, this field MUST be monotonically + increasing in the messages sent by the client. + + Kerberos authenticator token consists of type-length-value + attributes: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Reserved | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | attribute value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The following attributes are included in the Kerberos authenticator + token: + + Type Attribute Name Value + -------------------------------------------------------------------- + 0 Message Integrity Code Depends on the value of the + algorithm field. Its length is + 16 bytes for HMAC-MD5 [9, 10] + and 20 bytes for HMAC-SHA-1 + [11, 10]. The HMAC key must be + derived from Kerberos session + key found in the Kerberos + ticket according to the key + derivation rules in [6]: + + HMAC Key = DK(sess key, + key usage | 0x99) + + Here, DK is defined in [12] and + the key usage value for DHCP is + TBD. + + The HMAC is calculated over the + entire DHCP message. The + Message Integrity Code + attribute MUST be set to all 0s + for the computation of the + HMAC. Because a DHCP relay + agent may alter the values of + the 'giaddr' and 'hops' fields + in the DHCP message, the + contents of those two fields + MUST also be set to zero for + the computation of the HMAC. + Rules specified in Section 3 of + [2] for the exclusion and + +S. Medvinsky, P. Lalwaney -10- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + processing of the relay agent + information are applicable here + too. + + This field MUST always be + present in the Kerberos + authenticator. + + 1 AP_REQ ASN.1 encoding of a Kerberos + AP_REQ message, as specified + in [6]. This MUST be included + by the client when establishing + a new session key. In all + other cases, this attribute + MUST be omitted. + + AP_REQ contains the Kerberos ticket for the DHCP server and also + contains information needed by the DHCP server to authenticate the + client. After verifying the AP_REQ and decrypting the Kerberos + ticket, the DHCP server is able to extract a session key which it + now shares with the DHCP client. + + The Kerberos authenticator token contains its own replay protection + mechanism inside the AP_REQ structure. The AP_REQ contains a + timestamp that must be within an agreed upon time window at the DHCP + server. However, this does not require the DHCP clients to maintain + an accurate clock between reboots. Kerberos allows clients to + synchronize their clock with the KDC with the help of Kerberos + KRB_AP_ERR_SKEW error message, as specified in [6]. + + The DHCP server MUST save both the session key and its associated + expiration time found in the Kerberos ticket. Up until the + expiration time, the server must accept client requests with the + Kerberos authenticator that does not include the AP REQ, using the + saved session key in calculating HMAC values. + + The Kerberos authenticator inside all DHCP server responses MUST NOT + contain the AP REQ and MUST use the saved Kerberos session key in + calculating HMAC values. + + When the session key expires, it is the client's responsibility to + obtain a new ticket from the KDC and to include an AP REQ inside the + Kerberos authenticator for the next DHCP request message. + + + + + + + + + + +S. Medvinsky, P. Lalwaney -11- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + +7. Detailed message flows for Kerberos and DHCP message Exchanges + + The following flow depicts the Kerberos exchange in which a AS REQ + message is used to directly request the DHCP Server ticket. There + are no changes to transport mechanisms below when the additional + phase of using TGS requests/responses with TGTÆs is used. + + Client IAKERB Proxy KDC + + KB-client-------- AS_REQ ------> + + AS REQ Address type = - (htype) + AS REQ Address= hw address + + src UDP port = senders port + destination UDP port = 88 + + src IP = 0.0.0.0 + destination IP = 255.255.255.255 + + src link layer address = + clientÆs HW/link address [e.g Ethernet address] + + destination link layer address = + link broadcast address [e.g. ffffffff for Ethernet] + + + ---------------------------> + (unicast to UDP port 88) + + + + <-------------------------- + (unicast AS REP) + Encrypted portion of ticket + Includes clients HW address + + + <---------------AS_REP ----------- + + + Ticket includes clientÆs hardware address + + src UDP port = 88 + destination UDP port = copied from src port in AS_REQ + + src IP = ProxyÆs IP address + destination IP = 255.255.255.255 + + src link layer address = ProxyÆs HW/link address + destination link layer address = + ClientÆs link layer address from AS_REQ + + +S. Medvinsky, P. Lalwaney -12- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + + + The client uses the ticket received from the KDC in the DHCP +Authentication option as described in Section 6. + + + Client + DHCP-client DHCP Server + + ------DHCPDISCOVER ----> + (Auth Protocol = 2, includes Kerberos + authenticator with AP REQ ) + ----------------------------------- + | HMAC | AP REQ | + ---------------------------------- + | Ticket| Client Authent | + -------------------------- + + 1. Server decrypts ticket + (inside AP REQ) with service + key + 2. Server decrypts client + authenticator (inside AP REQ) + and checks content and + checksum to validate the + client. + 3. Recompute HMAC with session + key and compare. + + + <-------DHCPOFFER---------- + (Auth Protocol = 2, no AP REQ ) + + + + ---------DHCPREQUEST-------> + (Auth Protocol = 2, no AP REQ) + + + <--------DHCPACK------------- + (Auth Protocol = 2, no AP REQ ) + + + + +8. Security Considerations + + DHCP clients that do not know the DHCP serverÆs realm name will get + it from the proxy, as specified in IAKERB [7]. Since the proxy is + not authenticated, a DHCP client can be fooled into obtaining a + ticket for the wrong DHCP server in the wrong realm. + +S. Medvinsky, P. Lalwaney -13- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + This could happen when the client leaves out the server realm name + in a TGS Request message to the proxy. It is also possible, + however, for a client to directly request a DHCP server ticket with + an AS Request message. In those cases, the same situation occurs + when the client leaves out the realm name in an AS Request. + + This wrong DHCP server is still registered as a valid principal in a + database of a KDC that can be trusted by the client. In some + circumstances a client may assume that a DHCP server that is a + Kerberos principal registered with a trusted KDC will not attempt to + deliberately misconfigure a client. + + This specification provides a tradeoff between: + + 1) The DHCP clients knowing DHCP serverÆs realm ahead of time, + which provides for full 2-way authentication at the cost of + an additional configuration parameter. + 2) The DHCP clients not requiring any additional configuration + information, besides a password or a key (and a public key + certificate if PKINIT is used). This is at the cost of not + being able to fully authenticate the identity of the DHCP + server. + + + +9. References + + + [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol", + RFC 2131, Bucknell University, March 1997. + + [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages", + draft-ietf-dhc-authentication-13.txt, June 2000. + + [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V", + draft-hornstein-dhc-kerbauth-02.txt, February 2000. + + [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm + Specific IP: Protocol Specification ", draft-ietf-nat-rsip- + protocol-06.txt, March 2000. + + [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service + Location Protocol, Version 2", RFC 2608, June 1999. + + [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 05.txt, March 2000. + + + + + +S. Medvinsky, P. Lalwaney -14- + +Kerberos V Authentication Mode for Uninitialized Clients July 2000 + + + + [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through + Authentication Using Kerberos V5 and the GSS-API (IAKERB)", + draft-ietf-cat-iakerb-03.txt, September 1999. + + [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, + J. Trostle, "Public Key Cryptography for Initial Authentication + in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000. + + [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for + Message Authentication," RFC 2104, February 1997. + + [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995. + + [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and + Privacy", draft-horowitz-key-derivation-02.txt, August 1998. + + [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC + 2026. + + + + 10. Author's Addresses + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + Email: smedvinsky@gi.com + + Poornima Lalwaney + Nokia + 12278 Scripps Summit Drive + San Diego, CA 92131 + Email: poornima.lalwaney@nokia.com + + +11. Expiration + + This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and + expires January 1, 2001. + + + +12. Intellectual Property Notices + + + + + + +S. Medvinsky, P. Lalwaney -15- + +Kerberos V Authentication Mode for Uninitialized Clients March 2000 + + + This section contains two notices as required by [13] for + standards track documents. Per [13], section 10.4(A): + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances + of licenses to be made available, or the result of an attempt made + to obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification + can be obtained from the IETF Secretariat. + + Per [13] section 10.4(D): + + The IETF has been notified of intellectual property rights + claimed in regard to some or all of the specification contained in + this document. For more information consult the online list of + claimed rights. + + 13. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. The limited permissions granted above are perpetual and + will not be revoked by the Internet Society or its successors or + assigns. This document and the information contained herein is + provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + +S. Medvinsky, P. Lalwaney -16- +
\ No newline at end of file diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt new file mode 100644 index 0000000..85d7456 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on July 17, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt new file mode 100644 index 0000000..85d7456 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on July 17, 2000. diff --git a/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt new file mode 100644 index 0000000..68c170b --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt @@ -0,0 +1,1140 @@ + + + + + + +INTERNET-DRAFT Kerberized USM Keying M. Thomas + Cisco Systems + K. McCloghrie + Cisco Systems + July 13, 2000 + + + + + + + Kerberized USM Keying + + draft-thomas-snmpv3-kerbusm-00.txt + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + + The KerbUSM MIB provides a means of leveraging a trusted third party + authentication and authorization mechanism using Kerberos for SNMP V3 + USM users and their associated VACM views. The MIB encodes the normal + Kerberos AP-REQ and AP-REP means of both authenticating and creating + a shared secret between the SNMP V3 Manager and Agent. + +The SNMP Management Framework + + The SNMP Management Framework presently consists of five major + components: An overall architecture, described in RFC 2571 + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 1] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + [RFC2571]. Mechanisms for describing and naming objects and events + for the purpose of management. The first version of this Structure + of Management Information (SMI) is called SMIv1 and described in STD + 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 + [RFC1215]. The second version, called SMIv2, is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. Message protocols for transferring management + information. The first version of the SNMP message protocol is + called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second + version of the SNMP message protocol, which is not an Internet + standards track protocol, is called SNMPv2c and described in RFC 1901 + [RFC1901] and RFC 1906 [RFC1906]. The third version of the message + protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC + 2572 [RFC2572] and RFC 2574 [RFC2574]. Protocol operations for + accessing management information. The first set of protocol + operations and associated PDU formats is described in STD 15, RFC + 1157 [RFC1157]. A second set of protocol operations and associated + PDU formats is described in RFC 1905 [RFC1905]. A set of fundamental + applications described in RFC 2573 [RFC2573] and the view-based + access control mechanism described in RFC 2575 [RFC2575]. + + A more detailed introduction to the current SNMP Management Framework + can be found in RFC 2570 [RFC2570]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. Objects in the MIB are + defined using the mechanisms defined in the SMI. + + This memo specifies a MIB module that is compliant to the SMIv2. A + MIB conforming to the SMIv1 can be produced through the appropriate + translations. The resulting translated MIB must be semantically + equivalent, except where objects or events are omitted because no + translation is possible (use of Counter64). Some machine readable + information in SMIv2 will be converted into textual descriptions in + SMIv1 during the translation process. However, this loss of machine + readable information is not considered to change the semantics of the + MIB. + + +Introduction + + The User based Security Model of SNMP V3 (USM) [2] provides a means + of associating different users with different access privileges of + the various MIB's that an agent supports. In conjunction with the + View based Access Control Model of SNMP V3 (VACM) [3], SNMP V3 + provides a means of providing resistance from various threats both + from outside attacks such as spoofing, and inside attacks such as an + user having, say, SET access to MIB variable for which they are not + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 2] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + authorized. + + SNMP V3, unfortunately, does not specify a means of doing key + distribution between the managers and the agents. For small numbers + of agents and managers, the O(n*m) manual keying is a cumbersome, but + possibly tractable problem. For a large number of agents with + distribution of managers, the key distribution quickly goes from + cumbersome to unmanageable. Also: there is always the lingering + concern of the security precautions taken for keys on either local + management stations, or even directories. + + Kerberos [1] provides a means of centralizing key management into an + authentication and authorization server known as a Key Distribution + Center (KDC). At a minimum, Kerberos changes the key distribution + problem from a O(n*m) problem to a O(n) problem since keys are shared + between the KDC and the Kerberos principals rather directly between + each host pair. Kerberos also provides a means to use public key + based authentication which can be used to further scale down the + number of pre-shared secrets required. Furthermore, a KDC is intended + and explicitly expected to be a standalone server which is managed + with a much higher level of security concern than a management + station or even a central directory which may host many services and + thus be exposed to many more possible vectors of attack. + + The MIB defined in this memo describes a means of using the desirable + properties of Kerberos within the context of SNMP V3. Kerberos + defines a standardized means of communicating with the KDC as well as + a standard format of Kerberos tickets which Kerberos principals + exchange in order to authenticate to one another. The actual means of + exchanging tickets, however, is left as application specific. This + MIB defines the SNMP MIB designed to transport Kerberos tickets and + by doing so set up SNMP V3 USM keys for authentication and privacy. + + It should be noted that using Kerberos does introduce reliance on a + key network element, the KDC. This flies in the face of one of SNMP's + dictums of working when the network is misbehaving. While this is a + valid concern, the risk of reliance on the KDC can be significantly + diminished with a few common sense actions. Since Kerberos tickets + can have long life times (days, weeks) a manager of key network + elements can and should maintain Kerberos tickets well ahead ticket + expiration so that likelihood of not being able to rekey a session + while the network is misbehaving is minimized. For non-critical, but + high fanout elements such as user CPE, etc, requiring a pre-fetched + ticket may not be practical, which puts the KDC into the critical + path. However, if all KDC's are unreachable, the non-critical network + elements are probably the least of the worries. + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 3] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + +Operation + + The normal Kerberos application ticket exchange is accomplished by a + client first fetching a service ticket from a KDC for the service + principal and then sending an AP-REQ to a server to authenticate + itself to the server. The server then sends a AP-REP to finish the + exchange. This MIB maps Kerberos' concept of client and server into + the SNMP V3 concept of Manager and Agent by designating that the + Kerberos Client is the SNMP V3 Agent. Although it could be argued + that an Agent is really a server, in practice there may be many, many + agents and relatively few managers. Also: Kerberos clients may make + use of public key authentication as defined in [4], and it is very + advantageous to take advantage of that capability for Agents rather + than Managers. + + The MIB is intended to be stateless and map USM users to Kerberos + principals. This mapping is explicitly done by putting a Kerberos + principal name into the usmUserSecurityName in the usmUser MIB and + instatiating the krbUsmMibEntry for the usmUserEntry. MIB variables + are accessed with INFORM's or TRAP PDU's and SET's to perform a + normal Kerberos AP-REQ/AP-REP exchange transaction which causes the + keys for a USM user to be derived and installed. The basic structure + of the MIB is a table which augements usmUserEntry's with a Kerberos + principal name as well as the transaction varbinds. In the normal + case, multiple varbinds should be sent in a single PDU which prevents + various race conditions, as well as increasing efficiency. + + It should be noted that this MIB is silent on the subject of how the + Agent and Manager find the KDC. In practice, this may be either + statically provisioned or use either DNS SRV records (RFC 2782) or + Service Location (RFC 2608). This MIB is does not provide for a means + of doing cipher suite negotiation either. It is expected that the + choices for ciphers in the USM MIB will reflect site specific choices + for ciphers. This matches well with the general philosophy of + centralized keying. + +Keying Transactions + + The following shows an error free transaction: + + Note: optional steps or parameters are shown like [ ] + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 4] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + + Agent Manager KDC + +-- --+ + | 1) <------------------------------- | + | SET (krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx; | + | [ krbUsmPrinTable[usmUserName].krbUsmMibTgt = | + | TGT[usmUserSecurityName] ]); | + | | + | 2) -------------------------------> | + | Response | + +-- (optional) --+ + + 3) ---------------------------------------------------------------> + TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName + [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]); + + 4) <-------------------------------------------------------------- + Tick[usmUserSecurityName] = TGS-REP (); + + 5) ------------------------------> + INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq = + AP_REQ[Tick[usmUserSecurityName]]; + [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]); + + 6) <------------------------------ + SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]); + + + 7) ------------------------------> + Response + + + The above flow translates to: + + + 1) This step is used when the Manager does not currently have a ses- + sion with the Agent but wishes to start one. The Manager MAY + place a ticket granting ticket into the krbUsmMibMgrTgt varbind + in the same PDU as the krbUsmMibNonce if it does not share a + secret with the KDC (as would be the case if the Manager used + PKinit to do initial authentication with the KDC). + + + 2) This step acknowledges the SET. There are no MIB specific errors + which can happen here. + + + 3) If the Agent is not already in possession of a service ticket for + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 5] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + the Manager in its ticket cache, it MUST request a service ticket + from the Agent's KDC for the service principal given by + krbUsmMibMgrPrinName in the row that the krbUsmMibNonce was SET + in, optionally adding a krbUsmMibMgrTgt. If the TGT is speci- + fied, the Manager's TGT must be placed in the additional-tickets + field with the ENC-TKT-IN-SKEY option set in the TGS-REQ to + obtain a service ticket (see section 3.3.3 of [1]). + + Note: a Kerberos TGS-REQ is but one way to obtain a service + ticket. An Agent may use any normal Kerberos means to + obtain the service ticket. This flow has also elided ini- + tial authentication (ie, AS-REQ) and any cross realm con- + siderations, though those may be necessary prerequisites + to obtaining the service ticket. + + 4) If step 3 was performed, this step receives the ticket or an + error from the KDC. + + + 5) This step sends a krbUsmMibApReq to the Manager via an INFORM or + TRAP PDU. If the message is the result of a request by the + Manager, krbUsmMibNonce received from the Manager MUST be sent in + the same PDU. If the Manager did not initiate the transaction, + the Agent MUST NOT send a krbUsmMibNonce varbind. The Agent also + MUST check krbUsmMibUnsolicitedNotify is not false, otherwise it + MUST abort the transaction. All krbUsmMibApReq's MUST contain a + sequence nonce so that the resulting krbUsmMibApRep can provide a + proof of the freshness of the message to prevent replay attacks. + + If the Agent encounters an error either generated by the KDC or + internally, the Agent MUST send an INFORM or TRAP PDU indicating + the error in the form of a KRB-ERROR placed in krbUsmMibApReq + with the same rules applied to krbUsmMibNonce and krbUsmMibUnsol- + icitedNotify above. If the Agent suspects that it is being + attacked by a purported Manager which is generating many failed + TGS-REQ's to the KDC, it SHOULD meter its TGS-REQ transactions + for that Manager to the KDC using an exponential backoff mechan- + ism truncated at 10 seconds. + + + + 6) Upon recepit of an INFORM or TRAP PDU with a krbUsmMibApReq, a + Manager may accept the AP-REQ. If it is accompanied with a + krbUsmMibNonce it MUST correlate it with any outstanding transac- + tions using its stored nonce for the transaction. If it does not + correlate with a current nonce, the request MUST be rejected as + it may be a replay. + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 6] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + If the Manager chooses to reject an unsolicited keying request, + it SHOULD send a WrongValue Error to the Agent with the krbUsmMi- + bApReq as the subject of the WrongValue. If an Agent receives a + WrongValue Error from a Manager it MUST cease retransmission of + the INFORM or TRAP PDU's so as to mitigate event avalanches by + Agents. There is a possible denial of service attack here, but it + must be weighed against the larger problem of network congestion, + flapping, etc. Therefore, if the Agent finds that it cannot can- + cel an unsolicited Notify (ie, it must be reliable), it MUST use + a truncated exponential backoff mechanism with the maximum trun- + cation interval set to 10 minutes. + + Otherwise, the Manager MUST send a SET PDU to the Agent which + contains a krbUsmMibApRep. + + + 7) If the Agent detects an error (including detecting replays) in + the final AP-REP, it MUST send a WrongValue error with a pointer + to the krbUsmMibApRep varbind to indicate its inability to estab- + lish the security association. Otherwise, receipt of the positive + acknowledgement from the final SET indicates to the Manager that + the proper keys have been installed on the Agent in the USM MIB. + +Unsolicited Agent Keying Requests + + An Agent may find that it needs to set up a security association for + a USM user in order to notify a Manager of some event. When the Agent + engine receives a request for a notify, it SHOULD check to see if + keying material has been established for the user and that the keying + material is valid. If the keying material is not valid and the USM + user has been tagged as being a Kerberos principal in a realm, the + Agent SHOULD first try to instantiate a security association by + obtaining a service ticket for the USM User and follow steps 3-7 of + the flow above. This insures that the USM User will have proper key- + ing material and providing a mechanism to allow for casual security + associations to be built up and torn down. This is especially useful + for Agents which may not normally need to be under constant Manager + supervision, such as the case with high fan out user residential CPE + and other SNMP managed "appliances". In all cases, the Agent MUST NOT + send an unsolicited Notify if krbUsmUnsolicitedNotify is set to + false. + + How the Agent obtains the Manager's address, how it determines + whether a Manager, realm, and whether it can be keyed using this MIB + is outside of the scope of this memo. + + Note: Although the MIB allows for a Manager to set up a session + using User-User mode of Kerberos by sending a TGT along with + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 7] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + the nonce, this, is limited to Manager initiated sessions + only since there is no easy way to store the Manager's ticket + in the MIB since it is publicly writable and as such would be + subject to denial of service attacks. Another method might be + to have the Agent send a krbUsmMibNonce to the Manager which + would tell it to instigate a session. Overall, it seems like + a marginal feature to allow a PKinit authenticated user be + the target of unsolicited informs and it would complicate the + transactions. For this reason, this scenario has been omitted + in favor of simplicity. + +Retransmissions + + Since this MIB defines not only variables, but transactions, discus- + sion of the retransmission state machine is in order. There are two + similar but different state machines for the Manager Solicited and + Agent Unsolicited transactions. There is one timer Timeout which + SHOULD take into consideration round trip considerations and MUST + implement a truncated exponential backoff mechanism. In addition, in + the case where an Agent makes an unsolicited Agent keying request, + the Agent SHOULD perform an initial random backoff if the keying + request to the Manager may result in a restart avalanche. A suitable + method is described in section 4.3.4 of [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 8] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + +Manager Solicited Retransmission State Machine + + Timeout + +---+ + | | + | V + +-----------+ Set-Ack (2) +----------+ + | |------------>| | + | Set-Nonce | | Ap-Req | + | (1) |<------------| (5) | + +-----------+ Timeout +----------+ + ^ | + | | Set-Ap-Rep + | +----------+ | (6) + +------| |<------+ + Timeout | Estab-wt | + | (7) | + +----------+ + | + | Set-Ap-Rep-Ack (7) + V + +----------+ + | | + | Estab | + | | + + +----------+ + + + + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 9] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + +Agent Unsolicited Retransmission State Machine + + Timeout + +---+ + | | + | V + +----------+ + | | + +----> | Ap-Req |-------+ + | | (5) | | + | +----------+ | + | | + | | Set-Ap-Rep + | +----------+ | (6) + +------| |<------+ + Timeout | Estab-wt | + | (7) | + +----------+ + | + | Set-Ap-Rep-Ack (7) + V + +----------+ + | | + | Estab | + | | + +----------+ + +Session Duration and Failures + + The KerbUsmMib uses the ticket lifetime to determine the life of the + USM session. The Agent MUST keep track of whether the ticket which + instigated the session is valid whenever it forms PDU's for that par- + ticular user. If a session expires, or if it wasn't valid to begin + with (from the Agent's perspective), the Agent MUST reject the PDU by + sending a XXX Error [mat: help me here Keith... what does USM say + about this?]. + + Kerberos also inherently implies adding state to the Agent and + Manager since they share not only a key, but a lifetime associated + with that key. This is in some sense soft state because failure of an + Agent will cause it to reject PDU's for Managers with whom it does + not share a secret. The Manager can use the Error PDU's as an indica- + tion that it needs to reauthenticate with the Agent, taking care not + to loop. The Manager is even easier: when it reboots, it can either + check its credential cache to reconstruct state or cause the Agent to + reauthenticate to the Manager with its service ticket by initiating a + authentication transaction with the manager. + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 10] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + +Manager Collisions + + Managers may freely set up keys for different USM users using this + MIB without problem since they access different rows in the krbUsm- + PrinTable. However, multiple Managers trying to set up keys for the + same USM user is possible but discouraged. The requirement for the + Manager is that they MUST share the same service key with the KDC so + that they can all decrypt the same service ticket. There are two race + conditions, however, which are not well handled: + + + +1) At the end of a ticket lifetime, one manager may request the agent + to refresh its service ticket causing a new session key to be + installed for the USM user leaving the other managers with stale + keys. The workaround here is that the Agent will reject the stale + manager's PDU's which should inform them to do their own rekeying + operations. + + +2) If multiple managers try to access the same row at the same time, + the Agent SHOULD try to keep the transactions separate based on the + nonce values. The Managers or the Agents SHOULD NOT break the + krbUsmMibNonce and any other additional varbinds into separate PDU's + as this may result in a meta stable state. Given normal MTU sizes, + this should not be an issue in practice, and this should at worst + devolve into the case above. + + In all cases, the krbUsmMibNonce MUST be the last value to be + transmitted, though its position within a PDU is unimportant. + + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 11] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + + KrbUSM MIB + + KRB-USM-MIB DEFINITIONS ::= BEGIN + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, OBJECT-IDENTITY, + snmpModules, Counter32, Unsigned32 FROM SNMPv2-SMI + TruthValue, DisplayString FROM SNMPv2-TC + usmUserEntry FROM SNMP-USER-BASED-SM-MIB + + + + krbUsmMib MODULE-IDENTITY + LAST-UPDATED "00071300Z" + ORGANIZATION "IETF SNMP V3 Working Group" + CONTACT-INFO + "Michael Thomas + Cisco Systems + 375 E Tasman Drive + San Jose, Ca 95134 + Phone: +1 408-525-5386 + Fax: +1 801-382-5284 + email: mat@cisco.com" + DESCRIPTION + "This MIB contains the MIB variables to + exchange Kerberos credentials and a session + key to be used to authenticate and set up + USM keys" + + ::= { snmpModules nnn } -- not sure what needs to be here. + krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 } + + krbUsmMibAuthInAttemps + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Counter of the number of Kerberos + authorization attempts as defined by + receipt of a PDU from a Manager with a + krbUsmMibNonce set in the principal table." + ::= { krbUsmMibObjects 1 } + + krbUsmMibAuthOutAttemps + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 12] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + DESCRIPTION + "Counter of the number of unsolicited Kerberos + authorization attempts as defined by + an Agent sending an INFORM or TRAP PDU with a + krbUsmMibApRep but without krbUsmApMibNonce + varbind." + ::= { krbUsmMibObjects 2 } + krbUsmMibAuthInFail + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Counter of the number of Kerberos + authorization failures as defined by + a Manager setting the krbUsmMibNonce + in the principal table which results + in some sort of failure to install keys + in the requested USM user entry." + ::= { krbUsmMibObjects 3 } + + krbUsmMibAuthOutFail + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Counter of the number of unsolicited Kerberos + authorization failures as defined by + an Agent sending an INFORM or TRAP PDU with a + krbUsmMibApRep but without a krbUsmMibNonce + varbind which does not result in keys being + installed for that USM user entry." + ::= { krbUsmMibObjects 4 } + + krbUsmMibPrinTable OBJECT-TYPE + SYNTAX SEQUENCE OF krbUsmMibEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table which maps Kerberos principals with USM + users as well as the per user variables to key + up sessions" + ::= { krbUsmMibObjects 5 } + + krbUsmMibPrinEntry OBJECT-TYPE + SYNTAX KrbUsmMibPrinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 13] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + "an entry into the krbMibPrinTable which is a + parallel table to UsmUserEntry table" + AUGMENTS { usmUserEntry } + ::= { krbUsmMibPrinTable 1 } + + KrbUsmMibPrinEntry SEQUENCE + { + krbUsmMibApReq OCTET STRING, + krbUsmMibApRep OCTET STRING, + krbUsmMibNonce OCTET STRING, + krbUsmMibMgrTGT OCTET STRING, + krbUsmMibUnsolicitedNotify TruthValue, + } + + + krbUsmMibApReq OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "This variable contains a DER encoded Kerberos + AP-REQ or KRB-ERROR for the USM user which is + to be keyed. This is sent from the Agent to + the Manager in an INFORM or TRAP request. + KRB-ERROR MUST only be sent to the Manager + if it is in response to a keying request from + the Manager. + " + ::= { krbUsmMibPrinEntry 1 } + + krbUsmMibApRep OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable contains the DER encoded response + to an AP-REQ. This variable is SET by the + Manager to acknowledge receipt of an AP-REQ. If + krbUsmMibApRep contains a Kerberos AP-REP, the + Agent must derive keys from the session key + of the Kerberos ticket in the AP-REQ and place + them in the USM database in a manner specified + by [RFC2574]. If the Manager detects an error, + it will instead place a KRB-ERROR in this + variable to inform the Agent of the error. + + This variable is in effect a write-only variable. + attempts to read this variable will result in a + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 14] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + null octet string being returned" + ::= { krbUsmMibPrinEntry 2 } + + krbUsmMibNonce OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "SET'ing a krbUsmMibnonce allows a Manager to + determine whether an INFORM or TRAP from an + Agent is an outstanding keying request, or + unsolicited from the Agent. The Manager + initiates keying for a particular USM user + by writing a nonce into the row for which + desires to establish a security association. + The nonce is an ASCII string of the form + ``host:port?nonce'' where: + + host: is either an FQDN, or valid ipv4 or ipv6 + numerical notation of the Manager which + desires to initiate keying + port: is the destination port at which that the + Manager may be contacted + nonce: is a number generated by the Manager to + correlate the transaction + + The same nonce MUST be sent to the Manager in a + subsequent INFORM or TRAP with a krbUsmApReq. + The Agent MUST use the host address and port + supplied in the nonce as the destination of a + subsequent INFORM or TRAP. Unsolicited keying + requests MUST NOT contain a nonce, and should + instead use the destination stored Notifies of + this type. + + Nonces MUST be highly collision resistant either + using a time based method or a suitable random + number generator. Managers MUST never create + nonces which are 0. + + This variable is in effect a write-only variable. + Attempts to read this variable will result in a + nonce of value 0 being returned" + + + ::= { krbUsmMibPrinEntry 3 } + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 15] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + krbUsmMibMgrTgt OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "If the Manager does not possess a symmetric + key with the KDC as would be the case with + a Manager using PKinit for authentication, + the Manager MUST SET its DER encoded ticket + granting ticket into KrbUsmMgrTgt along + with krbUsmMibNonce. + + The agent will then attach the Manager's TGT + into the additional tickets field of the + TGS-REQ message to the KDC to get a User-User + service ticket. + + This variable is in effect a write-only variable. + Attempts to read this variable will result in a + null octet string being returned" + ::= { krbUsmMibPrinEntry 4 } + + + krbUsmMibUnsolicitedNotify OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "If this variable is false, the Agent MUST NOT + send unsolicited INFORM or TRAP PDU's to the + Manager. + + Attempts to SET this variable by the no-auth + no-priv user MUST be rejected." + ::= { krbUsmMibPrinEntry 5 } + + -- + -- Conformance section... nothing optional. + + krbUsmMibCompliences MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The compliance statement for SNMP + engines whichimplement the KRB-USM-MIB + " + MODULE -- this module + MANDATORY-GROUPS { krbUsmMib } + ::= { krbUsmMibCompliances 1 } + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 16] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + END + + +Key Derivation + + The session key provides the basis for the keying material for the + USM user specified in the AP-REQ. The actual keys for use for the + authentication and privacy are produced using the cryptographic hash- + ing function used to protect the ticket itself. The keying material + is derived using this function, F(key, salt), using successive + interations of F over the salt string "SNMPV3RULZ%d", where %d is a + monotonic counter starting at zero. The bits are taken directly from + the successive interations to produce two keys of appropriate size + (as specified in the USM user row) for the authentication transform + first, and the privacy transform second. If the authentication + transform is null, the first bits of the derived key are used for the + privacy transform. + +Security Considerations + + Various elements of this MIB must be readable and writable as the + no-auth, no-priv user. Unless specifically necessary for the key + negotiation, elements of this MIB SHOULD be protected by VACM views + which limit access. In particular, there is no reason anything in + this MIB should be visible to a no-auth, no-priv user with the excep- + tion of KrbUsmMibApReq, KrbUsmMibApRep, KrbUsmMibNonce, and + KrbUsmMibMgrTgt, and then only with the restrictions placed on them + in the MIB. As such, probing attacks are still possible, but should + not be profitable: all of the writable variables with interesting + information in them are defined in such a way as to be write only. + + There are some interesting denial of service attacks which are possi- + ble by attackers spoofing managers and putting load on the KDC to + generate unnecessary tickets. For large numbers or agents this could + be problematic. This can probably be mitigated by the KDC prioritiz- + ing TGS-REQ's though. + + +References + +[1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos + Network Authentication Service (V5)", RFC 1510, September + 1993 + +[2] The SNMPV3 Working Group, U. Blumenthal, B. Wijnen, "The + User-based Security Model of SNMP V3", RFC 2574, April 1999 + +[3] The SNMPV3 Working Group, B. Wijnen, R. Presuhn, + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 17] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + + K.McCloghrie, "The View-based Access Control Model of SNMP + V3", RFC 2575, April 1999 + +[4] The CAT Working Group, Tung, et al, "Public Key Cryptography + for Initial Authentication in Kerberos", draft-ietf-cat-pk- + init-11, November 1999 + +[5] Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC + 2705, October 1999 + + +[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, An Architecture + for Describing SNMP Management Frameworks, RFC 2571, April + 1999. + +[RFC1155] Rose, M., and K. McCloghrie, Structure and Identification of + Management Information for TCP/IP-based Internets, STD 16, + RFC 1155, May 1990. + +[RFC1212] Rose, M., and K. McCloghrie, Concise MIB Definitions, STD + 16, RFC 1212, March 1991. + +[RFC1215] M. Rose, A Convention for Defining Traps for use with the + SNMP, RFC 1215, March 1991. + +[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, Structure of Management Infor- + mation Version 2 (SMIv2), STD 58, RFC 2578, April 1999. + +[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, Textual Conventions for SMIv2, + STD 58, RFC 2579, April 1999. + +[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, Conformance Statements for + SMIv2, STD 58, RFC 2580, April 1999. + +[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple + Network Management Protocol, STD 15, RFC 1157, May 1990. + +[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + Introduction to Community-based SNMPv2, RFC 1901, January + 1996. + +[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Tran- + sport Mappings for Version 2 of the Simple Network Manage- + ment Protocol (SNMPv2), RFC 1906, January 1996. + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 18] + + + + + +INTERNET-DRAFT Kerberized USM Keying 13 July 2000 + + +[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP), RFC 2572, April 1999. + +[RFC2574] Blumenthal, U., and B. Wijnen, User-based Security Model + (USM) for version 3 of the Simple Network Management Proto- + col (SNMPv3), RFC 2574, April 1999. + +[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Pro- + tocol Operations for Version 2 of the Simple Network Manage- + ment Protocol (SNMPv2), RFC 1905, January 1996. + +[RFC2573] Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications, + RFC 2573, April 1999. + +[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, View-based + Access Control Model (VACM) for the Simple Network Manage- + ment Protocol (SNMP), RFC 2575, April 1999. + +[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, Introduc- + tion to Version 3 of the Internet-standard Network Manage- + ment Framework, RFC 2570, April 1999. + +Author's Address + + Michael Thomas + Cisco Systems + 375 E Tasman Rd + San Jose, Ca, 95134, USA + Tel: +1 408-525-5386 + email: mat@cisco.com + + + + + + + + + + + + + + + + + + + + +Thomas draft-thomas-snmpv3-kerbusm-00 [Page 19] + + diff --git a/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt new file mode 100644 index 0000000..b89108a --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt @@ -0,0 +1,227 @@ + +CAT Working Group Mike Swift +draft-trostle-win2k-cat-kerberos-set-passwd-00.txt Microsoft +February 2000 Jonathan Trostle +Category: Informational Cisco Systems + John Brezak + Microsoft + + Extending Change Password for Setting Kerberos Passwords + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos [1] change password protocol [2], does not allow for + an administrator to set a password for a new user. This functionality + is useful in some environments, and this proposal extends [2] to + allow password setting. The changes are: adding new fields to the + request message to indicate the principal which is having its + password set, not requiring the initial flag in the service ticket, + using a new protocol version number, and adding three new result + codes. + +2. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + + requirement is consistent with the TCP transport header in 1510bis. + +Request Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP_REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in big-endian order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0xff80 (big-endian + integer). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [1]) The AP-REQ message must be for the service + principal kadmin/changepw@REALM, where REALM is the REALM of the user + who wishes to change/set his password. The ticket in the AP-REQ must + must include a subkey in the Authenticator. To enable setting of + passwords, it is not required that the initial flag be set in the + Kerberos service ticket. + + KRB-PRIV message (see [1]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData ::= SEQUENCE { + newpasswd[0] OCTET STRING, + targname[2] PrincipalName OPTIONAL, + targrealm[3] Realm OPTIONAL + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set/change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password. The server also + checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswd field contains the cleartext password, and the server + should apply any local policy checks including password policy checks. + The server then generates the appropriate keytypes from the password + + and stores them in the KDC database. If all goes well, status 0x0000 + is returned to the client in the reply message (see below). + +Reply Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in big-endian order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0001 (big-endian + integer). (The reply message has the same format as in [2]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [2]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + decode the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [2]): + The result code must have one of the following values (big- + endian integer): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a "soft" error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + 0xFFFF if the request fails for some other reason. + Although only a few non-zero result codes are specified here, + the client should accept any non-zero result code as indicating + failure. + result string - from [2]: + This field should contain information which the server thinks + might be useful to the user, such as feedback about policy + failures. The string must be encoded in UTF-8. It may be + omitted if the server does not wish to include it. If it is + present, the client should display the string to the user. + This field is analogous to the string which follows the numeric + code in SMTP, FTP, and similar protocols. + +3. References + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments 1510. + + [2] M. Horowitz. Kerberos Change Password Protocol. + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +4. Expiration Date + + This draft expires in August 2000. + +5. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + jbrezak@microsoft.com diff --git a/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt new file mode 100644 index 0000000..e9611e3 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt @@ -0,0 +1,327 @@ +Network Working Group T. Ts'o, Editor +Internet-Draft Massachusetts Institute of Technology +draft-tso-telnet-krb5-04.txt April 2000 + + Telnet Authentication: Kerberos Version 5 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference mate- + rial or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + +0. Abstract + + This document describes how Kerberos Version 5 [1] is used with the + telnet protocol. It describes an telnet authentication sub-option + to be used with the telnet authentication option [2]. This mecha- + nism can also used to provide keying material to provide data confi- + dentiality services in conjuction with the telnet encryption option + [3]. + +1. Command Names and Codes + + Authentication Types + + KERBEROS_V5 2 + + Sub-option Commands + + Expires Sept 2000 [Page 1] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + AUTH 0 + REJECT 1 + ACCEPT 2 + RESPONSE 3 + FORWARD 4 + FORWARD_ACCEPT 5 + FORWARD_REJECT 6 + +2. Command Meanings + + IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5 + KRB_AP_REQ message> IAC SE + + This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the + remote side of the connection. The first octet of the <authenti- + cation-type-pair> value is KERBEROS_V5, to indicate that Version 5 + of Kerberos is being used. The Kerberos V5 authenticator in the + KRB_AP_REQ message must contain a Kerberos V5 checksum of the + two-byte authentication type pair. This checksum must be verified + by the server to assure that the authentication type pair was cor- + rectly negotiated. The Kerberos V5 authenticator must also in- + clude the optional subkey field, which shall be filled in with a + randomly chosen key. This key shall be used for encryption pur- + poses if encryption is negotiated, and shall be used as the nego- + tiated session key (i.e., used as keyid 0) for the purposes of the + telnet encryption option; if the subkey is not filled in, then the + ticket session key will be used instead. + + If data confidentiality services is desired the ENCRYPT_US- + ING_TELOPT flag must be set in the authentication-type-pair as + specified in [2]. + + IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE + + This command indicates that the authentication was successful. + + If the AUTH_HOW_MUTUAL bit is set in the second octet of the au- + thentication-type-pair, the RESPONSE command must be sent before + the ACCEPT command is sent. + + IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op- + tional reason for rejection> IAC SE + + This command indicates that the authentication was not successful, + and if there is any more data in the sub-option, it is an ASCII + text message of the reason for the rejection. + + IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE + <KRB_AP_REP message> IAC SE + + Expires Sept 2000 [Page 2] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + This command is used to perform mutual authentication. It is only + used when the AUTH_HOW_MUTUAL bit is set in the second octet of + the authentication-type-pair. After an AUTH command is verified, + a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP + message to perform the mutual authentication. + + IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED + message> IAC SE + + This command is used to forward kerberos credentials for use by + the remote session. The credentials are passed as a Kerberos V5 + KRB_CRED message which includes, among other things, the forwarded + Kerberos ticket and a session key associated with the ticket. Part + of the KRB_CRED message is encrypted in the key previously ex- + changed for the telnet session by the AUTH suboption. + + IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC + SE + + This command indicates that the credential forwarding was success- + ful. + + IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op- + tional reason for rejection> IAC SE + + This command indicates that the credential forwarding was not suc- + cessful, and if there is any more data in the sub-option, it is an + ASCII text message of the reason for the rejection. + +3. Implementation Rules + + If the second octet of the authentication-type-pair has the AUTH_WHO + bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial + AUTH command, and the server responds with either ACCEPT or REJECT. + In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv- + er will send a RESPONSE before it sends the ACCEPT. + + If the second octet of the authentication-type-pair has the AUTH_WHO + bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial + AUTH command, and the client responds with either ACCEPT or REJECT. + In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the + client will send a RESPONSE before it sends the ACCEPT. + + The Kerberos principal used by the server will generally be of the + form "host/<hostname>@realm". That is, the first component of the + Kerberos principal is "host"; the second component is the fully qual- + ified lower-case hostname of the server; and the realm is the Ker- + beros realm to which the server belongs. + + Expires Sept 2000 [Page 3] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP + messages, the KRB_CRED structure, or the optional rejection text + string must be doubled as specified in [4]. Otherwise the following + byte might be mis-interpreted as a Telnet command. + +4. Examples + + User "joe" may wish to log in as user "pete" on machine "foo". If + "pete" has set things up on "foo" to allow "joe" access to his ac- + count, then the client would send IAC SB AUTHENTICATION NAME "pete" + IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE> + IAC SE + + The server would then authenticate the user as "joe" from the + KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by + Kerberos, and if "pete" has allowed "joe" to use his account, the + server would then continue the authentication sequence by sending a + RESPONSE (to do mutual authentication, if it was requested) followed + by the ACCEPT. + + If forwarding has been requested, the client then sends IAC SB AU- + THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure + with credentials to be forwarded> IAC SE. If the server succeeds in + reading the forwarded credentials, the server sends FORWARD_ACCEPT + else, a FORWARD_REJECT is sent back. + + Client Server + IAC DO AUTHENTICATION + IAC WILL AUTHENTICATION + + [ The server is now free to request authentication information. + ] + + IAC SB AUTHENTICATION SEND + KERBEROS_V5 CLIENT|MUTUAL + KERBEROS_V5 CLIENT|ONE_WAY IAC + SE + + [ The server has requested mutual Version 5 Kerberos + authentication. If mutual authentication is not supported, + then the server is willing to do one-way authentication. + + The client will now respond with the name of the user that it + wants to log in as, and the Kerberos ticket. ] + + IAC SB AUTHENTICATION NAME + "pete" IAC SE + IAC SB AUTHENTICATION IS + KERBEROS_V5 CLIENT|MUTUAL AUTH + <KRB_AP_REQ message> IAC SE + + Expires Sept 2000 [Page 4] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + [ Since mutual authentication is desired, the server sends across + a RESPONSE to prove that it really is the right server. ] + + IAC SB AUTHENTICATION REPLY + KERBEROS_V5 CLIENT|MUTUAL + RESPONSE <KRB_AP_REP message> + IAC SE + + [ The server responds with an ACCEPT command to state that the + authentication was successful. ] + + IAC SB AUTHENTICATION REPLY KER- + BEROS_V5 CLIENT|MUTUAL ACCEPT + IAC SE + + [ If so requested, the client now sends the FORWARD command to + forward credentials to the remote site. ] + + IAC SB AUTHENTICATION IS KER- + BEROS_V5 CLIENT|MUTUAL + FORWARD <KRB_CRED message> IAC + SE + + [ The server responds with a FORWARD_ACCEPT command to state that + the credential forwarding was successful. ] + + Expires Sept 2000 [Page 5] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + IAC SB AUTHENTICATION REPLY KER- + BEROS_V5 CLIENT|MUTUAL FOR- + WARD_ACCEPT IAC SE + +5. Security Considerations + + The selection of the random session key in the Kerberos V5 authenti- + cator is critical, since this key will be used for encrypting the + telnet data stream if encryption is enabled. It is strongly advised + that the random key selection be done using cryptographic techniques + that involve the Kerberos ticket's session key. For example, using + the current time, encrypting it with the ticket session key, and then + correcting for key parity is a strong way to generate a subsession + key, since the ticket session key is assumed to be never disclosed to + an attacker. + + Care should be taken before forwarding a user's Kerberos credentials + to the remote server. If the remote server is not trustworthy, this + could result in the user's credentials being compromised. Hence, the + user interface should not forward credentials by default; it would be + far safer to either require the user to explicitly request creden- + tials forwarding for each connection, or to have a trusted list of + hosts for which credentials forwarding is enabled, but to not enable + credentials forwarding by default for all machines. + +6. IANA Considerations + + The authentication type KERBEROS_V5 and its associated suboption values + are registered with IANA. Any suboption values used to extend + the protocol as described in this document must be registered + with IANA before use. IANA is instructed not to issue new suboption + values without submission of documentation of their use. + +7. Acknowledgments + + This document was originally written by Dave Borman of Cray Research, + Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen- + tation experience. Cliff Neuman and Prasad Upasani of USC's Informa- + tion Sciences Institute developed the credential forwarding support. + + In addition, the contributions of the Telnet Working Group are also + gratefully acknowledged. + +8. References + + [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys- + tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem- + ber 1993. + + [2] Internet Engineering Task Force, "Telnet Authentication", draft- + tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems, + April 2000. + + [3] Internet Engineering Task Force, "Telnet Data Encryption Option", + draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux + Systems, April 2000. + + [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC + + Expires Sept 2000 [Page 6] + +Internet-Draft Kerberos Version 5 for Telnet April 2000 + + 855, STD 8, USC/Information Sciences Institute, May 1983. + +Editor's Address + + Theodore Ts'o + Massachusetts Institute of Technology + MIT Room E40-343 + 77 Massachusetts Avenue + Cambridge, MA 02139 + + Phone: (617) 253-8091 + EMail: tytso@mit.edu + + Expires Sept 2000 [Page 7] + + + Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 + The Kermit Project * Columbia University + 612 West 115th St #716 * New York, NY * 10025 + http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org + + diff --git a/crypto/heimdal/doc/standardisation/rc4-hmac.txt b/crypto/heimdal/doc/standardisation/rc4-hmac.txt new file mode 100644 index 0000000..202d44e --- /dev/null +++ b/crypto/heimdal/doc/standardisation/rc4-hmac.txt @@ -0,0 +1,587 @@ +CAT working group M. Swift +Internet Draft J. Brezak +Document: draft-brezak-win2k-krb-rc4-hmac-03.txt Microsoft +Category: Informational June 2000 + + + The Windows 2000 RC4-HMAC Kerberos encryption type + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may be + updated, replaced, or obsoleted by other documents at any time. It + is inappropriate to use Internet- Drafts as reference material or to + cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +1. Abstract + + The Windows 2000 implementation of Kerberos introduces a new + encryption type based on the RC4 encryption algorithm and using an + MD5 HMAC for checksum. This is offered as an alternative to using + the existing DES based encryption types. + + The RC4-HMAC encryption types are used to ease upgrade of existing + Windows NT environments, provide strong crypto (128-bit key + lengths), and provide exportable (meet United States government + export restriction requirements) encryption. + + The Windows 2000 implementation of Kerberos contains new encryption + and checksum types for two reasons: for export reasons early in the + development process, 56 bit DES encryption could not be exported, + and because upon upgrade from Windows NT 4.0 to Windows 2000, + accounts will not have the appropriate DES keying material to do the + standard DES encryption. Furthermore, 3DES is not available for + export, and there was a desire to use a single flavor of encryption + in the product for both US and international products. + + As a result, there are two new encryption types and one new checksum + type introduced in Windows 2000. + + +2. Conventions used in this document + + + +Swift Category - Informational 1 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. Key Generation + + On upgrade from existing Windows NT domains, the user accounts would + not have a DES based key available to enable the use of DES base + encryption types specified in RFC 1510. The key used for RC4-HMAC is + the same as the existing Windows NT key (NT Password Hash) for + compatibility reasons. Once the account password is changed, the DES + based keys are created and maintained. Once the DES keys are + available DES based encryption types can be used with Kerberos. + + The RC4-HMAC String to key function is defined as follow: + + String2Key(password) + + K = MD4(UNICODE(password)) + + The RC4-HMAC keys are generated by using the Windows UNICODE version + of the password. Each Windows UNICODE character is encoded in + little-endian format of 2 octets each. Then performing an MD4 [6] + hash operation on just the UNICODE characters of the password (not + including the terminating zero octets). + + For an account with a password of "foo", this String2Key("foo") will + return: + + 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, + 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc + +4. Basic Operations + + The MD5 HMAC function is defined in [3]. It is used in this + encryption type for checksum operations. Refer to [3] for details on + its operation. In this document this function is referred to as + HMAC(Key, Data) returning the checksum using the specified key on + the data. + + The basic MD5 hash operation is used in this encryption type and + defined in [7]. In this document this function is referred to as + MD5(Data) returning the checksum of the data. + + RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A + compatible cipher is described in [8]. In this document the function + is referred to as RC4(Key, Data) returning the encrypted data using + the specified key on the data. + + These encryption types use key derivation as defined in [9] (RFC- + 1510BIS) in Section titled "Key Derivation". With each message, the + message type (T) is used as a component of the keying material. This + summarizes the different key derivation values used in the various + +Swift Category - Informational 2 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + operations. Note that these differ from the key derivations used in + other Kerberos encryption types. + + T = 1 for TS-ENC-TS in the AS-Request + T = 8 for the AS-Reply + T = 7 for the Authenticator in the TGS-Request + T = 8 for the TGS-Reply + T = 2 for the Server Ticket in the AP-Request + T = 11 for the Authenticator in the AP-Request + T = 12 for the Server returned AP-Reply + T = 15 in the generation of checksum for the MIC token + T = 0 in the generation of sequence number for the MIC token + T = 13 in the generation of checksum for the WRAP token + T = 0 in the generation of sequence number for the WRAP token + T = 0 in the generation of encrypted data for the WRAPPED token + + All strings in this document are ASCII unless otherwise specified. + The lengths of ASCII encoded character strings include the trailing + terminator character (0). + + The concat(a,b,c,...) function will return the logical concatenation + (left to right) of the values of the arguments. + + The nonce(n) function returns a pseudo-random number of "n" octets. + +5. Checksum Types + + There is one checksum type used in this encryption type. The + Kerberos constant for this type is: + #define KERB_CHECKSUM_HMAC_MD5 (-138) + + The function is defined as follows: + + K - is the Key + T - the message type, encoded as a little-endian four byte integer + + CHKSUM(K, T, data) + + Ksign = HMAC(K, "signaturekey") //includes zero octet at end + tmp = MD5(concat(T, data)) + CHKSUM = HMAC(Ksign, tmp) + + +6. Encryption Types + + There are two encryption types used in these encryption types. The + Kerberos constants for these types are: + #define KERB_ETYPE_RC4_HMAC 23 + #define KERB_ETYPE_RC4_HMAC_EXP 24 + + The basic encryption function is defined as follow: + + T = the message type, encoded as a little-endian four byte integer. + +Swift Category - Informational 3 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + BYTE L40[14] = "fortybits"; + BYTE SK = "signaturekey"; + + ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 10 + 4, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + add_8_random_bytes(data, data_len, conf_plus_data); + HMAC (K2, conf_plus_data, 8 + data_len, checksum); + HMAC (K1, checksum, 16, K3); + RC4(K3, conf_plus_data, 8 + data_len, edata + 16); + memcpy (edata, checksum, 16); + edata_len = 16 + 8 + data_len; + } + + DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + HMAC (K1, edata, 16, K3); // checksum is at edata + RC4(K3, edata + 16, edata_len - 16, edata + 16); + data_len = edata_len - 16 - 8; + memcpy (data, edata + 16 + 8, data_len); + + // verify generated and received checksums + HMAC (K2, edata + 16, edata_len - 16, checksum); + if (memcmp(edata, checksum, 16) != 0) + printf("CHECKSUM ERROR !!!!!!\n"); + } + + The header field on the encrypted data in KDC messages is: + + typedef struct _RC4_MDx_HEADER { + UCHAR Checksum[16]; + UCHAR Confounder[8]; + } RC4_MDx_HEADER, *PRC4_MDx_HEADER; + + The KDC message is encrypted using the ENCRYPT function not + including the Checksum in the RC4_MDx_HEADER. + + +Swift Category - Informational 4 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +7. Key Strength Negotiation + + A Kerberos client and server can negotiate over key length if they + are using mutual authentication. If the client is unable to perform + full strength encryption, it may propose a key in the "subkey" field + of the authenticator, using a weaker encryption type. The server + must then either return the same key or suggest its own key in the + subkey field of the AP reply message. The key used to encrypt data + is derived from the key returned by the server. If the client is + able to perform strong encryption but the server is not, it may + propose a subkey in the AP reply without first being sent a subkey + in the authenticator. + +8. GSSAPI Kerberos V5 Mechanism Type + +8.1 Mechanism Specific Changes + + The GSSAPI per-message tokens also require new checksum and + encryption types. The GSS-API per-message tokens must be changed to + support these new encryption types (See [5] Section 1.2.2). The + sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption + is: + Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 + + The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: + Byte 2..3 SGN ALG 0x11 0x00 - HMAC + + The only support quality of protection is: + #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 + + In addition, when using an RC4 based encryption type, the sequence + number is sent in big-endian rather than little-endian order. + + The Windows 2000 implementation also defines new GSSAPI flags in the + initial token passed when initializing a security context. These + flags are passed in the checksum field of the authenticator (See [5] + Section 1.1.1). + + GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s + implementation of DCE RPC, which initially expected three legs of + authentication. Setting this flag causes an extra AP reply to be + sent from the client back to the server after receiving the server’s + AP reply. In addition, the context negotiation tokens do not have + GSSAPI framing - they are raw AP message and do not include object + identifiers. + #define GSS_C_DCE_STYLE 0x1000 + + + +Swift Category - Informational 5 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the + server that it should only allow the server application to identify + the client by name and ID, but not to impersonate the client. + #define GSS_C_IDENTIFY_FLAG 0x2000 + + GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the + client wants to be informed of extended error information. In + particular, Windows 2000 status codes may be returned in the data + field of a Kerberos error message. This allows the client to + understand a server failure more precisely. In addition, the server + may return errors to the client that are normally handled at the + application layer in the server, in order to let the client try to + recover. After receiving an error message, the client may attempt to + resubmit an AP request. + #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 + + These flags are only used if a client is aware of these conventions + when using the SSPI on the Windows platform, they are not generally + used by default. + + When NetBIOS addresses are used in the GSSAPI, they are identified + by the GSS_C_AF_NETBIOS value. This value is defined as: + #define GSS_C_AF_NETBIOS 0x14 + NetBios addresses are 16-octet addresses typically composed of 1 to
th
15 characters, trailing blank (ascii char 20) filled, with a 16 + octet of 0x0. + +8.2 GSSAPI Checksum Type + + The GSSAPI checksum type and algorithm is defined in Section 5. Only + the first 8 octets of the checksum are used. The resulting checksum + is stored in the SGN_CKSUM field (See [5] Section 1.2) for + GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). + + MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, + MIC_seq, MIC_checksum) + { + HMAC (K, SK, 13, K4); + T = 15; + memcpy (T_plus_hdr_plus_msg + 00, &T, 4); + memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8); + // 0101 1100 FFFFFFFF + memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); + MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); + HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); + memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K5); + }else{ + HMAC (K, &T, 4, K5); + +Swift Category - Informational 6 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + } + if (fRC4_EXP) memset(K5+7, 0xAB, 9); + HMAC(K5, MIT_checksum, 8, K6); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K6, seq_plus_direction, 8, MIC_seq); + } + +8.3 GSSAPI Encryption Types + + There are two encryption types for GSSAPI message tokens, one that + is 128 bits in strength, and one that is 56 bits in strength as + defined in Section 6. + + All padding is rounded up to 1 byte. One byte is needed to say that + there is 1 byte of padding. The DES based mechanism type uses 8 byte + padding. See [5] Section 1.2.2.3. + + The encryption mechanism used for GSS wrap based messages is as + follow: + + + WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, + WRAP_seq, WRAP_checksum, edata, edata_len) + { + HMAC (K, SK, 13, K7); + T = 13; + PAD = 1; + memcpy (T_hdr_conf_msg_pad + 00, &T, 4); + memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 + FFFFFFFF + memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); + memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); + MD5 (T_hdr_conf_msg_pad, + 4 + 8 + 8 + msg_len + 1, + MD5_of_T_hdr_conf_msg_pad); + HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); + memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 + bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K8); + }else{ + HMAC (K, &T, 4, K8); + } + if (fRC4_EXP) memset(K8+7, 0xAB, 9); + HMAC(K8, WRAP_checksum, 8, K9); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + +Swift Category - Informational 7 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K9, seq_plus_direction, 8, WRAP_seq); + + for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte + of key with 0xF0 + T = 0; + if (fRC4_EXP){ + *(DWORD *)(L40+10) = T; + HMAC(K10, L40, 14, K11); + memset(K11+7, 0xAB, 9); + }else{ + HMAC(K10, &T, 4, K11); + } + HMAC(K11, seq_num, 4, K12); + RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, + edata); /* skip T & hdr */ + edata_len = 8 + msg_len + 1; // conf + msg_len + pad + } + + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + +9. Security Considerations + + Care must be taken in implementing this encryption type because it + uses a stream cipher. If a different IV isn’t used in each direction + when using a session key, the encryption is weak. By using the + sequence number as an IV, this is avoided. + +10. Acknowledgements + + We would like to thank Salil Dangi for the valuable input in + refining the descriptions of the functions and review input. + +11. References + + 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997 + + 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993 + + + +Swift Category - Informational 8 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, + June 1996 + + 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April + 1992 + + 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April + 1992 + + 8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption + Algorithm", Work in Progress. + + 9 RC4 is a proprietary encryption algorithm available under license + from RSA Data Security Inc. For licensing information, contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + 10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 04.txt, June 25, 1999 + + +12. Author's Addresses + + Mike Swift + Dept. of Computer Science + Sieg Hall + University of Washington + Seattle, WA 98105 + Email: mikesw@cs.washington.edu + + John Brezak + Microsoft + One Microsoft Way + Redmond, Washington + Email: jbrezak@microsoft.com + + + + + + + + + + + + + + + +Swift Category - Informational 9 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + +13. Full Copyright Statement + + "Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and + furnished to others, and derivative works that comment on or + otherwise explain it or assist in its implementation may be + prepared, copied, published and distributed, in whole or in + part, without restriction of any kind, provided that the above + copyright notice and this paragraph are included on all such + copies and derivative works. However, this document itself may + not be modified in any way, such as by removing the copyright + notice or references to the Internet Society or other Internet + organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or + as required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will + not be revoked by the Internet Society or its successors or + assigns. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 10 + diff --git a/crypto/heimdal/doc/whatis.texi b/crypto/heimdal/doc/whatis.texi index 97d4da2..eff52d7 100644 --- a/crypto/heimdal/doc/whatis.texi +++ b/crypto/heimdal/doc/whatis.texi @@ -1,3 +1,5 @@ +@c $Id: whatis.texi,v 1.5 2001/01/28 22:11:23 assar Exp $ + @node What is Kerberos?, Building and Installing, Introduction, Top @chapter What is Kerberos? diff --git a/crypto/heimdal/doc/win2k.texi b/crypto/heimdal/doc/win2k.texi index 1a0e731..baa1b47 100644 --- a/crypto/heimdal/doc/win2k.texi +++ b/crypto/heimdal/doc/win2k.texi @@ -1,4 +1,6 @@ -@node Windows 2000 compatability, Acknowledgments, Kerberos 4 issues, Top +@c $Id: win2k.texi,v 1.12 2001/01/28 22:10:35 assar Exp $ + +@node Windows 2000 compatability, Acknowledgments, Migration, Top @comment node-name, next, previous, up @chapter Windows 2000 compatability @@ -7,37 +9,182 @@ Kerberos 5. Their implementation, however, has some quirks, peculiarities, and bugs. This chapter is a short summary of the things that we have found out while trying to test Heimdal against Windows 2000. Another big problem with the Kerberos implementation in Windows -2000 is the almost complete lack of documentation. +2000 is that the available documentation is more focused on getting +things to work rather than how they work and not that useful in figuring +out how things really work. This information should apply to Heimdal @value{VERSION} and Windows -2000 RC1. It's of course subject all the time and mostly consists of +2000 Professional. It's of course subject all the time and mostly consists of our not so inspired guesses. Hopefully it's still somewhat useful. @menu +* Configuring Windows 2000 to use a Heimdal KDC:: +* Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC:: +* Create account mappings:: * Encryption types:: * Authorization data:: +* Quirks of Windows 2000 KDC:: +* Useful links when reading about the Windows 2000:: @end menu -@node Encryption types, Authorization data, Windows 2000 compatability, Windows 2000 compatability +@node Configuring Windows 2000 to use a Heimdal KDC, Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Windows 2000 compatability, Windows 2000 compatability +@comment node-name, next, precious, up +@section Configuring Windows 2000 to use a Heimdal KDC + +You need the command line program called @code{ksetup.exe} which is available +in the file @code{SUPPORT/TOOLS/SUPPORT.CAB} on the Windows 2000 Professional +CD-ROM. This program is used to configure the Kerberos settings on a +Workstation. + +@code{Ksetup} store the domain information under the registry key: +@code{HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Domains}. + +Use the kadmin program in Heimdal to create a host principal in the +Kerberos realm. + +@example +unix% kadmin +kadmin> ank -pw password host/datan.my.domain +@end example + +You must configure the Workstation as a member of a workgroup, as opposed +to a member in an NT domain, and specify the KDC server of the realm +as follows: +@example +C:> ksetup /setdomain MY.REALM +C:> ksetup /addkdc MY.REALM kdc.my.domain +@end example + +Set the machine password, i.e. create the local keytab: +@example +C:> ksetup /setmachpassword password +@end example + +The workstation must now be rebooted. + +A mapping between local NT users and Kerberos principals must be specified, +you have two choices: + +@example +C:> ksetup /mapuser user@@MY.REALM nt_user +@end example + +This will map a user to a specific principal, this allows you to have +other usernames in the realm than in your NT user database. (Don't ask +me why on earth you would want that...) + +You can also say: +@example +C:> ksetup /mapuser * * +@end example +The Windows machine will now map any user to the corresponding principal, +for example @samp{nisse} to the principal @samp{nisse@@MY.REALM}. +(This is most likely what you want.) + +@node Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Create account mappings, Configuring Windows 2000 to use a Heimdal KDC, Windows 2000 compatability +@comment node-name, next, precious, up +@section Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC + +See also the Step-by-Step guide from Microsoft, referenced below. + +Install Windows 2000, and create a new controller (Active Directory +Server) for the domain. + +By default the trust will be non-transitive. This means that only users +directly from the trusted domain may authenticate. This can be changed +to transitive by using the @code{netdom.exe} tool. + +You need to tell Windows 2000 on what hosts to find the KDCs for the +non-Windows realm with @code{ksetup}, see @xref{Configuring Windows 2000 +to use a Heimdal KDC}. + +This need to be done on all computers that want enable cross-realm +login with @code{Mapped Names}. + +Then you need to add the inter-realm keys on the Windows kdc. Start the +Domain Tree Management tool. (Found in Programs, Administrative tools, +Active Directory Domains and Trusts). + +Right click on Properties of your domain, select the Trust tab. Press +Add on the appropriate trust windows and enter domain name and +password. When prompted if this is a non-Windows Kerberos realm, press +OK. + +Do not forget to add trusts in both directions. + +You also need to add the inter-realm keys to the Heimdal KDC. There are +some tweaks that you need to do to @file{krb5.conf} beforehand. + +@example +[libdefaults] + default_etypes = des-cbc-crc + default_etypes_des = des-cbc-crc +@end example + +since otherwise checksum types that are not understood by Windows 2000 +will be generated (@xref{Quirks of Windows 2000 KDC}.). + +Another issue is salting. Since Windows 2000 does not seem to +understand Kerberos 4 salted hashes you might need to turn off anything +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: +@end example + +You must also set: + +Once that is also done, you can add the required inter-realm keys: + +@example +kadmin add krbtgt/NT.REALM.EXAMPLE.COM@@EXAMPLE.COM +kadmin add krbtgt/REALM.EXAMPLE.COM@@NT.EXAMPLE.COM +@end example + +Use the same passwords for both keys. + +Do not forget to reboot before trying the new realm-trust (after running +@code{ksetup}). It looks like it might work, but packets are never sent to the +non-Windows KDC. + +@node Create account mappings, Encryption types, Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Windows 2000 compatability +@comment node-name, next, precious, up +@section Create account mappings + +Start the @code{Active Directory Users and Computers} tool. Select the +View menu, that is in the left corner just below the real menu (or press +Alt-V), and select Advanced Features. Right click on the user that you +are going to do a name mapping for and choose Name mapping. + +Click on the Kerberos Names tab and add a new principal from the +non-Windows domain. + +@node Encryption types, Authorization data, Create account mappings, Windows 2000 compatability @comment node-name, next, previous, up @section Encryption types Windows 2000 supports both the standard DES encryptions (des-cbc-crc and -des-cbc-md5) and its own proprietary encryption that is based on md4 and -rc4 and which is supposed to be described in -draft-brezak-win2k-krb-rc4-hmac-01.txt. To enable a given principal to -use DES, it needs to have DES keys in the database. To do this, you -need to enable DES keys for the particular principal with the user -administration tool and then change the password. - -@node Authorization data, , Encryption types, Windows 2000 compatability +des-cbc-md5) and its own proprietary encryption that is based on MD4 and +rc4 that is documented in and is supposed to be described in +@file{draft-brezak-win2k-krb-rc4-hmac-03.txt}. New users will get both +MD4 and DES keys. Users that are converted from a NT4 database, will +only have MD4 passwords and will need a password change to get a DES +key. + +Heimdal implements both of these encryption types, but since DES is the +standard and the hmac-code is somewhat newer, it is likely to work better. + +@node Authorization data, Quirks of Windows 2000 KDC, Encryption types, Windows 2000 compatability @comment node-name, next, previous, up @section Authorization data The Windows 2000 KDC also adds extra authorization data in tickets. It is at this point unclear what triggers it to do this. The format of -this data is unknown and according to Microsoft, subject to change. A -simple way of getting hold of the data to be able to understand it +this data is only available under a ``secret'' license from Microsoft, +which prohibits you implementing it. + +A simple way of getting hold of the data to be able to understand it better is described here. @enumerate @@ -56,3 +203,82 @@ the file. analyzing the data. @end enumerate +@node Quirks of Windows 2000 KDC, Useful links when reading about the Windows 2000, Authorization data, Windows 2000 compatability +@comment node-name, next, previous, up +@section Quirks of Windows 2000 KDC + +There are some issues with salts and Windows 2000. Using an empty salt, +which is the only one that Kerberos 4 supported and is therefore known +as a Kerberos 4 compatible salt does not work, as far as we can tell +from out experiments and users reports. Therefore, you have to make +sure you keep around keys with all the different types of salts that are +required. + +Microsoft seems also to have forgotten to implement the checksum +algorithms @samp{rsa-md4-des} and @samp{rsa-md5-des}. This can make Name +mapping (@pxref{Create account mappings}) fail if a @code{des-cbc-md5} key +is used. To make the KDC return only @code{des-cbc-crc} you must delete +the @code{des-cbc-md5} key from the kdc using the @code{kadmin +del_enctype} command. + +@example +kadmin del_enctype lha des-cbc-md5 +@end example + +You should also add the following entries to the @file{krb5.conf} file: + +@example +[libdefaults] + default_etypes = des-cbc-crc + default_etypes_des = des-cbc-crc +@end example + +These configuration options will make sure that no checksums of the +unsupported types are generated. + +@node Useful links when reading about the Windows 2000, , Quirks of Windows 2000 KDC, Windows 2000 compatability +@comment node-name, next, previous, up +@section Useful links when reading about the Windows 2000 + +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. + +@itemize @bullet + +@item Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability - +@url{http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp} +Kerberos GSS-API (in Windows-ize SSPI), Windows as a client in a +non-Windows KDC realm, adding unix clients to a Windows 2000 KDC, and +adding cross-realm trust (@xref{Inter-Realm keys (trust) between Windows 2000 +and a Heimdal KDC}.). + +@item Windows 2000 Kerberos Authentication - +@url{http://www.microsoft.com/TechNet/win2000/win2ksrv/technote/kerberos.asp} +White paper that describes how Kerberos is used in Windows 2000. + +@item Overview of kerberos - +@url{http://support.microsoft.com/support/kb/articles/Q248/7/58.ASP} +Links to useful other links. + +@item Klist for windows - +@url{http://msdn.microsoft.com/library/periodic/period00/security0500.htm} +Describes where to get a klist for Windows 2000. + +@item Event logging for kerberos - +@url{http://support.microsoft.com/support/kb/articles/Q262/1/77.ASP}. +Basicly it say that you can add a registry key +@code{HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel} +with value DWORD equal to 1, and then you'll get logging in the Event +Logger. + +@item Access to the active directory through LDAP +@url{http://msdn.microsoft.com/library/techart/kerberossamp.htm} + +@end itemize + +Other useful programs include these: + +@itemize @bullet +@item pwdump2 +@url{http://www.webspan.net/~tas/pwdump2/} +@end itemize |
